The whole concept of Agile was designed to prevent project bloat. Back in the 1990’s when software development and deployment projects became mega projects a little too easily, the notion of Agile became much more popular.
We’ve all heard about Agile. The idea that we’ll develop incrementally in sprints and after each sprint we should have deployable code, each time with a bit more functionality.
It’s a great idea.
We use Agile project management within our own development at HMS. Using this methodology we can take an elephant sized project and gradually consume it one bite at a time.
But to make this work, there are some assumptions in the background that you can’t lose sight of. We assume that as we’re eating the elephant, no one is substituting an additional, larger elephant each time we go to our list of things to do. In Agile, this list is called the backlog and we tend to think of the backlog as a constrained list.
But who in your organization is in charge of constraining it?
One of the great things about Agile is that it’s, well, agile. It allows the project to maneuver in different directions based on how the project evolves including how the users react to the early iterations of the code being released.
That’s awesome (really, it is), but this is just the formula that can result in the dreaded scope creep. As feedback arrives to push the functionality one way then the other, a few things become easy to forget about:
Who is doing the creeping?
Firstly, the very people giving feedback are probably the very people who helped with the original design. It’s not uncommon to have people respond in one way while a project is more theoretical and a very different way once they can see it. The budget for the project which is likely to have gone through a whole process of tradeoffs and prioritization is built around those theoretical decisions, not the more immediate reactions to things from the field as the project is actually underway even if the people who did that budgeting and the people who are making these new requests are the same people.
Is everyone still on the same page?
It is common to be more expansive in ensuring that a project has all the design requirements built into it when it’s first budgeted. Perhaps someone from Finance was tasked to ensure a particular link would work and that the data would have been validated in some way. Then someone from Payroll was tasked to review the design and make sure the payroll rules were followed. But as the project gets underway, it’s often difficult to ensure that all the people who worked diligently on the design at the beginning are still giving the project the same level of attention as it is being coded in an Agile methodology.
There’s not a single simple answer to how to avoid these types of pitfalls. But blissfully moving on in an Agile world without thinking about some of the constraints and assumptions that other aspects of the business are counting on can lead to problems.
Our experience has been to institute a few checks and balances to projects:
Communicate
First of all, communication is key and by communication, I mean discussion. We have seen projects where there was some upset at deployment and someone says “Oh that was in the June email last year” and, sure enough, there the change is, buried on page 12 of an email with many topics in it. So, we’ve come to do more discussion of requested changes before they end up in the backlog.
Estimate
Sometimes a request from the client or user will seem like a tiny impact in terms of developer hours but we have found some things that seemed easy to change in the code can cause enormous heartache in downstream processes and user impact. So, we ask that estimates include not just coding time but impact on QA both now and for future versions, upgradeability, backwards compatibility, documentation and future technical support. Often an original estimate of a few hours becomes days or weeks long when we shine a light on all the other work involved.
Corporate memory
We have had to take the responsibility of being the corporate memory on numerous projects. That’s often because our team is quite stable and client teams often change faster. So, even with lots of documentation and email threads and communications plans. We are often the ones who say “You might remember that the reason you said last year that you wanted to do this in this way was because of this.” Find someone who will be the anchor for the corporate memory.
Project Management Best Practices
Even while the Agile group is evolving the project in great strides, don’t abandon your basic project management principles. Did you have a budget? The project charter? Approved design? Progress milestones? They can be even more important at one level when Agile is involved at another.
Like all things, Agile has pluses and minuses. I always recommending taking from these methodologies the practices and processes that work for you in your particular environment. In most organizations I’ve worked with, this usually means an environment with processes culled from several different methodologies.
