I’ve spent over 20 years developing software, most of the time I’ve used some derivative of the waterfall methodology (aka, light the blue touch paper, stand back and then hope and pray). In my previous professional incarnation we started to use what we called an “Agile Methodology”. With hindsight what we really did was empower just the project management team to adjust our delivery and review cadence. Engineering and Product Management didn’t really materially change their approach to development. I suspect that this is because we saw Agile as just a modification of the waterfall approach’s scheduling to include risk as a factor rather than it being a change of mindset for all involved.
In my new role we are more fully embracing Agile, among the plethora of tools, training and information I have been reading Mike Cohn’s book Agile Estimating and Planning. Rather than summarizing the entire book I thought that I might focus in on the key things that stand out as differences between Agile and the more traditional methods for delivering software. Hopefully this will be useful for other software development professionals as they move towards real Agile development.
Part 1- Planning
- Planning upfront for a minimal acceptable product. In the classic “plan everything upfront” methods of software development everyone knows that something will be cut from the end product but no one will admit it and hence no one plans for that eventuality. In Agile you start the process expecting not to get every part of the proposed solution; given that expectation you get to plan for what you are going to give up, way before it becomes a critical issue. This is done by defining the “minimal acceptable product” and then knowing that anything else that is prioritized outside of that will be a bonus.
- I need to think this one through a little more because you could run the joint risks of either putting too much in the minimal acceptable product plan or having engineering think that delivering just that minimal product would be OK and not aiming for additional features.
- Prioritize by comparative story size. Don’t worry too much about what a story is but suffice to say that it describes a feature that a customer wants in the product. The key here is that rather than asking engineering to estimate the effort to build each and every story we just ask them to put them in order of effort.
- Try it sometime. Ask someone to estimate the comparative size, weight or value of three things and then ask them to estimate the actual size, weight or value of each. Invariably they will do much better in the former exercise. I am guessing that “The Price is Right” would not be the marvel of intellectual brilliance that it is today if all the contestants did was to say whether a piece of consumerized junk was more or less valuable than some other miscellaneous detritus.
- Don’t think that you can plan away uncertainty. Agile promotes planning on a more frequent basis, having brief daily reviews, planning for just an iteration and only planning the overall, high-level objectives upfront. Let’s assume that you could in fact plan away all uncertainty; the entire team leaves the meeting room at 2:30 on Thursday with a comprehensive plan in place. As soon as any one of them does anything – starts to code, installs a component, talks to the customer – the reality changed and your plan is no longer complete; change (like death and taxes) is inevitable.
- Consider a house builder. Building a house is relatively simple; there are a well-established set of things to do, they’ve been done in pretty much the exact same way for generations and there are regulations that govern how the end product should be built. Your builder will come to you with a set of plans and a schedule…this is based on his estimate for how long things will take and when they’ll start. Builders pretend that they have planned away uncertainty and that’s the reason that we are all disappointed with builders – it rains, the cement truck blows a tire, the electrician is sick on the Monday after the big game, etc.
- If a house builder can’t do it with the relatively well-established and finite process of building a house how is it that we think we can do it with something as nefarious as software development?
- Plan for features not activities. Most software development companies are primarily driven by engineering and many product managers started out life as engineers so it is natural that we’d gravitate towards using activities as our standard currency. Engineers think in terms of activities on a day-to-day basis. Agile says that we should use features as our primary currency when planning and tracking because customers do not care about activities, they care about delivered features. This is one of the changes in mindset that I talked about. Engineering can code activities but they need to think in terms of features that a customer needs.
- This reminds me of the move to decimalization that happened in the UK, (before my time I hasten to add). You have to believe that everyone in the UK knew that it made no sense having 240 pence in a pound, 12 pence in a shilling (hence 20 shillings in a pound) and coins such as the "half-crown" (worth two shillings and sixpence, or one eighth of a pound). But they were used to this system and the idea of a change was logical but disruptive. We need to get the entire company to embrace the decimalization of software development.
-
Failure to deliver is acceptable, failure to commit is not. This is so common in the non-Agile world. I am going to be uncharacteristically honest here, this one made my blood run cold because I have seen and done this way too many times in the past. When you see it in black and white it makes you wonder why you didn’t do a better job of fighting it.
- Here’s how it goes…your manager or the SVP of sales calls up and says, “When will the product go GA?” You explain that you don’t know yet because of the unknowns and you’re told, “Just give me a date so I can close the deal, it doesn’t matter if it changes later”.
- True to their word, it is OK when the product does not ship on time. I’ve seen products (not mine) with a 1 year schedule ship two years late and no one be terribly surprised. A consequence of not understanding the minimally acceptable product? Of upfront over planning without understanding the unknowns? Of building activities not features so never ending up with something shippable? Of not understanding who the real user of the system was and their needs?
- Probably a combination of all of these…
Conclusion
This is only looking at the first section in Cohn’s book but it already points to the fact that in order to be successful with Agile you need to get buy-in (not just acceptance) from the entire company not just R&D – sales, senior management, marketing, etc. This is a change of mindset but one that truthfully embraces the pragmatic lessons learned from trying to use rigid planning and delivery techniques on a process that is so unpredictable.
In product management one of your new responsibilities it to communicate to the entire team what the customers looks like, what they are trying to achieve, what motivates them and makes them happy. I pretty much guarantee that if the engineering, marketing, tech pubs and especially QA teams do not understand the customer then they will not be able to code features effectively.
Stay tuned for part two – it is due next time we get a rainy day in New Jersey.
Comments