PART II: Understanding of the investment side of agile
After half a century in the making, the traditional program and project management theory looks better than ever — well understood, ubiquitously trusted, battle-tested and continuously fine-tuned to perfection. As long as your desired outcome (scope) is well understood, and your constraints (quality, time and cost) are agreed-upon upfront, it will get you to your destination safe and sound. The definition of success is clear and simple — deliver the desired outcome with minimal variance to the constraints.
All good, but what if the desired outcome is not well understood, like in the case of agile development? What do you agree to? What variance do you care for? How will you know if your program succeeds with stars or is about to fail spectacularly? This is the dilemma most business, capability and IT leaders face when they are about to scale up their agile programs.
In Part I of this article, we introduced key roles and operational principles necessary to effectively manage enterprise-scale agile program investments. In Part II, we will discuss related common practices in the financial services industry and their potential pitfalls. Let’s start with defining the key investment components of a typical agile program:
- Agile, Core represents the effort and expenses for activities that are directly controlled by agile teams. They typically include analyze, design, build, test and release tasks.
- Agile, Noncore refers to the effort and expenses for activities that are not directly controlled by agile teams, but performed by their members. Examples include assistance with environment set up and management, test data collection, cross-team coordination, support for ad-hoc requests to perform activities not directly related to the scope of their current sprint workload.
- Enabling refers to the effort and expenses incurred outside of agile teams. Examples include program and project management and reporting, architecture, infrastructure support, change management and deployment.
Most executives are painfully aware of the tremendous effort that goes into the planning cycle to determine which IT projects should be funded and prioritized. One of the goals of the agile approach is to optimize the amount of effort and time spent for planning by keeping the estimation rigor proportional to the confidence in inputs, like the business need, scope (desired outcome), constraints (quality, time, cost) and dependencies. Among many variations in style, I see two distinct estimation patterns in practice:
- The first pattern favors control over agility. It requires a traditional bottom-up project proposal estimate from each program team (agile and enabling), for the elaborated agile scope. These organizations often end up operating a waterfall-style enterprise program under the disguise of the "agile" brand name.
- The second pattern fully embraces the agile principles. Followers of this pattern size the agile team effort by using story points first. Then they calculate the required capacity for enabling teams using a predefined formula, often a simple multiplier.
Sign up for Computerworld eNewsletters.