In the previous posts we have discussed how to bid for an Agile project and what to look out for in the early stages of the client engagement process. So let’s move on and discuss how to set the stage for successful delivery by planning for success.
Adaptive Planning
Agile development approaches embrace the concept of “adaptive” over “predictive” planning – an example I like to use to highlight the difference between these approaches is that of the weather forecast. Predictive planning approaches (such as those used in waterfall environments) take the high-level estimates for the current project as well as empiric data from previous projects and add some contingency to plan the project.
In comparison, the Met Office does something similar – they take current meteorological data and, taking empiric observations into consideration, produce a weather forecast spanning several months. So far, so useful – however, would you plan your Christmas barbeque based on the weather forecast you’ve checked in July?! Of course you wouldn’t – that wouldn’t be very smart at all, would it? So what does the Met Office do to make sure your prawns stay dry during the festive season? They continuously re-forecast based on more recent information that becomes available – introduce adaptive planning.
Outsourced projects can be a little like planning your Christmas barbie – while incremental delivery and business integration/ absorption is the Agile Nirvana we all hope to reach, this is often not the case in projects involving a vendor, since as a vendor you will be providing one part of the solution, rather than the whole project end-to-end (and let me stress here that software is only ever one part of a solution) and most clients are unwilling to commit their own employees to become part of a cross-functional project team. So sometimes it’s just got to be a big-bang, all-or-nothing drop requiring resources to be booked, people to be on stand-by or marketing material to be completed by other parties on this one particular date. And clients tend to get a little stroppy if you wait until you’ve waded through 80% of their time and money to tell them that it’ll cost at least the same again to finish what you’ve started; adaptive planning allows you to continuously monitor and reassess your actual progress and respond proactively when reality has different plans to your Gantt chart and the information gathered during your project chartering activities (discussed in my previous post on “How to become an Agile Vendor…Where are we going?“) will allow you and your clients to make business-sensible decisions on how to respond when “reality bites”!
Now that we’ve clarified why adaptive planning is a good idea, let’s look at how it all comes together:
Requirements Gathering
If I had to pick my personal “no# 1 tip” for Agile requirements gathering it’s timebox, timebox, timebox! Unless you’re working on the bleeding edge of technological innovation, your clients will have a reasonably good idea of what it is they want from the engagement with you and they want you to tell them how much it’s going to cost and when it can be delivered. So you’ll have to gather some requirements before you start work, ideally in the form of user stories (for a quick brush-up on user stories, check out http://techportal.inviqa.com/2011/07/19/how-to-create-user-stories/) – if your clients don’t have experience in writing user stories, you may want to consider a short intro to what user stories are, their benefits and how they will be used throughout the project. This doesn’t have to be much, but in my experience, it pays to have a short intro at hand and involve an experienced facilitator with a strong understanding of Agile in gathering the stories. There are many different ways of gathering user stories and the most useful / meaningful way to do so will depend on individual context, however, my preference has always been for observation or workshops, i.e. mediums facilitating face-to-face conversations among multiple players, over working off interviews, questionnaires or similar. How to design, structure and facilitate the requirements gathering process goes way beyond the scope of this series so, I will focus on “the stuff that often goes wrong and how to avoid running open-armed into the abyss”:
Apart from ensuring that you maximise project value (and your clients’ exposure to risk) by focusing on the immediate needs (which will help to keep the non-value-add parts of the project short and tight), this will also go a long way towards managing expectations. One of the most common issues in a waterfall project is that we spend weeks and weeks in a room gathering requirements and a large chunk of time writing them up before having to tell our clients that they can’t afford what they want. The issue here is, in my mind, two-fold – 1) as far as your clients are concerned, you’ve wasted their time (and money!) to deliver nothing and 2) you disappointed them at an early (and therefore crucial) time of your engagement. I used to firmly believe that subjective feelings such as “disappointment” had no place in a business environment – however, I had to reassess this simply based on experience and now understand that many business decisions are rooted on emotions such as fear, mistrust and disappointment (or their positive counterparts, for that matter). Gathering requirements is “telling a story” or “painting a picture” of how the final outcome will look, feel and behave – while describing “what’s in their head” to you, clients not only form this picture, they also become attached to it. The disappointment your clients likely feel in the scenario above is not one of “having expectations managed”, it’s one of “having had their vision taken away” – so while you might feel like you’re being “upfront and honest”, they feel like you’ve led them (knowingly) down the wrong path only to leave them hanging. Oh, and obviously both parties are right – from their perspective!
Relative Estimation
Of all the Agile concepts, I’ll have to admit that relative estimation using story points was the hardest one to wrap the thing between my ears around. As a Project Manager, my first question had to be “now how many hours is a point then?” – what followed was a string of attempts at explanation met with a lot of rather furious headshaking on my part.
So how do you make relative estimation and the concept of story points palpable to your clients? This is where your positive client relationship comes back into play (you may remember this from the previous post on “How to become an Agile Vendor…Getting Started”) – in a collaborative relationship, your client will be willing to listen to facts over “wishful thinking”. For a good starting point to discuss the issues with predictive planning (and the false certainty provided by time-based estimation) check out http://agile101.net/2009/07/17/software-estimation-the-more-precise-you-are-the-less-accurate-you-will-be/)
Now before you shake your head, laugh this off and close your browser (I know you’ve been tempted!), let’s look at this some other way. What your clients will be interested in is the delivery of a particular feature, from initial discussion through to deployment – how long the analysis, design, development, testing and deployment take individually is realistically irrelevant, since the feature has not been delivered until all of these parts have been completed, correct? Using relative estimation and a high-level velocity identified for planning purposes will allow you to forecast feature delivery without ever using units of time for estimation, so there’s no reason not to go down this route. “But my client wants to know exactly how much we’re planning to spend on task X!” I hear you say. Until now you may have thought that you have a solid relationship with your client built on trust and a common, shared goal – this question would indicate that there may not be quite as much trust as you thought or wanted. In my experience there’s two common reasons for clients to ask these types of questions – either they don’t trust that the estimate you’ve given them is based on the realistic effort involved in carrying out the work or they feel the pressure internally in their own organisation, so your first step should be trying to figure out what the driver for these kind of questions is.
One way I have found beneficial to conquer the issue of trust around estimation (and, ultimately , establishing a mutual understanding of “value for money”) is to include your clients in the actual estimation process. Not only will they start to get an understanding of how the delivery team comes up with the estimation for a particular story, your client will also be able to provide guidance there and then (without wasting time and money on having to do this as a separate step). As the party that brings the necessary cash to the table, it is your clients responsibility (and their prerogative!) to push back on estimates which would make a particular piece of functionality unfeasible or to elaborate on the scope of a story if they feel that it would increase the benefit provided. In a vendor environment we’re often shy to provide “full disclosure” at the fear of losing our “expert status” with a client, so many organisations don’t include client representatives in the estimation process – in my personal experience I would have to agree that some of the discussions that happen during estimation can shake your clients’ confidence somewhat (especially if you’ve presented yourself as the “all-seeing, all-knowing oracle”) but once again, if you’re uncertain as to how to tackle a particular problem or you’ve never implemented a specific piece of functionality before, raising awareness with your client now and thinking of risk mitigation strategies ahead of time will save money (and your relationship!) in the long run. Also, including your client representatives in the estimation workshops helps to separate the “bells and whistles” from the minimum requirements and allows the whole team to exclude superfluous user stories as well as add any that have been missed previously.
But how do you tackle a scenario where your client representative is feeling undue pressure from their own organisation? In my experience, this can be due to the fact that your client representative has not been empowered to make decisions and has been assigned the job of “overseeing” the execution rather than “steering” the product. Again, my recommendation would be to approach this head-on – it may just be a case of your Product Owner setting the right expectations within their own organisation and getting the information they need to make decisions! Or maybe they really are not the right person to be making the kind of decisions you need, in which case you’re better off going back to the drawing board.
Putting it all together
Now that we’ve looked at gathering user stories and providing some initial estimates around them, we want to start thinking about creating a Release Plan, showing us what can be delivered and when. In my opinion, Release Planning doesn’t vary too much whether you are an in-house or a vendor delivery team, except that “big” and “visible” become even more important when establishing a new relationship with an Agile – immature client who is not co-located with the delivery team. Also, as a vendor it is crucial to bear in mind that there is no such thing as a “software development project” – every piece of software that you deliver is only part of a wider business solution. In an Agile environment, vendors should thrive to establish themselves as valued business partners, and that means understanding, and accounting for, the activities surrounding software development (e.g. end-user training, marketing efforts, advertising, call-centre training, etc).
Another good practice to adopt when putting together your Release plan is to think of your stories not only in terms of a “Product Backlog” but go a step further and organise your stories into “Minimal Viable Product Increments” (MVPs) – a version of your product (which may or may not be the final version) which provides you with the “biggest bang for your buck” at the fastest possible time while maintaining quality to an agreed standard. To get a better understanding of what MVPs are and how they can be used, check out Eric Ries’ blog on http://www.startuplessonslearned.com/2009/08/minimum-viable-product-guide.html
In addition to the above, there is a lot more to planning an Agile project than I will be able to do justice in this blog, so for a great overview of planning on an Agile project, from Product Roadmaps to daily delivery commitments, see Shane Hastie’s “The Many Levels of Planning on an Agile Project” on http://www.infoq.com/articles/many-levels-planning-agile-project
Your details have been submitted and we will be in touch.