Posts Tagged ‘Theory of Constraints’

Big Agile Adoption Approach

Posted on October 5th, 2009 by Dennis Stevens  |  1 Comment »

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.

capabilitymodel

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.

Theory of Constraints and Big Agile

Posted on September 17th, 2009 by Dennis Stevens  |  3 Comments »

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.

TheConstraint

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.