Recently I’ve visited three software companies that are all Agile…. or at least they thought they were Agile. I know a lot has been written about being Agile, but after seeing colleagues, friends and peers struggling to get to grips with Agile I thought I would bring my own brand “Let’s keep it simple” to the debate.
Why do I get nervous when I hear my boss talking about Agile?
It’s probably just me but when I hear people talking about Agile I start to get nervous, especially so when it’s my boss, or someone in marketing…. or the sales guy pitching to the latest prospect.
It’s just in my head I can see a thought bubble above their heads with pictures of silver bullets, magic cures, free energy, invisibility cloaks and personal aerial vehicles.
Part of the problem is that Agile means different things to different people and whilst the classic benefits are easy to understand, the way to get to the benefits can be difficult.
Ok Starbuck, what’s Agile?
Maybe it’s easier to start with what it isn’t. It isn’t Waterfall….
When we tune out all of the white noise there’s a fundamental assumption in Waterfall that doesn’t exist in Agile….. namely that all problems and corresponding solutions can be understood upfront.
Furthermore the project will be delivered in a serial type way…. one thing followed by another in a very structured process that probably ends in a big regression test phase.
Fail Fast
Agile approaches break the project up into small chunks, they’re called Sprints. The basic premise is that when a Sprint is finished the software is ready to release. So we need all the people skills in one team to be able to release i.e. teams are organised around end products / releasable artefacts.
Think about how this might change your team structure e.g. dev and test in one team.
Be specific please….
Agile turns the rationale for a spec on it’s head and says we can’t possibly understand all of the challenges and solutions upfront. We might have a rough idea, or we might choose to deep dive specific problems that we’re aware of in advance, but we accept that we can’t know everything.
We accept that there is inherent uncertainty in not only the solution but also the problem that we are solving. Sounds weird right…. we’re saying that when we start a piece of development we don’t completely understand the problem that we’re solving.
How can this possibly be true…. well it’s true because we’re human and because often we’re attempting to do difficult stuff.
Agile Classic Benefit #1 Risk Reduction
I think this idea of inherent uncertainty is really interesting and kinda contradicts the first of the commonly cited benefits of Agile Development….. Agile reduces Risk:
Agile Trickery
Now this is not Agile trickery or bloggy sleight of hand….. it’s true because all of the stakeholders are accepting the uncertainty upfront, which means that we must work very closely to make sure that we all understand the problem that is being solved and the solution that is being created.
As we discover new constraints or opportunities the customer & build team understand how this will affect the solution. I hate myself for saying this, but we’re walking the path together (you can de-friend me now).
Four Candles Please
So we have actually dramatically reduced the likelihood of delivering “four candles” when the customer bought “fork-andles”.... the risk of delivering the wrong thing has been reduced because we have to work together and communicate frequently.
Agile Classic Benefit #2 Visibility
The second classic benefit is visibility and it’s closely related to the first benefit of reduced risk.
Because we don’t have a large spec to build off we have to talk to the customer frequently, this can take many forms but the most common are:
- Product Managers / Developers present user stories to the organisation / customer in Show & Tells
- Product Managers attend daily stand ups
- Product Managers are part of the sprint planning team
- Product Managers attend sprint retrospectives
Code Caves
This is important because we catch “hey that’s not what I wanted” early in the cycle. We definitely don’t disappear into Code Caves (you know who you are!) to geek out on cool tech that nobody wants or needs.
Agile Classic Benefit #3 Adaptability
Now I'm really going to Birch myself for uttering this….. Adaptability
Is Adaptability even a word?
The third classic benefit of Agile is Adaptability. Being adaptable allows to us change course, to deviate from our original plan and look for new solutions.
We need to be adaptable because we can’t foresee all of the issues that we will have to overcome. Frequently we will also question the problem that we’re solving and sometimes this results in the problem definition changing.
Now, because we’re not locked into the straight-jacket of a spec, and because the customer and supplier accept the inherent uncertainty in this approach we can adapt as our knowledge of the problem and solution evolve.
Agile Benefit #4 Business Value
Finally the last benefit of the Agile approach is reduced time to Business Value. Again this is kind of a contradictory benefit…. given that we can’t see exactly what a solution will look like, and therefore exactly how much time will be required how can we say that it’s possible to realise the value sooner?
It’s basically a cheeky slap across of the face of the Waterfall approach. Most Waterfall approaches overrun because they misidentify the problem and therefore the solution. But because we’re delivering production ready software at the end of a sprint the value is said to have been achieved (although in practise it may take several sprints to get to a viable product, but the principle still holds).
The true cost of a Waterfall project is almost always higher than forecast, and this is enough compensation for us to at least give Agile a try.
A major obstacle to overcome though, is how do you align Agile forecasting with normal budgetary planning…. more on this later.
Many Slip Betwixt Cup and Lip
I estimate that my first attempt at implementing an “Agile Transformation” took at least a year. It was hard work, some subtleties of the approach are difficult to put into practise, especially when you consider that so many different teams are impacted.
In my next blog I'm going to share some of the Agile traps that I've avoided and walked into! Like estimating, cultural challenges and loss of control to name but just a handful.
- SAP Managed Tags:
2 Comments
