If we accomplish one thing in Big Agile, we hope it will be to provide a way for people to think about what they are doing and create a learning framework for being able to do it well and take it to scale.

We don’t want to try to present the one right path you have to follow – because we think each situation will require distinct strategies.  But we also want to get beyond the intuitive approach. Just saying, “Eliminate waste, identify and remove impediments, and write code better” is not enough guidance to create a reliable and sustainable approach that can be scaled .  So, what is a structured way to think about being good at Agile that supports getting big? Part of the answer is to focus on outcomes and purposes using capabilities. But how do we apply these and where do we start?

First off, teams are the organizational units that actually produce value.  So  getting small teams highly productive is the right place to start.  Then, as we scale, the principles that make the small team function well scale into different instances of the same principles. The objective is to add the least amount of overhead possible at each order while maintaining the productivity of the small teams.

Today, I present the (draft) Big Agile Learning Framework. This reflects the approach  I have intuitively used when approaching this problem. The three dimensions are Value, Velocity, and Context.  The capabilities of the organization operate together in an interdependent way.  Understanding how each one plays in this model, and how they impact each other, is a key to developing situation specific strategies for taking Agile to the Enterprise.

The Big Agile Learning Framework

Value, Velocity, and Context

Value: What the product development team provides back to the business that the business might sell to an actual customer.

When we look at value, we want to identify what Jack Welch called the value nub – the intersection where low-cost and just-the-right-features intersect. Moving up on the value axis means moving towards the nub. In Agile, we leverage the ability to get a working product to the customer frequently to continue to narrow in on the value hub. This helps us reduce the costs and risks associated with a granular up  front requirements effort.

Velocity: The rate that work is moving toward its objective.

Confusion over the distinction between speed, utilization and velocity is a common problem. Velocity is speed in one direction. The car driving 60 mph on a straight road has much higher velocity than the one going 60 mpg on a winding road.In Agile we increase velocity through finishing what we start, coordinating hand-offs to remove delay, improving quality, and continually removing waste from our processes.

Context: The environment that the team operates it. It is shaped by the team, the organization, the goal of the effort, and the sphere of influence of leadership.

Software development is a knowledge-based endeavor.  People need room to think and innovate.  Difficulties in the context can compromise efforts to improve Value and Velocity. In Agile we improve context through commitment to a productive environment, empowered teams, disciplined compliance with the team standards, working toward individual mastery, bringing in external knowledge, and managing expectations.

Each of the dimensions in the learning  framework are interdependent. Let’s take the capabilities around requirements as an example. In once case, we put in an up front focus on detailed requirements. We think they are perfect and they take a long time. So the capability is high on value but low velocity. As we move along on the project, errors in the original assumptions and evolving customer preference degrades the actual value, moving the capability down on the value axis. If we take an Agile approach, Agile recommends a lightweight, progressive elaboration approach to requirements. This would be farther right on the Velocity axis but potentially not as high on the Value axis. Over time, as we uncover specifics and move towards the value nub, the capability raises on the value axis. We also know when to stop adding things not valued by the customer – so we don’t begin to slide down the value axis again. Experience in software development shows this is effective, but the organizational context has to allow for this approach.

The Thinking Framework is a way to frame the development of strategies as we scale. As we develop situation specific strategies to scale Agile the way that we can impact Value and Velocity become more complex But keep in mind that we must not sub-optimize small team productivity. Top down approaches have not been consistently successful in scaling agile up into the enterprise. Just replicating the same practices up through the organization hasn’t worked either. Basing our work on capabilities and leveraging the thinking framework, we are able to develop appropriate strategies.

You may already know that Mike Cottmeyer and I signed a contract to produce a book that describes situation specific approaches to scaling Agile in the Enterprise. This book is based on the work Mike and I have done over the last 10 years or so in helping organizations improve their ability to deliver value to their customers. While we have done the customer engagements separately, we think about this in a similar way and have been able to consistently deliver results to our clients.

Mike and I need to write about 157,000 words over the next 9 months to produce the content for the book. We will be blogging most of the ideas as we write the book and really look forward to your comments and feedback on our approach. Learning to tell the story so it resonates is really important to achieving our goal of writing a book that is very valuable to managers in organizations who are facing the Scaling Agile challenge.

Common Capability Model

A Capability is “an ability or capacity the organization relies on for a specific purpose or outcome”. We focus on capabilities because we are initially interested in What and Why, not on How. Getting caught up in How without clarity on What and Why is common in methodology debates. We Call this the “How Trap”. Using a capability analysis approach we have been able to get people out of what we call the “How Trap” and get them thinking about purposes and outcomes.

As a core part of communicating how managers can develop situation specific strategies for scaling Agile, we are building out a common capability model. Why not use an existing model? Well, we are working from the understanding that there is no single model that is outcome/purpose focused that can be used to build out the scaling. We need to build that base – not by recreating it from scratch but by building on top of traditional models that have worked at the enterprise level, like CMMI and PMI, as well as Agile approaches that have worked at the team level like Open RUP, Scrum, and XP.

As I introduce this capability model, I will start from a Scrum/XP perspective even though those methods are based on practices and not Capabilities. For example, iterations in Scrum and short releases in XP are about Limiting Work in Progress. So is incremental development in Open RUP. I will introduce the Big Agile Capability Model in terms of  Agile practices. I will show how they are complementary to the traditional models and how this outcome-based understanding helps us develop a situation specific approach to scale. Finally, I will talk about common dysfunctions in organizations that limit effectiveness.

Capability Analysis

I have been working on this consolidated capability model for a few years. At a number of clients, I have used an approach based on a consolidation of CMMI, OPM3, XP, and Scrum. More recently I have included Kanban and the Open RUP in the model. At higher levels of scaling I rely on some other capability models like the Process Classification Framework, ITIL, Pragmatic Product Management, and the Business Architecture work I did at Microsoft. The goal is always to find a way to talk about outcomes and purposes before we talk about implementation.

The trick is in translating these jargon specific detailed models into something straight-forward that facilitates the development of situation specific strategies for scaling Agile. This is a challenge that Mike and I are working through now. Before everyone pukes on the idea of basing our approach on a capability based model, I want to cover a couple of important things.

First, I am not a big fan of staged models. I get the concept of CMMI’s levels of maturity – it is important to establish maturity in the lower level processes to gain benefit from the higher level processes. But I believe an organization can make progress on higher-level processes while they don’t have all the lower level processes in place. The capabilities are interdependent and so can’t be addressed in a linear manner.

In OPM3, the model is not staged. You pick an area of focus, such as project cost or program risk, and the model will walk your though capabilities related to that strategic area. Like OPM3, our model is not staged or prescriptive in nature. We talk about these in an order, but in reality, the team needs to be focused on improving capabilities based what makes the most sense for a specific situation.

Second, I don’t like the idea that Product Development, Project Management, and Software Engineering (http://www.dennisstevens.com/2009/03/12/project-management-product-management-and-agile/) are evaluated separately and independently of other the rest of the organization. They are too tightly integrated in real life once you get past the small team to be treated separately. At the end of the day, there is no point in getting better at any of these areas if it doesn’t result in an improvement in delivery of value to the customer.

Finally, one problem I have with formal capability models in adoption is that these models come off as overly complicated, prescriptive, and aren’t typically treated as situation specific. Typical models drive the conversation, “What do I have to do to pass an audit”. We want to change the conversations in the business to, “What is the next most important thing we can focus on to improve our ability to deliver value to my customers”.

The Big Agile Capability Model

The model that Mike and I are working on starts with Small Team Agile. We build this out to Horizontal Scaling, where you have multiple teams doing Agile development on distinct outputs. Then we build out to First Order Scaling, where multiple Agile teams are working together on a single product. At Second Order Scaling, multiple Agile teams are working on multiple products. At Third Order Scaling, we are working to leverage the ability to rapidly deliver working software across the Enterprise. Wrapped around this is a set of common capabilities that apply to every level of scaling. Over the next several days I am going to describe the capability model we have derived from our experience and research. As with everything else in the book, this model is subject to change.

I am going to describe the Small Team agile capabilities over the next few days. Over the next few weeks, I will go into the capabilities associated with Horizontal scaling, then First Order, Second Order, and Third Order scaling.

As we go through our approach, please share your thoughts – good and bad – with the approach and how it is being communicated. We need to make sure this is valuable contribution to the body of works hoping to improve our ability to deliver high quality products that meet the needs of customer.

I want to share the presentation I did in the Open Jam at Agile 2009. I got good feedback from some of the thought leaders there like David Anderson, Chris Matts, Eric Willeke, Chris Shinkle, and Mike Cottmeyer.  Ok, enough name dropping. A common theme at Agile 2009 was, “Now that we are pretty good at small teams developing software, what’s next?” One of the answers is making sure the developers are working on the stuf that provides the greatest value back to the organization. A lot teams aren’t very good at this.

If your projects are anything like most of the development projects I’ve been on you are likely to run into cost and time pressure near the end. Our story might be something like, “We can’t meet your needs for the planned cost or by your expected time-frame. We have been telling you from the beginning there was uncertainty in the requirements and that development is fraught with risk. You will just have to pony up.” Customer’s don’t like this but they have come to expect teams to be late and over budget.

If you had the foresight and tools to understand how to focus on eliminating risk on the front end and then building the highest value things first, you can go to your customer with a story like this, “Even though there is a lot of uncertainty in the requirements and exactly how we would build the software, we have a working product that meets all of your most important business needs. In fact, I bet you didn’t know that over half of all the technology built is never even used in the end. We would love to continue to build out the remaining features after we get this adopted by your customer, but we bet addressing what they think is important will be more valuable than building out elaborate and potentially unused features.”

I have used this approach on about a dozen efforts and have found that it promotes far better communication between the team, product owner, and customers. It provides clarity on what needs to be build, why it needs to be built, and how we can do acceptance testing on what is built. It is also low friction to maintain if the product or project strategy changes in flight.  It is a sustainable artifact that connects Ivory Tower discussions about business value and risk to the developers context.

Typical Business Analysis techniques have high transaction costs and high coordination cost while still not getting the key points across to development. We end up with lagging risk, too much rework, missing critical requirements, lack of testability, and over engineered products. This is very expensive – both in terms of what is spent to deliver to our customers and in terms of meeting the needs of the customers. Once we change the conversation from “What can we get done this week?” to “How can we optimize business value and manage risk responsibly?” we are on the right track to Feeding this Agile Beast.

Something I find interesting is the push back I hear from agile developers that process discipline will inhibit their creativity. They say, “Software development is a creative activity. If you put process rigor around it you will inhibit our creativity.” I have heard others complain about applying Lean concepts to software development. “This isn’t manufacturing,” they say, “There is no place for standard work in what we do.”

Non Sequiturs in Software Development

These statements are examples of the non sequitur fallacy. A non sequitur fallacy is where the argument is false because the conclusion (rigor will inhibit creativity) does not follow from the initial premise (software development is a creative process). We see examples of non sequitur’s every day. We see them in advertising. For example,

“Buy this car and you will be more appealing to the opposite sex”

This isn’t a true statement. The car won’t make you more appealing to the opposite sex. We may want to be –  so we believe it. But this is a logical fallacy because the conclusion (you will be more appealing) actually has no cause and effect relationship with the initial premise (Buy this car).

In fact, it is because software development is a creative process and because it isn’t manufacturing there there are a whole set of processes that must exist to drive value. It is important to focus creativity where it adds value. It is also important to create an environment where creativity can be harnessed. You may not be able to create standard work around domain specific problem solving, but I contend that the higher the level of process discipline in the team, the more reliably developers will  deliver value. Further, I believe that the lack of discipline in the following process areas is the key contributor to poor performance – particularly in new agile teams.

Areas Where Process Discipline will Drive Value

To make my point, I am going to discuss four processes areas where process discipline to the point of standard work will improve the delivery of software. “Standard Work” is defined as a simple written description of the safest, highest quality, and most efficient way known to perform a particular process or task. It is agreed by the team to be the only acceptable way to do the process it describes. It is expected to be continually improved.

This is not an exhaustive list of the processes areas where discipline is required. These are process areas that are critical to teams, regardless of your flavor of agile: quality, learning and feedback, collaboration processes, and flow management.

Quality: The purpose of Quality processes is to create an environment where it is safe to pursue creativity in domain specific problem solving. Quality processes ensure the resulting product meets the needs of the customer and supports the goals of the development team. Effective Quality processes result in a net improvement in time to value delivery. Test Driven Development, Continuous Integration, Use of Patterns, Configuration Management, and Coding Standards are examples of Quality processes. Quality processes don’t hinder creativity. Just as in manufacturing they enhance the ability to leverage creativity to deliver value.

Feedback and Learning: The purpose of Feedback and Learning processes is to inform the team about how they are performing and to identify where constraints to their performance exist. Armed with this information, the team takes corrective action to avoid problems and overcome impediments. They also identify improvements that increase their ability to deliver value. Feedback and Learning processes include maintaining Burn-down Charts, Cumulative Flow Diagrams, and Kanban Boards and performing Retrospectives and Operations Reviews. Because software development isn’t manufacturing, constant feedback and the resulting learning is necessary to ensure the Agile team is improving (or at least maintaining) its ability to deliver value to the organization. Feedback and Learning processes also provide the ability for teams to creatively improve their performance.

Collaboration: The purpose of Collaboration processes is to ensure the team has a clear understanding of what they need to deliver and have a shared understanding of the dependencies within the team. Effective Collaboration processes will dramatically improve the teams ability to create value. Sprint Planning, Daily Stand Ups, and Story Reviews are examples of Collaboration processes. Clearly, adherence and process discipline are necessary to ensure a team if performing effectively. Strict adherence to Collaboration processes does not restrict creativity.

Flow Management: The purpose of Flow Management processes is to prioritize work for the team to optimize value and to throttle the amount of work that is active within the team to optimize productivity. Management also uses Flow Management processes to understand where the business stands on commitments to stakeholders and customers. Setting Milestones, Iteration Planning, Backlog Grooming and setting WIP policies are examples of Flow Management processes. As we learned from manufacturing, following these processes with discipline can dramatically improve the rate and amount of value the team is able to produce. None of these processes restrict creativity.

Process without Purpose is the Culprit

When pursued with the appropriate purpose, process does not inhibit creativity – it enables creativity. Many of the processes and techniques that have proven to be valuable in manufacturing have also demonstrated tremendous benefit in software development organizations. The “bad-taste-in-your-mouth” feeling that developers get when discussing process discipline and standard work is the result of process for the sake of process. Don’t let that feeling sway you from putting appropriate process rigor into place. Remember, “Software development is a creative process. If you put process rigor around it you will inhibit our creativity” is a logical non sequitur. Process discipline and standard work are not inhibitors to creativity, they are enablers.