Best Practices are Still Best Practices

I do a lot of consulting on the adoption of agile management techniques. What I keep seeing are the same issues popping up time and time again. While lots of good information has been circulating about agile project management for the past decade or so, misperceptions abound.

One problem that I find puzzling is the frequent appearance of misunderstandings about the need for “best practices” on agile projects. Yes, agile methods promote different techniques for requirements management, scope management, estimating, scheduling, communications, and quality management. However, these techniques are not new – many were developed in the middle of the last century and have been often used on large, complex projects. Agile management frameworks simply gathered together the existing “best practices” for complex or high-change projects. So, saying that agile methods are not “best practices” is false – agile methods are one set of “best practices” for managing projects with certain common characteristics.

This battle between factions with their own methodology preferences does not surprise me, however. The issue that really puzzles me is the confusion over best practices for project startup.

In most organizations, there are certain management control points (also known as “stage gates”) to manage the funding allocations and project approvals. Usually it follows a pattern something like this:

• Someone comes up with an innovative idea and presents it to management to get approval to spend some time and money thinking through the concept and coming up with an initial guess at what the business case might be. The management approval to spend that time and money doing the investigation is called ‘Passing through Gate 1.’
• Next comes the development of the initial business case. This will include high-level numbers, many of them educated guesses or placeholders for items where further research is needed. This initial business case is taken for review by a funding committee who determine if the benefits of the idea adequately exceed the costs of implementing the idea. They challenge some of these initial business case assumptions, and may discount the benefits or increase the costs in order to reflect their confidence in the ‘guesstimates’ used in preparing the figures. The committee may decide to stop further investigation into the idea, or may provide further funding to build a ‘real’ business case that contains numbers with something behind them other than a best guess. Such as decision passes the idea through Gate 2.
• Once through Gate 2, the goal is to do some up front work to see if a project is truly feasible. This work includes gathering and documenting high level requirements, performing initial analysis, high-level design of a solution, documenting scope, preparing effort and duration estimates, building an initial implementation schedule, and documenting estimating assumptions. In essence, preparing a traditional project proposal. This proposal is again presented to a funding body that makes a decision whether to proceed or not with the project. Approval means passing through Gate 3.
• Finally, the project can begin for real, with the detailed requirements analysis, detailed solution design, refined estimates and plans, and validation of assumptions that happens at the start of a complex project. There may be a pilot or proof of concept phase that may validate the estimates and plans (and ultimately the business case costs) with real metrics captured from the proof of concept. If such as proof of concept is reviewed and approved before a project can proceed in full, it is called passing through Gate 4.

There is a lot of misunderstanding about where agile management techniques fit into this model. For an agile team to come up with its initial list of scope (expressed as ‘user stories’) there needs to be some requirements capturing and analysis and some high level solution design work completed so that the project team knows the solution for which they are providing development estimates. And, these estimates feed the construction of an initial schedule, called a ‘release plan.’ This work needs to get done in an initial iteration, often called ‘Iteration Zero’ or ‘Sprint Zero.’ If you think about it, you’ll see that this is the work we normally do to pass Gate 3 – the development of a proposal for funding of the development work of the project.

Some individuals have misunderstood how agile projects work in the real world. They believe that the project should start immediately with developing a solution in the first iteration. Some even say that doing up front analysis and design is going against agile principles. This could not be further form the truth. No matter whether you are following serial/waterfall-type management methods, or agile management methods, the work that needs to get done at the start of a project does not change – best practices are still best practices. You cannot build a plan (even an agile one) without some estimates. And to estimate, the team members need to understand the scope they are estimating to build, and some characteristics of the architecture/design of the solution. And who can prepare a scope and design without knowing at least the high-level requirements? The difference is not in the nature of the work that needs to be done, but rather in the level of detail needed in this first instance. Most serial/waterfall teams will do much more analysis and design work in this initial proposal phase than agile projects, mostly due to the difficulty of incorporating changes later in the serial/waterfall processes. Oddly, the business cases for serial/waterfall projects still often present ranges in their budget and schedule estimates, even with the extra analysis and design work that is usually done.

Regardless, best practices declare that some up-front work needs to get done before estimating and planning. Both agile and serial/waterfall methods require that this work get completed before the real solution development work begins. Many agile teams seem to forget or deny this and end up in trouble. Unfortunately, I find too many of them in my troubled project recovery consulting work. This is not a flaw in agile project management methods, but rather one in maturity in understanding the nuances of how agile methods get deployed in real-world scenarios. Classroom learning is not enough – for initial attempts and using agile methods, organizations need some agile-experienced help to coach the teams through the process.

Kevin Aguanno is an Executive Project Manager who is certified by IBM, PMI, and the IPMA. He is a specialist in troubled project recovery and in agile project management methods, authoring many books on the topic. He is also the editor of the AgilePM Newsletter (www.AgilePM.com).