I’m by no means against Agile, in fact I’m a fan of Agile, but within the projects and programs I’ve been managing, I’ve been working with teams using Agile methodologies for long enough to have seen Agile go bad on more than one occasion. In this post I’d like to share some of the common pitfalls and problems that organisations and teams can encounter when using Agile.
In the old days we used the Waterfall approach. Here we would spend a lot of time up-front designing what we want, involving all necessary stakeholders. We would give these specifications to the developers, who would then disappear into a darkened room for 6 months or more to build what we asked for. At the end of six months the developers would emerge from the darkened room with pale skin and ask, “is this what you wanted?”. The answer would usually be “no” and the developers would then disappear back into the darkened room for another few months of hard work to put things right. Eventually though, we’d have something we could release, we’d throw a cheap party for the weary developers, and we’d set them off on the next project.
The reason the developers didn’t build what we want was usually because we didn’t tell them accurately what we wanted because of a gap in our understanding, or because the business environment changed during the time they were writing the code, so that what we asked for was not what we now wanted.
At some point the developers got fed up and decided to come up with a better approach. Developers such as Kent Beck, Ken Schwaber, and Martin Fowler got together (February 2001) and The Agile Alliance was started. The alliance published a manifesto to describe how it was different from the waterfall methodology.
At the core of Agile are short iterations (sprints). At the end of every iteration we should have something which is useful that we can release for customers to use if we whnt. This means there is the potential for a very quick return on investment, as we can release earlier than when using the waterfall approach. Additionally, Agile builds momentum within a team as the short iterations impose a rhythm of continual mini deadlines, keeping the team moving forward at a consistent yet productive pace.
It all sounds great, but there are a number of pitfalls you need to watch out for when project managing or program managing teams using Agile:
Because we have working software at the end of each iteration, the temptation is to release it as soon as it’s “good enough”. I don’t necessarily disagree with this as it’s probably the quickest way to deliver business benefit to the organisation, however, once we have something “good enough” in the marketplace, the temptation is then always to introduce new stories containing new features, rather than taking the time to make what you already have exceptional.
If you choose to repeatedly release software that is just “good enough”, then make sure you haven’t just happened into this behaviour and that you are doing this deliberately. Ensure you understand the impact this “good enough” software is having on other parts of the business, along with impact on top line revenue.
Ask any software architect and software team to design you and build an end to end system and inevitably they will begin by designing the core components and services of the system. In my experience, they then make these components high quality (and who doesn’t want solid foundations) before thinking about building the user interface. How can you build the UI when you have no framework in place? They then build the UI and release it when it good enough (see point 1), sometimes before if the pressure from the business is strong enough.
I would argue that it makes more sense to build the UI first and make that of exceptional quality, whilst stubbing out all the underlying core services. In this way the UI can be exceptional (which is typically what the Agile customer wants first and foremost in my experience (note that my background is consumer facing software)) and the underlying core and common services can then be started, with everything being released when the core services are “good enough”.
This may sound counter intuitive but there are some advantages to this approach:
I’m not saying that my approach is always right, but I am trying to make you think before you jump in and start building the system/platform.
Agile was designed by developers and as such it sees the world from a developer’s point of view. When organisations adopt Agile, all too often the good bits of using waterfall are thrown out along with the bad. Examples of this include concepting with users, design work, and some documentation. The Agile Manifesto states, “Working software over comprehensive documentation”. Many developers use this as an argument to produce no documentation. I really encourage you to use some common sense here in the projects you manage and not accept that things like important documentation don’t get done just because it is written.
As I stated at the beginning of this post, I’m a fan of Agile as it does offer businesses some tremendous advantages. Fellow project managers and program managers, the above pitfalls should serve as warnings that Agile, like any other methodology, is not without its traps. I hope that the above gotcha’s can help you get your projects or programs off on the right foot from the start.