The Agile Practitioner: Agile Projects

The traditional approach to project management has been to identify goals and then map out the steps required to achieve them. With steps identified, dependencies are assigned and time to complete each step is estimated. The result is usually some variant of the well-known Gantt chart.

From this point, the Gantt chart is used (sometimes) to track actual progress against estimates. If you have ever used this method, then you, like me, have experienced the inevitable slippage in the schedule as it was originally defined. Having managed projects my whole working life, I can think of only one that got done early. A few were on time, most were later than originally anticipated.

Smart people will add a buffer to the final deadline, but quite often that gets consumed as well. Agile practitioners tend to scorn the venerable Gantt chart. It stands for the old “waterfall” way of doing projects, i.e. plan everything out and then work the plan.

Scope Versus Time

The fundamental flaw with the traditional approach to project management is that both the time permitted and the scope of work are fixed at the beginning. This is like selecting a box and then filling it with what you think you will need. Inevitably, you will realize that you forgot something, but with the box already full, there's no room to add the missing items. Rarely will you be removing items from the box that you thought you would need but didn't because you don't find out you don't need them until the end of the project.

The Agile approach to this problem is to require that one of these parameters be allowed to float. If the deadline is critical, then the scope will be allowed to adjust to meet it. A minimum acceptable scope is defined that is well within reach of the deadline and this scope is attained first. Then, the remaining time is used to achieve more of the goals for the project. When time is up, the project is over and whatever scope has been delivered is considered a success.

If the scope is critical, then time is allowed to float and the project proceeds until all the goals and objectives have been achieved. Of course, this requires great patience on behalf of stakeholders waiting for project completion. The good news is, Agile work is delivered in small increments, so some value should be provided well before the project ends.

The Tyranny of the Unknown Unknown1

Donald Rumsfeld made famous the 1955 work of two psychologists. It is known as the Johari Window. Although it was used in a self-help context at the time, Agilistas often invoke this concept when discussing estimates. The things we know are easy to estimate. The things we know we don't know are a bit harder. But, the things we don't even know we don't know are impossible to estimate.

The impact of these unknown unknown “things” could be trivial or massive. Recognizing this, people doing the initial design of a project with a hard deadline will attempt to minimize the risk of unknown unknowns by utilizing tried and true practices, techniques, tools, and/or approaches. They will focus on delivering the riskiest parts of the scope first if possible, so that plans can be adapted early in the project rather than later. Delivering incrementally usually affords this option.

Smashing Boulders

Since Agile practices are an outcropping of Lean thinking, much of the same rules apply. Despite some shared product development practices, software development has some fairly unique characteristics that other types of product development don't share. For example, the only critical commodity in software development is time. If you were designing a car, your prototypes would require materials, some or all of which would be scrapped if you started over. Not so with software. Starting over costs mostly time (and possibly some hosting fees if you use cloud services)…and even that is debatable (I could, and may, write a whole article on refactoring).

This fact has caused some in the software development world to believe that incremental delivery means that EVERYTHING about the project is delivered incrementally. One can take incrementalism too far. For example, one thing that should be considered in toto before beginning to create actual software is architecture. This is especially true if the system being built is complex, requires adaptability, or serves an evolving purpose. Good architecture is difficult to do incrementally.

Imagine you were going to build a skyscraper, but you didn't know how many floors you were going to build when you started. Someone has to make a decision about the composition of the foundation. Not having an overarching architecture will almost certaining result in a foundation that is either too big and expensive or will limit the number of floors that can be constructed. Such is the case with lack of or bad architecture.

The challenge is to strike a proper balance. In much the same way the planning for a traditional project begins, Agile projects start with goals. Next, a set of high level elements are defined to achieve said goals. These are often called epics or boulders. Boulders can be rough sized to provide an “order of magnitude” estimate for stakeholders.

After the boulders are sequenced, only the first one or two are broken down into detailed work. In some cases, boulders are broken into smaller boulders that are sequenced and only broken down into work details one or two at a time.

The purpose of only breaking down the work incrementally ahead of actual execution is to mitigate the tyranny of the unknown unknowns. These discoveries can have a major impact on the work that follows. When they do, it is less likely that they will impact the project at the boulder level, so planning work is not wasted. Furthermore, commitment to a predetermined plan can cause team members to force fit the existing path even when it is no longer optimal.

The Cost of the Do Over

One of the ideas central to Agile practices is the notion of refactoring. Simply put, refactoring is either reworking or rewriting code to benefit from discoveries made along the way or remove technical debt incurred in the name of speedy delivery. Technical debt is the name given to compromises in coding that allow value to be produced more quickly for the system's users while making future system capabilities more difficult or impossible to achieve.

The choice to incur technical debt is often made because a premium is placed on learning from actual users making real use of the system. The quicker the team can get to this stage, the more likely the end product will fulfill the users' requirements for it. The result is doing things with full knowledge that they will either need to be redone or reworked.

The challenge teams face is deciding whether to include technical debt work effort in the project or defer it until after the project is delivered. These choices are usually made on an individual basis based on a number of criteria.

There are many other factors that fall outside this list, but these tend to be fundamental to all decisions about how to handle technical debt.

The Buffer Bank

One idea that we are using at ITHAKA is called the buffer bank. Each boulder (we use the term epic) is initially estimated. When we break the epic into individual user stories (the increment of work that delivers specified value to users), they are assigned “story points.” Story points (or just points) are usually based on a fibonacci numbering sequence starting with one. These numbers are not a straight proxy for time as they also include factors for complexity and unknowns. Ultimately, as a measure of effort, in aggregate they provide data that suggests how long work will take. As stories are created and sized with points, the points are deducted from the original estimate for the epic.

As the buffer bank is consumed by actual planned work, we can gage the accuracy of the original estimate. This allows the team to adjust either the scope or timing of the project, depending on which one is floating.

Therefore

Agile project management is not an excuse to forgo planning or architecture. Those who make this claim are misrepresenting the purpose of incremental delivery. The traditional “work breakdown system” (WBS) is flawed because it assumes that the team will be able to anticipate every detail of the work required to achieve the goals of the project. This is almost never the case — especially when it comes to developing complex software.

I leave you with this thought. It has been said that the genius of Steve Jobs was his ability to see past what people asked for in order to give them what they actually want. Sony asked people what they wanted and they said they wanted smaller discs, so their devices would be more portable. Steve Jobs gave them the MP3 player. Given the differences in a project to deliver minidisc players and MP3 players, one begins to understand why too much upfront planning will limit your ability to deliver the right value to the customer. Learning as you go is always a better idea.

Tom Bellinson

Mr. Bellinson has been working in information technology positions for over 30 years. His diverse background has allowed him to gain intimate working knowledge in technical, marketing, sales and executive roles. Most recently, Mr. Bellinson finds himself serving as a Scrum Master for ITHAKA, a global online research service. From 2008 to 2011 Bellinson worked with at risk businesses in Michigan through a State funded program which was administered by the University of Michigan. Prior to working for the University of Michigan, Mr. Bellinson served as Vice President of an ERP software company, an independent business and IT consultant, as chief information officer of an automotive engineering services company and as founder and President of a systems integration firm that was a pioneer in Internet services marketplace. Bellinson holds a degree in Communications with a Minor in Management from Oakland University in Rochester, MI and has a variety of technical certifications including APICS CPIM and CSCP.