One of the key technology trends over the last decade or three… showing our age there… has been the broadening use of ‘Agile’ software development techniques. If you didn’t know that then you’ve been living in some sort of technology free cave for quite a while.
So much has been written about Agile we weren’t sure where to start. So as always we consulted with the oracle… Dilbert.
Unfortunately what we see all too often is either partially successful or completely failed implementations, often because they had too much focus on Agile adoption being a process change rather than cultural change.
The real shame is that a well-constructed Agile delivery group really does work. And when you see it working it is quite a beautiful thing. Teams working under an effective Agile method are able to produce high quality software targeted at areas of maximum business value, with flexibility built in that deliver without destroying the project team along the way.
So what are some of the common myths or mistakes that we’ve seen across the many Agile implementations we’ve been party too?
1. A little bit of Agile is better than none
And is better than smelly old Waterfall.
A well thought out Waterfall based methodology that is widely understood, regularly reviewed and continuously improved will still out-perform any half-baked Agile implementation. Methodologies do not make great projects, people do that. But poorly implemented methodologies are a sure fire way to lock in project failure.
It’s easy to throw in a few stand up meetings and a retrospective or two but that doesn’t make you Agile. Any good project method will look at basics like project communications and regular review/refine cycles, that’s not some revolutionary thinking that Agile has brought to the party.
And as the saying goes you can’t be half pregnant… so if the drivers exist to consider an Agile implementation then it needs to be approached with 100% commitment. The implementation of an Agile method is a significant change management exercise and needs to be planned and executed with the highest degree of care and not nibbled at out of interest.
2. Iterative = Agile
Following on from the above point we also see many Agile teams working only in an iterative way. This ‘AgileFall’ approach is often the result of a curtailed or misinformed attempt at adopting Agile which has withered away over time until only some of the basic mechanics of Agile are being followed. Unsurprisingly these situations don’t produce great results, at best they may improve on some elements of software delivery but often results are no improvement at all. A common complaint we’ve heard from business stakeholders is “they spent all that time on adopting Agile and now they just go slower”.
Good Agile projects are iterative as well as many other things. But often we see projects with locked in scope not just for a sprint or iteration but for several iterations ahead. This is symptomatic of an Agile tech team dealing with business stakeholders unaware of their role in the Agile project. In reality the result is a series of Waterfall projects, little improvement in the ability to handle change, little tolerance by the business to ‘build it then build it better’ and overall outcomes marginally improved if you’re lucky.
When you have a Product Owner come to the team mid-sprint, excited about a change they want to introduce right now to already delivered software and keen to agree what to remove from the sprint to accommodate the change then you have something that is a long way past just iterative.
3. Agile adoption is best driven by the technology group
In our experience successful implementations of Agile methods need engagement organisation wide. What does an effective Agile team look like? Well it’s a long way from just a bunch of tech gurus with a burn down chart. It starts from the business with the role of Product Owner and must have buy in across the organisation to have any chance of success.
Remember the Agile manifesto… it says that we should value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Individuals, their interactions, how they collaborate and respond to change are all people centric things that require a focus on cultural change. Unsurprisingly we see Agile implementations driven by technology groups become too focused on the adoption of tools and related development processes with insufficient focus on the cultural changes that are critical to successful Agile adoption.
4. Agile means no design and no documentation
Here’s the oracle again…
