Agile/Scrum – Reality Check


I’ve written a number of posts of late (1, 2, 3, 3a) on the topic of Agile/Scrum and Product Management. My goal was to discuss some of the issues I saw with Scrum in relation to software product management.

Given our blog stats, this is one of the hottest, if not THE hottest topic for software product managers today. Within the PM and (I’m assuming) development communities, there are a lot of questions and there is a lot of confusion on this topic. I’ll take a break from my multi-part series on Agile/Scrum and Product Management to bring a little clarity to this topic. If you don’t agree with me or have some comments, please post a comment or question below. It is only with discussion that clarity will be gained.

Agile is a software development philosophy

I made this point in my original article on this topic and it is a very important one to remember. There is so much hype around being “agile” these days: agile development, agile product management, agile companies etc. Who wouldn’t want to be “agile”? But, the second line of the Agile Manifesto clearly states:

Working software over comprehensive documentation

Emphasis on the word software is mine. So don’t get lost or caught up in the rest of it, at least in this discussion. There is nothing wrong with being “agile”, but don’t confuse the specific meaning of the word for the purposes of developing software, and the general meaning of the term “agile” that seems to get applied to everything from people, to departments and companies.

Scrum is a software development methodology

Based on the philosophy defined in the Agile Manifesto, and the Principles behind the Manifesto, Scrum is one of several, and arguably one of the most commonly used, “agile” software development methodologies. It defines specific roles, such as Scrum Master and Product Owner, and a set of best practices for creating high-performance development teams. By decomposing large development efforts into smaller user stories, implementing them via sprints or iterations, and daily progress tracking and reporting (via burndown charts) it is possible to detect potential project delays earlier than other non-Agile development methods.

Scrum is not a panacea for organizational issues

As a development methodology, Scrum can provide more visibility into potential problems in the development cycle earlier than other methodologies such as a traditional waterfall approach. But, Scrum will not solve any organizational problems you may have. It won’t make bad developers better. It won’t make bad product managers better. It won’t fix dysfunctional relationships between Product Management and Engineering. As a general rule, organizational problems cannot be addressed by process changes, and bad relationship between those two groups may actually get worse with Scrum because of the expectation of Engineering of that daily interaction with “the customer” or “the voice of the customer”.

As I’ve written previously, this principle of Agile — that business people and developers must work together daily throughout the project — is a cause for concern.  I’ve seen development teams within the same company not talk to each other daily, let alone business people and developers. Personally, I find this requirement of daily interaction an over adjustment to the large lack of business/technical engagement that has generally plagued many software development projects. Regular, clear and meaningful communication across teams is needed, but daily communication isn’t always needed nor possible.

Scrum can increase developer productivity, but at a price

Every system requires tradeoffs. A lot of Scrum teams focus on velocity which is a Scrum term for the amount of product backlog functionality that a Scrum team can take on in a single sprint or iteration. But, given that analysis of the work needed takes place at the beginning of each sprint (in a sprint planning meeting), it can be difficult to plan out well in advance how how much progress on the backlog of features can be made in a fixed period of time.

Now why is that important? For a Product Manager in an ISV, sprints and iterations are simply a means to an end. The end being a release with a pre-defined and agreed upon set of functionality that will need to be marketed and sold, and much of which is likely tied to customer commitments related to opportunities or sales commitments. In short,  the price for speed and agility via Scrum is a loss of certainty about the state of the software at a given time in the future.

This can lead to frustrating discussions between Product Management and some Scrum teams who adhere rigidly to the Scrum development model, and don’t understand the need of the business to be able to confidently communicate a planned future state of the product to customers, partners or other internal or external parties. Those parties need this information well in advance of the release, so they can make decisions related to their own objectives and goals.

Agile/Scrum should be viewed as an Ethos

Tom Grant at Forrester Research asked if people viewed Agile as a Creed or an Ethos. He defined the two as follows:

  • Agile as a creed. One type of Agile enthusiast treats the methodology of choice as a set of firm guidelines, to be followed or ignored (at your peril). The closer you get to orthodoxy, as the Pharisees communicate by voice or in print, the better the results.
  • Agile as an ethos. The other species of Agile enthusiast sees the methodology as a guide to action. Perfect adherence to its principles are impossible in an imperfect world, so the goal is to add a healthy dose of Agile to the blend of different techniques and imperatives.

First, let me make a point of clarification. I’m not sure if Tom meant it this way, but the way I interpret this, is that when he says “Agile”, it’s really referring to Scrum or any other specific Agile methodology. i.e. Agile is a software development philosophy, whereas the methodologies, like Scrum are defined based on the Agile philosophy.

So, for me, Scrum has to be ethos. And here’s why? No single development methodology can be applicable to every situation or every team. Scrum defines a number of best practices, but is not in itself dogmatic about exactly how everything must be done. This is a good thing. It provides people (IMHO) flexibility to implement what works best for them given time, people, needs and constraints.

If it were rigid, it could hardly be called “agile” could it? :-)

Hopefully this helps provide some clarity into my views on this topic and a little more fodder for discussion. So comments please.

Saeed

If you enjoyed this post, please consider leaving a comment or subscribing to the RSS feed to have future articles delivered to your feed reader.
19 Responses to Agile/Scrum – Reality Check

  1. RT @onpm: Agile/Scrum – Reality Check http://t.co/GjBUg2rP

  2. craig says:

    “In short, the price for speed and agility via Scrum is a loss of certainty about the state of the software at a given time in the future.”

    Sounds like quantum physics; you can measure an object’s movement or identify it’s location, but not both.

  3. saeed says:

    Sit10

    Thanks for coming by. Look forward to future comments.

    In a nutshell, smart people will figure out how to work effectively with or without any kind of methodology. All the religiosity pitting Agile vs. non-Agile methodologies ignores the fact that it’s the people and not the methodology that make things happen.

    Just like every diet boils down to: “eat less, exercise more”, every methodology can be summarized as: “hire talented people, use common sense.” This is especially true for software development.

    Saeed

  4. saeed says:

    Paco

    Thanks for the detailed comment. A couple of points.

    1. There is a distinction to be made between internal IT product/project management, where there THE (singular) customer may actually exist, and ISV software development where the “customer” is really a market or market segment. My writing is focused on the latter. In the internal IT scenario, the customer may simply be the internal project sponsor or some similar entity and have the Product Owner and Product Manager be the same may work.

    2. Even for ISVs , it CAN work, but that doesn’t mean it is ideal or recommended. From an ISV Product Manager perspective, putting more time into the development cycle means less time in other places. There are a few options.

    a) Load it all onto the existing Product Management (i.e Product Owner responsibilities) and decide what you don’t want them to do that they are currently doing

    b) Add headcount (Technical Product Managers) to the PM team and give them the PO responsibility along with other things

    c) Find or assign headcount on the Dev side of the org (there’s likely a lot more dev headcount than PM headcount) who can take on this role, and have them work close with the PM team to ensure tight communication and coordination.

    There may be other ways to deal with it, but anyone who picks option a) better not assume that the PM team can simply absorb the new duties with impact to other aspects of their job.

    3. I completely agree with your point on continuing to produce MRDs, PRDs etc. They have a lot of value to the business as a whole.

    Saeed

  5. Sit10 says:

    Thanks Saeed and team for this assessment, and for your ongoing series about Agile development. My company is attempting Agile development for a major redesign, and I was recently assigned to this team. I believe that our Development Director seized on Agile as industry-sanctioned permission not to have to write functional specs (and little else), but to be fair to the team in question, they are apporaching the methodology seriously. I came to On Product Management to read your discussion, which had been recommended by CrankyPM. It is helping me sort out what is inherent to the methodology, what is methodology-gone-awry in our team’s approach, and what is the team blowing smoke and calling it Agile. I see the multiple (and sometimes conflicting) opinions of your readers as contributors as quite helpful in exploring this topic. Looking forward to reading more.
    ~Service Readiness participant.

  6. Paco says:

    OK, I just read the trilogy+3a of articles thanks to the link from the Cranky PM.

    I agree with the points you’re trying to make.

    I agree with your interpretation of Agile and Scrum.

    However, just like bumblebees fly even though theoretically they’re not supposed to, I’ve worked as a Product Manager who was also simultaneously the Product Owner and Scrum Master for multiple teams. So it *can* work. Not always, but it’s possible.

    In my case, I had several things going for me which I believe were critical to make that possible:

    1. My development manager and the team members all knew me and trusted my judgment about being the voice of the customer.
    2. We stuck to the rule that daily stand-ups should only take 15 minutes. And I enforced that like Stalin.
    4. Everyone bought into Agile Scrum and filled their role. This was especially important for the dev manager. When I’d go Stalin on someone for blathering on in a stand-up, I knew he’d chat with that person afterwards to remind them of the purpose of the stand-up. Ditto with people who blew their estimates. Ditto with people who didn’t follow specs. Etc.
    4. We still wrote a lot of documents!

    That last part probably seems very anti-Agile, but we all felt it was necessary. I still wrote a requirements document. The engineers and I would still collaborate on a functional spec. The engineers still produced a technical spec. We used them as the source material for our backlog – not just a crappy pile of post-it notes that people brain-stormed together over lunch. This supports your contention that Agile is much more about the development process and not the overall product lifecycle.

    I’ve also thought about the fact that I was working on internal corporate projects at the time and one customer-facing project, and I’ve been a PM at other commercial software companies where we did waterfall and I was out doing lots of customer visits, etc. I’ve tried to imagine in my head if I could’ve done my job at those companies as well if we were using Agile Scrum.

    The answer – maybe.

    The main complaint I’ve read here and on other PM blogs about this idea is that PMs need to be out in the wild, talking with customers, while the PO is always stuck hanging out with engineers.

    That’s just not true.

    Two of the teams I was the PM/PO/Scrum Master for were remote and I always ran the stand-ups over a conference call. Eventually, all my teams were remote cuz I moved to Minnesota (don’t ask why) and I would fly back to the office once a month.

    I also made really good use of that monthly visit – I was always there in-person when we started a new project and the team had to digest the requirements backlog for the first time. Did I get bugged by engineers a lot? Yes. Did I need to be physically next to them? No. Email and IM were enough for the random questions that popped up.

    And even if you’re visiting a customer, you can find 15 minutes a day to run a simple stand-up meeting. On the few occasions you can’t, someone else can fill in for you.

    I haven’t even gotten to the best part – the control! By being plugged-in to the team so frequently, I felt much more confident that they understood what the requirements were and I had much more immediate feedback to them when things were going astray.

    And we used Agile Scrum for projects with schedules running from as little as a few weeks (like an Excel widget for internal sales) to a little over a year (the forecasting engine for our external application platform).

    Obviously, though, there are downsides and limitations that I will readily admit:

    1. Even with the close contact, some projects delivered better results than others. Methodologies are just conceptual frameworks. Guys who are lousy at coding and lousy at time estimation will continue to be lousy regardless of the software development lifecycle methodology. In these cases, I just got to see their train wrecks up close and in near real-time. Hooray.

    2. My experience scaled well in the sense I was doing this for multiple product teams. However, each team was relatively small – no more than about 15 engineers+QA. If the teams were much larger, we would’ve needed to break into multiple Scrums and then have Scrum-of-Scrums.

    This would be even harder if teams were across multiple geographies. Quite a few readers are probably familiar with the crappy scheduling window for a San Fran/London/Bangalore meeting. After a point, even Agile Scrum becomes weighted down with bureaucracy.

    Sorry – this is getting lengthy. To summarize:

    1. Yes, PMs can do this.
    2. For the love of God, still produce MRDs, PRDs, functional specs, etc. as you’ve done before. Then use them as the inputs for your backlog.


  7. [...] Agile/Scrum is not a panacea, and commentary on the ironic inflexibility of some agile proponents: Agile/Scrum Reality Check.  (Was going to say “rigidity” instead of “inflexibility”, but kept [...]


  8. [...] The ROLE of the Product Owner in Scrum, is to be the “voice of the customer”. That is fundamental to the methodology. If the PO does what is in the developers’ best interests and NOT the customers’ interests, then the PO is not doing their job, plain and simple. It then becomes a management issue to resolve. The VP of Engineering or whomever is in charge, needs to be mature enough to ensure that people in the Engineering org do their job. If that’s not the case, the problems have nothing to do with Scrum or the Product Owner. As mentioned in a previous post: [...]

  9. saeed says:

    Jim,

    Agree with you wholeheartedly. The fact that many people don’t understand the difference between Product Management and Program or Project Management is part of the problem.

    Hey, this blog was nominated for an award in IT Project Management!

    Add to that, the Development centric view of the world as proposed by Agile, and the lack of business understanding by many of those who are adopting Agile, and you can see where the problem comes from.

    Clarity of thought and a focus on the “big picture” are needed. But too many people are stuck in thought and knowledge silos and can’t get out of them.

    I’ve worked in 3 companies where Agile/Scrum was used. All used a slightly modified methodology to ensure they had alignment with the business needs.

    Saeed

  10. saeed says:

    Steve,

    Smack your development team on the head, give them a dollar and tell them to use it to get a clue.

    The business has to come first. No business can run looking only 1 month or 2 weeks ahead (the length of a typical iteration) at a time. The VP of Eng must surely understand this and thus ensure his development leaders understand it clearly. Software companies must focus on releases and the associated timeframes around those releases.

    A rigid adherence to Scrum, with little regard to the business, is a really bad sign for any company that allows it to persist.

    If the VP of Eng doesn’t “get it”, then appeal to the other members of the management team. If none of them “get it”, then the future of that company may look like this:

    Saeed

  11. Steve says:

    You’ve hit the nail on the head with the problem that I am facing with my Development team as they adopt Agile. In the past, we have asked them to estimate on a set of requirements that we have provided so that we can come up with a release date that can be communicated to the market and internally. Not to mention to get approval from the Product Steering Committee to proceed with the investment to deliver the functionality for that release.

    They are now saying that with agile, they are only going to estimate a sprint at a time and that anything that falls out of one sprint will go back into the backlog to be prioritized for the next sprint.

    While I agree with and like the idea of smaller iterations with “production grade” deliverables, as a vendor of Enterprise software, we cannot get away from doing that up front analysis and estimation to plan out everything that we will do in the release – and then break it up into the different sprints.


  12. Saeed: Wow – what a lot of talk about such a small part of what it means to be a Product Manager! I’ve got no issues with your Scrum overview; however, it sure looks like the conversation is spirling down into more of a Project Manger discussion than a Product Manager discussion. From a Product Manager point-of-view, what really matters is what features are going to be in the product (really what customer problems does it solve) and when will the product be available. End of development story. Yes, it’s easy to get caught up in a lot of development issues; however, a Product Manager has many other things that only he/she can deal with: marketing, sales, pricing, etc. Keep the communication up with the development team and let them use Scrum, waterfall, or whatever just as long as they deliver what’s needed on time.

    - Dr. Jim Anderson
    The Accidental PM Blog


  13. [...] Agile/Scrum – Reality Check by Saeed. This is an in-depth look at the world of Agile and Scrum through the eyes of a product manager. If your development teams have moved to Agile/Scrum, or if they are thinking about it, you need to read this post and its links. [...]


  14. And how accurate are those initial estimates and release plans, really?

    If they’re consistently pretty good, you’re probably in a stable environment (same dev team, same code base, same product management) and you really don’t need agile.

    If they’re not, when and how are the estimation and planning errors manifesting themselves, and how were you compensating?


  15. If you think that a Scrum team can only look one iteration ahead, you’ve misunderstood Scrum. Once you’ve established a velocity, you can extrapolate (not estimate) where you’re likely to be in the future, with greater accuracy than any “up front” estimation technique (and I’m somewhat of an expert on estimation).

    It was the ability of the agile methods to consistently deliver value, on a schedule and budget, that won me over. They do this by providing feedback that lets the business manage for value, rather than just hoping the initial requirements and estimate were good enough (and piling on the overtime and generating a bunch of scrap and technical debt if they weren’t).

    http://wistechnology.com/articles/5190/

    http://wistechnology.com/articles/5514/

    As for “creed” or “ethos,” I’m a pragmatist, and land in the middle. There’s a lot about agile methods that you can tinker with, but there are also load-bearing walls. Cut into them at your peril.

    http://www.ufunctional.com/2009/01/30/load-bearing-walls/


  16. Amen.

    IMO one of the reasons why Agile methods have worked is that they’ve been tried first by early adopters who tend to have pretty good people at all levels.

    Now they’re starting to get (mis)-applied by the early majority, who are going to run into trouble because they don’t know where the load-bearing walls are.

    http://www.ufunctional.com/2009/01/30/load-bearing-walls/

    You can succeed with waterfall, and you can succeed with agile. But to the extent that your initial requirements are volatile and your estimation accuracy is limited, you’re better off with a less brittle, adaptive process (agile). But you still can’t shut your brains off.

We really want to hear your thoughts...