Looking at Why Agile Works Tells You How To Make It Scale

Recently, I have found myself engaging in conversations with clients who are new to adopting agile and are struggling with how to get started, especially in a large-scale, enterprise context.

I don't find myself talking about which agile method they should adopt. Rather I focus on why agile works.

The reasons are simple, but that doesn't stop the principles from being highly disruptive to the waterfall command-and-control way of thinking. Even adoption of simple principles requires a radically different mindset.

 IT organizations don't have to adopt agile methods whole to start using these principles. sure agile methods are battle tested, and you work in particular contexts, but adoption can seem overwhelming.

I encourage clients who aren't willing to take the agile plunge to take a look at some of the simple but disruptive principles and see where they can introduce one or more to their organization. 

1. Replace Stage Gates with Regularly Scheduled Cadence
2. Describe Planning Units As Increments of Business Value, And Treat Them As Atomic Units That Can Be Designed and Delivered Independently
3. Limit Consumption of Demand According to the Capacity of Workers to Satisfy That Demand
4. Use Visualization to Make Sure That Everyone Understands What the Processes Are, and Where the Current Work Fits into That Process
5. Invest Both Time and Capital To Improve the Way Work Is Completed

Replace Stage Gates with Regularly Scheduled Cadence

Stage gates are the familiar command-and-control waterfall tool of choice of to ensure high quality and stable delivery. Work cannot proceed until the entire batch is deemed to be of sufficient quality to proceed to the next stage. This in theory prevents defective work from proceeding to the next stage, and helps mitigate delivery risk.

The problem with stage gates is that they actually reduce the amount of quality reviews and inspection done for projects that really require it.

Take 2 programs, the first program contains healthy projects, the second one unhealthy project.

In the first program projects produce good quality work, projects almost always made it clear to stage gates on time, and pass on first review. This means that the stage gate reviews happens relatively frequently across the program.

Now let's take the second program, unhealthy work causes the projects to hit delays. These delays in turn cause stage gate reviews to be delayed for the projects within this program. This means that stage gate checks for the program actually happen less often.

Any process that mandates less checks for an unhealthy project versus more check for a healthy projectis inherently flawed. 

The answer to this is favoring cadence over a state gate approach. A cadence is a regularly occurring event, and is at the heart of the iterative model inherent to agile methodologies like scrum and extreme programming.

Transforming a waterfall process into an iterative one end to end may be more disruption than many IT organizations can bear.  

Rather than trying to reengineer the entire process, a simple fix is to mandate that all work in process within a particular stage should be reviewed at a regular cadence by required governance folks and/or downstream knowledge workers. 

Eventually knowledge workers can start categorizing work into  two clumps, work that can be moved into the next stage, versus work that is not ready to move into the next stage. 

Suddenly knowledge workers come to the realization that work that is ready can proceed to the next stage can do so, leading unready work behind.

Putting regularly scheduled cadence reviews can be the first step towards getting to to smaller batches of work. 

Whenever I see any stage gate process in a delivery model, I tend to recommend leaving it relatively intact,except that I replaced the stage date with a cadence review.

Describe Planning Units As Increments of Business Value, And Treat Them As Atomic Units That Can Be Designed and Delivered Independently

Agile methods force teams to look at planning from a different perspective. You are expected to create plans out of small, stable, atomic increments of business value. 

• Being small means work can be effectively estimated. 
• Having business value means that completing work is a great way to measure progress 
• Being atomic means that work can be built and given to the client by itself, you can get toto business value sooner.

Most agile methods  express this concept in user stories, I personally like the Kanban approach of taking the types of work that are already recognized by the delivery organization, and gradually coaching teams towards expressing these in smaller, atomic units of work

As stated above, creating small atomic units of work facilitates movement of those pieces independently of each other, this makes iterative and/or flow-based development much easier.

Limit Consumption of Demand According to the Capacity of Workers to Satisfy That Demand

Agile teams that ignore this principle are not as successful as they could be. Even very effective agile teams run into trouble when they have a very large backlog of work.

If the release plan contains over 2 years of stories, chances are that there is enough upstream churn to affect the overall success of the agile team. Regardless of how good their velocity or quality is. 

Getting to business agility requires that everyone asks the question "when can I actually complete this" when considering looking at new projects.

Getting management, stakeholders, and even knowledge workers to understand the toxic nature of inventory can really be a challenge. One that I struggle with every day.

Use Visualization to Make Sure That Everyone Understands What the Processes Are, and Where the Current Work Fits into That Process

Fog of war is probably the most serious impediment to effective knowledge work. I don't think fog of war requires a large team to take effect.

I find after a team size of 2 to 3 people it becomes challenging to understand what other people are doing to the point where it interferes with good teamwork. 

Agile planning boards, Kanban systems, and other information radiators are an excellent example of how to combat this fog of war. 

An entire agile method does not need to be adopted to start taking advantage of these information radiators.

Invest Both Time and Capital To Improve the Way Work Is Completed

While I have stated this one last, it's probably one of the most important if not the most important of these principles. This is something I continue to struggle with both for my own work, as well as how to get teams that I coach to effectively do this.

Of course agile and lean methods have plenty of tools to address this, from retrospectives, to operational reviews and the A3 process. 

Different approaches can be used, such as explicit periods of time for improvement events, a minimum inventory level for improvement were tickets, or a commitment to complete all improvement activities after they are raised. 

What is important is that taking time to improve performance should not only be tolerated, but mandated. 

The point here is that agile organizations are adaptive, they continually change the way they work, because the investment always more than pays off in the value produced. 

I'm sure I've missed a few important principles, and I'll add to this list as I ago. Everyone out there feel free to contribute.