This post is going to go back over the past month’s posts and bring them together into a model I can use to discuss Big Agile. I took me a while to noodle this out so I haven’t posted in over a week. This approach is based on over two decades of improving performance in development organizations. The last decade has been spent working to explicitly articulate what I’ve done to consistently deliver results. It is amazing how much you learn when you take concepts practiced unconsciously and write them in a (relatively) concise format.

Enterprise Agility

Many companies are dependent on technology to be competitive. Either because they deliver technology as their product or because technology enables the processes they depend on. For those companies it is important to be able to operate faster than their competition.  This requires not only the ability to rapidly deliver technology – but the ability to adapt their organization.  This is the concept of operating within your competitors decision cycle. The model I use to demonstrate this concept is John Boyd’s O-O-D-A model.

This is Enterprise Agility, when the enterprise has learned to leverage technology and change management to develop an energized workforce frequently delivering value that meets the emerging needs of the customer.

Three Concepts for Achieving the Agile Enterprise

I am going to build on three concepts in showing how to build Enterprise Agility.

1. Theory of Constraints. You can’t get there all at once. It is necessary to decide where to focus. You have to develop the underlying capabilities from the bottom up. If you can’t produce quality product, the best ideas in the world will run into problems. The way of thinking about problems covered in the management system the Theory of Constraints provides the method for deciding where to focus. Identify the current constraint, get the most out of the capability that is the constraint, subordinate the system to the constraint, elevate the constraint, and then continue to pursue this cycle. This “Process of On-Going Improvement” is applied to the flow of value to the customer.

2. Creative Solution Finding. Once we understand where to change we need to understand what to change to. We have to apply a method to lead the overall adoption effort that supports aligning the capabilities with the overall goals of the organization. The stages of Creative Solution Finding are useful for identifying the situation specific approach to developing this road-map. There is no magic sauce for developing this road-map. By applying the seven principles, along with a knowledge of applicable best practices, a useful road-map that fits both the process and social context of the Enterprise can be developed.

3. The Learning Organization. Technology development efforts are knowledge based efforts. As such, they are performed through a social construct. To improve the performance of software development we have to not only improve the methods of development, we have to improve the performance of the social construct. First the individuals on the team must be willing to change. While the People Design principle in Creative Solution Finding will help prepare individuals for change, their personal fears and concerns must also be addressed. Once the constraint is identified and a road-map for improvement is developed, the learning organization concepts in the Fifth Discipline are relevant. The right individual competencies must be developed on the team to do the job (Personal Mastery and Mental Models).  The team has to be functioning well together (Shared Vision and Team Learning).  And the Team has to be functioning in a way that is aligned with the goal of the overall system (Systems Thinking).  The primary tool used to influence a social construct to create change and to improve performance is the conversation.

Discussing Big Agile

So the approach is to take the Big Agile capabilities, (1) provide insight to identify when a specific set of capabilities at a level of scaling are the current constraint, (2) leverage the solution finding model and best practices to define/refine the roadmap to move toward,  (3) and then identify the competencies to develop and conversations that are necessary to execute the change.  Then continue the cycle continuously.

This is the Big Agile improvement approach. It takes a model that I have been applying for two decades implicitly and evolving explicitly for the last decade. Clear direction combined with appropriate best practices and an effective adoption approach. All that’s left now is to build out the details of the capabilities, when they are a constraint, how to select appropriate best practices, and the conversations and change approach at each level of scaling for the model.

In 1984, Eli Goldratt first published The Goal: A process of ongoing improvement. The book describes the Theory of Constraints, a method for managing systems. It is based on the concept that at any time in a system there is one (of very few) bottleneck(s) slowing down the performance of the system. Performance is measured based on three variables. Throughput measures the units delivered to the consumer of the system. Operating expense is investment into the system to ensure its operation on an ongoing basis. Inventory is investment into the system to produce.

The Goal is to make more money now and in the future in order to meet the expectation of stakeholders and ensure the business continues to operate.  You increase profit by combinations of increasing throughput while decreasing the ratios of operating expense and inventory against throughput. A key first step to accomplish this is to reduce inventory – or work in process. This will improve cash flow of the organization. Reducing WIP has the added benefit of exposing the bottlenecks in the system. Exposing these bottlenecks is the key to implementing POOGI (Process Of OnGoing Improvement). Goldratt provides five focusing steps to follow to help achieve the goal.

Five Focusing Steps

Identify the limited number of current constraints: At any point, there is a single point in the system that is the current bottleneck. For example in Agile development teams, it may developer productivity or a testing person.  The way that you will identify the constraint is that it is the person where work is piling up in front of them and where downstream resources are starved for work. In the figure below the constraint is B. Work can only get through B at 3 units per unit of time. Since A is more productive work will pile up in front of B and C will be starved for work.

Two important concepts need to be presented here. The first is that the team of ABC can’t produce work any faster than the bottleneck, B. So the consumer is only receiving 3 per unit of time. The second really important concept is that A, B, and C don’t have to be different people, they can be state transitions of a piece of work. In an Agile team, A might be understanding the requirements, B might be develop and unit test the code, and C might be integrate and acceptance test. On an Agile team, everyone is involved in all the states, it is the work that is moving through various states.

Make sure output from the constraint is not compromised. The second step in the five focusing steps is to recognize that the work done at the bottleneck is precious and must be exploited. So focus on making sure that none of B’s work is wasted. In our Agile example that means improving the quality of how work is communicated in the transition from A to B. It also means focusing on quality at B so that C is able to use everything produced by B.  Doing this step will result in improved performance of the system.

Subordinate the system to the bottleneck. This means slow down the work at A. While this might seem counter-intuitive B can’t work any faster than it can work. Often, manager’s focus on improving utilization rather than throughput and this focus actually exacerbates the problems. Producing more and more inputs to B creates stress on the people in the system, makes the system more difficult to manage, and increases the likelihood of waste at B. In our Agile example, A can spend more time clearly communicating what needs to be built and less time producing more detailed stories. A may consist of meetings where stories are communicated, estimated, and prioritized. On our Agile team, it is consuming time from the team that could be spent at A. So do less detailed estimating and prioritizing in each cycle. The effort is better spent at B.

Elevate the constraint. In many organizations, when the effort is to elevate performance of a system (or team) investment is made to elevate the entire team.  In our example above, that may mean adding more subject matter expert resources as well as more testing resources. But the only benefit to improving throughput of the team in our example is to increase at B. Elevating the constraint can happen through improving the capabilities at B or shifting more manpower to B. In our Agile example above, it may be better to shift one of the testing people to focus on development. Even if they are initially not as productive as the top developers, they will contribute to elevating the constraint without damaging the throughput of the team.

After the system has stabilized go back to the beginning and identify the constraint. The final step is really to not let inertia become the constraint. Remember, this is POOGI – a Process Of OnGoing Improvement. You don’t go through the process once – you go through it continually.

Theory of Constraints and Big Agile

This model is very interesting because if provides a thinking process for focusing efforts on the next most important problem. If our Agile team example above, if this model is not kept in mind by the team, they may spend time putting in a cool new CI environment – but unless that environment raises the constraint at B it will not result in an improvement. So it isn’t the next best place to focus. The other interesting thing about this model is that it scales up through the organization through the orders of scaling. If you haven’t read The Goal and Goldratt’s other writings you need to get this model into your thinking toolkit.

Today, I am looking at the Learning Organization model Peter Senge presents in “The Fifth Discipline”. This model is interesting because there are strong corollaries between the way effective Agile teams form and the Learning Organization. The book is called the Fifth Discipline because it describes five disciplines that build on each other: Personal Mastery, Mental Models, Shared Vision, Team Learning, and the Fifth Discipline is Systems Thinking.  I am going to briefly describe each discipline and how they apply to the Agile Enterprise.

Personal Mastery

Senge says Personal Mastery “goes beyond competence and skills…it means approaching one’s life as a creative work, living life from a creative as opposed to a reactive viewpoint.” In Agile, this means being very good at what you do. If you code, you should aspire to be a great coder – but not just a coder. Great Agile teams depend on Generalizing Specialists.  This means that you have one or more specialties, you have general knowledge of product development, you have general knowledge of your  business domain, and you actively aspire to improve your specialization while broadening you general knowledge.

Personal Mastery doesn’t just apply to development. It applies to all aspects of the business. Seeking personal mastery improves the performance of the team in two ways. First, each individual is competent to perform their job. Second, they are better able to understand and meet the needs of the people they work with.

Mental Models

Mental Models are a way to describe a person’s intuitive perception of the world around them.  We make decisions in order to achieve some result from the options we perceive based on our Mental Models. Learning occurs when we observe the result of our decision in the real world. If we don’t get the result we want, we will try something different. In Agile we call this Inspect and Adapt. Because you can represent this as a cycle it is also known as single loop learning.

One of the key challenges to successful adoption of Agile is changing Mental Models. This is because many Agile principles aren’t intuitive or are counter to traditional management approaches. Some of these initially counter-intuitive principles include:

• Starting more stuff faster means you will finish more stuff later.
• Striving for perfect definition up front is going to slow down delivery.
• Don’t build everything that might ever be needed right now – only build what you will need today.
• More testing speeds you up.

Changing Mental Models creates new possibilities and allows us to make better decisions. We allow the results to influence our Mental Model and not just the next decision. When learning influences our Mental Model we call this Double Loop Learning. Personal Mastery can bring in outside influences and open our eyes to improvements in our Mental Models.

Shared Vision

Shared vision describes the common understanding the team has of where they would like to be and how they would like to interact in getting there. This shared vision exists whether the team makes it explicit or not. It can just be assumed from the larger organization or it can be intentionally managed by the team.  Intentionally developing a shared vision, or shared Mental Models, about how to work together effectively and what needs to be delivered to the customer is a powerful approach to improving team performance.

In Agile, many of the practices support creating an effective shared vision. The product vision, release schedule, and backlog create a shared understanding of where the team is going.  Frequent delivery, continuous integration, daily sprints, focus on quality, co-location, and constant customer interaction all support a shared vision of how to deliver.

Team Learning

Team Learning is the next step after Shared Vision. In Team Learning, the team works together to improve their ability to achieve the Shared Vision. Individual Skills may have to be developed. Mental Models regarding how teams perform may have to be changed. The Shared Vision may be updated as the team acts and responds to feedback based on their efforts.

Agile has a number of feedback tools and learning opportunities built in. Burn-down charts, Swarming, Transparency, Sprint Reviews, and Retrospectives represent things Agile teams use to learn how to improve their collective abilities. In Agile we call Team Learning self-organization.

Systems Thinking

Systems Thinking is a framework for understanding that the component parts of a system can be better understood in context with each other, rather than in isolation. A core concept of systems is interdependence, the concept that the actions of any component have the potential to impact other components.

In Agile, the concept of interdependence is used to overcome the linear nature of Waterfall and over-specialization.  Rather than isolate requirements, design, development, and test into separate functional teams, Agile recognizes the interdependence and brings all the skills and competencies necessary to deliver product onto a single team.

Systems Thinking and the Agile Enterprise

Systems Thinking and the Agile Enterprise is very interesting. First, because it gives a model to follow for developing individuals and then teams into a functioning Learning Organization. Unlike software development models, Learning Organization efforts are written by people specializing in change management. So there is a substantial body of knowledge about creating this type of change up to the Enterprise level.

Secondly, development is just one component of the larger Enterprise system. Getting better at software development doesn’t always result in an improved delivery of value to the customer. There is a lot to learn through applying Systems Thinking as a problem solving tool in establishing the Agile Enterprise.