I have been reading a lot about of the recent group discussions and papers regarding Kanban and Lean Software Development. One of the things I have noticed is that there is not a consistent application of the concepts regarding time. One of the reasons we establish a body of knowledge is to create a common language that helps us communicate based on a shared understanding. This inconsistency in the use of terms around time create a gap in understanding. In an effort to help the conversation here are the appropriate definitions for each type of time.

Durations

Duration is simply a measure of elapsed time.

Lead Time: The average time it takes for one unit to go through the entire process – from start to finish – including time waiting between sub-processes. Lead time can take different perspectives.

Development Lead Time is the time it takes for a unit to go through development from release from the backlog until it is done (which includes analysis, development, test, acceptance, deployment – but maybe not release to production). It is interesting to the development manager.

Order Lead Time is the time that elapses between when the customer places an order and when the customer receives what they ordered. In cases where requests are queued in a back log and releases are decoupled from development completion this can be far longer than the Development Lead Time. This is interesting to customer.

Order to Cash Lead Time is the time from when the customer places the order to the time cash is received by the business. While this is often longer than the Order Lead Time it can be shorter than the Order Lead Time when the customer prepays. This is interesting to the person paying the bills.

Process Lead Time: The time the unit is being worked on in a specific process before it is passed on to the next process. For example, within Development Lead Time this could be analysis, development, automated test, acceptance test or deployment time. This is interesting to the person performing the specific process or activity.

Processing Time: The time the unit is actually being worked on. It would be the sum of all the Process Lead Times. This is interesting to use as we try to improve our Lead Time.

Value Add Time: The Processing Time spent on a unit that transforms the unit in a way that the customer is willing to pay for. Not all Processing Time is Value Add Time – although non-Value Add Time can be necessary due to compliance requirements, to optimize performance of value add resources, and to minimize rework. This is interesting as it has been the subject of much of the lightweight process effort in Agile development. When taken to far it results in increased Rework Time and increased Process Lead Time.

Rework Time: The Processing Time that results from poor quality.  Failure Demand is the amount of resource that is consumed by Rework Time. This is interesting as it is expensive.

Queue Time: The time a unit sits between sub-processes waiting for someone to work on it. This is interesting to us as we try to improve our Lead Time. This is no cost to improving flow to reduce Queue Time but it reduces Lead Time.

Cadences

Cadence is a measure of time per unit.

Cycle Time: The average time between units coming out the end of the pipe. This is interesting because it helps us predict Lead Time.

Takt Time: How often units need to come out the end of the pipe to meet customer demand. This is interesting because it reflects the rate we need to produce to optimize investment against revenue.

You would expect Lead Time to be the sum of Processing Time, Queue Time, and Rework Time – and it is in a purely serial process flow. But in cases where work moves in parallel the sum of Processing Time, Queue Time and Rework Time will be greater than the Lead Time. Lead Time is interesting because it is what we use to make commitments.  Improving Lead Time can be done by reducing Queue Time, shortening Process Lead Time, eliminating Rework Time, minimizing non-Value Add Time, and performing processes in parallel.

The concept of Value Add Time is interesting and has had strong impact on Agile processes. At some point things like documentation, planning, testing, and adding additional features are not adding value in a way the customer is willing to pay for. Reducing these items to the bare minimum time that is necessary to meet the needs of the customer is helpful. Reducing them to the point they increase rework or reduce the productivity of the value added performers is not helpful.

The biggest inconsistency I have noticed is the improper use of Lead Time (a duration), Cycle Time (a cadence), and Takt Time (a cadence). In summary, Lead Time is how long it takes us to build and deliver it, Cycle Time is how often a new one is produced, and Takt Time is the rate of customer demand. In a stable system, Duration and Cadence are related by Little’s Law. The cadence of Cycle Time will equal WIP divided by the duration of Lead Time.

I believe that consistent use of these terms will help us have more meaningful conversations and continue to improve the ways that we deliver software to our customers. Part of my focus over the last decade has been on reducing Lead Time through reducing WIP, Queue Time, and non-Value Add Time, improving quality to reduce Rework Time, and improving architecture, automation, and shared understanding to reduce Processing Time. Having a shared understanding for each type of time leads to productive conversations around specific techniques and improves the teams ability to focus on the right types of improvements.

There is a nice summary of Kanban at http://www.kanbandistilled.com/. It shows Feature Requests going into the Software Development Pipeline and Improved Software coming out.The article does a great job of showing how Kanban helps improve the flow of software development. Getting better at software development is important and Agile methods have been helping teams achive this goal. This is the first bargain of Agile-delivering software faster and with much higher quality then ever before. In most organizations however, this is only a small part of the business equation. Even when development is successful, a narrow focus on software  development narrows the value an organization will achieve. We also need to align of development with the most important needs of the business, balance development with adoption, and ensure improved business performance is achieved.

Feeding the Software Development Pipeline

Unless a company is a software development service provider, its business is not about software development. Software likely enhances the businesses ability to create value for it’s customers. So, while Agile development helps teams get better at software development – the goal is to get better at creating value for it’s customers. The focus of Agile software development is upside down. The focus should be on the capabilities of the business. Aligning development with the needs of the business requires understanding  which business capabilities will benefit from improvement and prioritizing these needs based on business value.

After using a business capability approach to need identification and prioritization, the business needs must be appropriately scoped and communicated to development. Over the last month I have been writing about Making Agile Requirements Work. need to make sure the requests that go into the Software Development Pipeline are clear and appropriately defined. Following the six principles of Agile Requirements That Work help with this feeding of the Software Development Pipeline.

1. Articulate Purpose and Outcome
2. Establish a Shared Language
3. Provide a Stable View of the Business
4. Support Progressive Elaboration
5. Testable
6. Prioritized and Reflect Business Value and Risk

Gaining Business Benefit

The other part of the equation is to ensure the organization adopts and supports the improved software. Once the Software Development Pipeline has produced Improved Software, it still isn’t valuable until the Business Capability has achieved the intended performance improvement. Just as the elicitation and analysis of requirements has to match the cadence and needs of Software Development. Software Development has to match the cadence and needs of the organizations ability to adopt and support Improved Software. Part of the overall feedback to the organization includes ensuring the capability improvement is achieved.

Risk

At every step in this equation different risks may exist. identifying, prioritizing, and scoping feature requests have risk associated with a lack of understanding. Software Development has risk associated with the Ability to Execute and Verify the delivered software. Benefit realization has risks associated with achieving adoption and being able to sustain and support change in the organization. These risks should be explicitly managed and feedback mechanisms should be in place to recognize the realization of risks. Failing to understand and manage risks in an integrated fashion will also diminish the organization’s ability to maximize benefit from it’s investment.

The Real Agile Bargain

The real agile bargain is the maximizing of economic outcomes by increasing the speed and focus an organization can improve and respond to the market. The Agile Business Value Equation is solved at the Business Capability Level. The ability to rapidly develop high quality software moves Technology from a change obstacle to become an change enabler. This happens at the intersection of Feeding the Software Development Pipeline, Developing the Software, and Gaining Business Benefit. Solving any of these parts independent of each other does not result in optimizing business agility.

The Gilb’s have started a series of posts against Agile. The first on is Wrong Focus.

“It is not about working software. It is not about your preferred working process. It is not about user stories. It is not only about your customer or user. It is all about delivering, to your set of Stakeholders, value improvements to them, to what they care about, what makes their world better, within agreeable, minimum or pre-determined costs. If that is not the main focus, if that is not clear to everyone on the team, you will eventually loose! If your methods are not focusing on delivering that value, as todays most popular Agile methods are not, they will fail to deliver, they will become last years fad.”

They claim Agile software development is flawed because it focuses on improving the process and environment of the team developing software. These improvements result in improved customer collaboration that ensures the team better understands what the customer wants. From my experience, the combination of improved environment, appropriately sized process, and customer collaboration results in mature agile teams doing a great job of delivering the projects and products. But I understand their point. There is a difference between understanding the customer and focusing on delivering customer value.

Wrong Focus

Whether the software development organization is building software for external clients or to enable the organization’s business processes, there are always more things that can validly be improved than there are resources to do the work. Not all of the improvements will result in the same return of business value to the overall organization. Some benefits are more valuable to the organization than others. If you don’t pick the one that is most valuable to the business it is not the right investment for the business. In any of these improvements, there is more improving that is valid than is necessary to achieve the benefit. If the team works on improvements that aren’t the focus of the effort, “while they are there”,  they are not focusing on business value. This delays delivery of the effort and is not the right investment for the business.

Nothing in the Agile Manifesto, nor most of the Agile methods, give the tools to pick the right improvements to focus on. They also create an environment where it is extremely likely to work on more then is the minimum necessary to achieve the targeted business benefit. In many organizations, close customer collaboration can lead to “gold-plating” of features. If you offer the customer whatever they want – they will ask for it.

Wrong Focus in Practice

I have a customer right now that is going to build some software to support their field employees. The business goal is to achieve a significant cost reduction in the field through improving quality and efficiency in the field. The developers are extremely interested in developing mobile applications, distributed collaboration, GPS interfaces, image capture and markup, mapping, barcode, and training training. They have started a new business to build this product with the hope of selling it outside the business in the future. The challenge here is how do they clearly identify those improvements in the field and in dispatching that will deliver the significant reduction in field expense. If they go and and talk to the dispatchers they might find 30 things that could be done better. All of these improvements would result in an improvement in work conditions or performance. But they may not be aligned with the current business focus. The same will happen in the field.

Just because it will improve satisfaction or make someone’s job easier doesn’t mean it will help with the current business focus. How do they align absolutely the minimum amount of technology to deliver on these improvements? Especially when their interests are in this bigger, more robust solution. Especially when this limiting of features is not in line with their future business objectives. Nothing in Agile addresses how to deal with this conflict.

Where’s the Answer

I address this in Feeding the Agile Beast. This is the domain of Business Analysis. As the Gilb’s point out, most Agile methods abstract this from the team. They focus on improving their processes and collaboration. In Scrum, Business Analysis is abstracted behind the Product Owner. In XP, it is abstracted behind the Onsite Customer. I don’t agree with the implication from the Gilb’s that this abstraction is a deficiency in Agile. It is just outside the scope. I also don’t agree with Agile teams that close collaboration with the customer is sufficient to ensure business value is achieved. This is not an OR conversation. This needs to be handled as an AND conversation. This is the next thing we need to learn – how to keep an Agile team laser focused on business value AND maintain the benefits of understanding the customer that comes with Agile software development.

The problem with many current methods of Elicit Requirements on software development projects is that they don’t add economic value to the solution effort. Many projects develop unrealistically detailed requirements in large batches up front. Due to the impossibility of accurately defining exactly what the effort requires they aren’t completely useful. In addition to resulting in churn and rework they require a high level of effort to maintain. In response to problems with Big Up-front Elicitation efforts some projects have resorted to “too little” requirement definition up front. This also results in expensive churn and a lack of project focus that delays the time to value. In both cases the transaction costs associated with producing and maintaining the documents offset any value they might bring.

The How Trap

The How Trap is a very human condition. If you see someone at the fax machine and ask them what they are doing, they will say “Sending a Fax”. That isn’t what they are doing though. That is “how” they are doing something – not what they are doing. The How Trap is very common. Ric Merrifield, in his book Re-Th!nk: A Business Manifesto for Cost Cutting and Innovation talks about Dick Fosbury and the Fosbury Flop. Dick Fosbury realized the How of the high jump was to go as high as possible and abandoned trying to perfect any of the existing techniques that involved jumping over the bar so you could land on your feet. His focus on the What of jumping as high as possible led him to jump over it backwards and land on his back. His gold medal in the 1968 Summer Olympics pointed out the wisdom of his approach. When requirements are elicited on a How-Trap basis assumptions are made that limit options that should be considered to accomplish the goal of the effort.

To avoid the how trap elicit requirements based on outcomes and purposes. Avoid getting trapped in How specific language. You can be pretty specific about the purpose or outcome without falling into non-productive detail. For example, the outcomes and purposes associated with Pay Employees doesn’t change much regardless of the implementation. People need to be paid a specific amount, there are specific tax requirements, and there are clear governance and compliance needs. These don’t change whether Pay Employees is outsourced, done manually, or automated internally.

Remember Fosbury’s goal was not to jump higher it was to clear the bar at its highest point. Sending a fax is never the requirement. It is something like Communicate Status or Confirm Order. This is a subtle distinction but frees up the team to apply their creativity to the How and will lead to significantly different outcomes.

This is the final post in my review of the impact of Agile on the tasks within the knowledge areas of the BABOK®.  There are some interesting findings from this exercise. The implications are that while some business analysis tasks are performed within the development team, the business analyst role itself is more strategic and challenging on agile projects. A clear understanding of the BABOK tasks and how they should be addressed on Agile projects will dramatically increase your ability to deliver value through Agile projects.

So, What’s New?

First off, the business analysis tasks are not just aimed at documenting requirements. There are three primary targets of analysis activities. Many tasks address the features of the product. These are aimed ensuring requirements are elicited, communicated, and the solution is verified. There are business analysis tasks aimed at understanding organizational readiness and transition requirements. Finally, there are business analysis tasks aimed at understanding and improving the ability of the organization to develop and deliver the solution.

Secondly, all the tasks are still necessary. However, unlike a traditional project, where many of the analysis tasks are performed up front, they are performed continuously throughout the project. The requirements for the solution, the ability to deliver, and the readiness of the organization are evaluated incrementally throughout the project and the approach is adapted to improve fit and performance.

Finally, the understanding of requirements, organizational readiness, and development capabilities is progressively elaborated throughout the project.  In Agile, the development team itself performs detailed business analysis activities within the development iterations. The business analyst continues to operate in front of and after the development efforts. Lightweight requirements documentation combined with an emerging understanding means the business analyst become an advocate for the product. They collaborate with the team to ensure a shared understanding unfolds. The business analyst also facilitates the understanding and implementation of improvements in the business analysis and organizational readiness processes.

Summary of Business Analysis Knowledge Areas

Business Analysis Planning and Monitoring.  The tasks in this knowledge area are still primarily performed on the front end. The team will agree on the approach it will take in business analysis tasks. This means agreeing on who and how. All the task purposes in the BABOK still need to be planned – but planned to support the cadence of the team and the emergence of understanding through the project. The way the business analysis tasks are performed are not cast in stone, they will be updated through inspection and adaptation throughout the life of the project.

Elicitation. This knowledge area occurs continuously in a progressive fashion and responsibility for the product requirements changes hands during each iteration.  These hand-offs associated with the various levels of elicitation can contribute to lost knowledge and increased transaction costs.  An approach that ensures continuity of understanding is critical.

Requirements Management and Communication. The existence of Requirements Management and Communication in a single Knowledge Area demonstrates the closely held traditional belief that documenting and tracking something is the best way to communicate it. It is important that the method of documenting requirements at the higher level is lightweight while still facilitating understanding, focus and priority. In Agile projects, communication should be viewed as completely distinct tasks. At the detailed levels, there is a transfer of context, purposes, and outcomes requirements that is best performed through conversation between the customer and the development team.

Enterprise Analysis. The business analyst will still carry primary responsibility for understanding organizational readiness, transition requirements, and solution verification.  They will need to communicate findings from releases back into transition requirements to improve release performance. Gaps in the fit of the solution will feed back into the requirements backlog. Enterprise Analysis is very strategic, outside the scope of the typical Agile development team, and critical to the successful realization of business value.

Solution Assessment and Validation. These tasks happen continuously in a progressive fashion. The Big Solution Architecture will still be developed with input from the Business Analyst as well as Architects. The Business Analyst will need to understand and address the impact that progressive elaboration has on the transition requirements.

Requirements Analysis. Prioritization and organization of requirements happens as part of backlog prioritization. The business analyst should make sure that business value concerns and risks associated with assumptions and constraints are clearly understood here. Like Enterprise Analysis these tasks are very strategic, often outside the scope of the typical Agile development team (presumed to be understood by the Product Owner), and are critical to the team’s ability to burn down risk early and get to business value fast.

Missing Tasks

I believe there are at least three areas regarding business analysis on Agile projects that are not addressed by the BABOK.

Enrolling Stakeholders involves making sure everyone understands how they will participate. Just documenting a process or developing some templates don’t ensure appropriate engagement.  Stakeholders may play a role making sure shared understanding of the product requirements exists, they may be responsible for development process feedback, or they may need to participate in the transition of the solution.

Understanding Requirements is the new task or set of tasks that deal with generating the shared understanding of context, purpose, and outcome that is necessary for successful projects. Since the understanding of what is being developed and how it is being developed will emerge over the course of the project specific tasks must be in place to establish this shared understanding.  This may sound like a subtle extension of communicate requirements but this is social in nature and is fundamentally different than the push of communicating requirements.

Organizational Learning extends Enterprise Analysis. Not only does the readiness of the organization to use the product need to be reviewed, the ability to develop, deliver, and support the product needs to be evaluated. This task includes the introspection, retrospectives, operations reviews, and outside review of best practices that the organization performs to improve its ability to use and deliver solutions.

Agile Business Analysis Summary

The common concept that Business Analyst’s add no value to Agile projects is flawed. It is true that some of the detailed business analysis activities will be best served through direct interaction between developer’s and the customer. The high level planning and coordination around these direct interactions should not be abandoned but should be managed to facilitate focus on business value and shared understanding while minimizing transaction costs.

Additionally, there are many critical business analysis tasks outside the scope of the development team. Particularly, the tasks involving Solution Validation, Enterprise Analysis, and the inputs to Requirements Analysis are very strategic, outside the scope of the typical Agile development team, and critical to the successful realization of business value. A clear understanding of the tasks and purposes in the BABOK® demonstrates the strategic nature of Business Analysis tasks, highlights where the tasks should be performed within the Agile development team, and will increase the ability of the development team to achieve its objective of rapid delivery customer value.

Today I am discussing the tasks from the BABOK® associated with Requirements Analysis. These are the tasks to organize, prioritize, and model requirements and risks. There are six tasks associated with Requirements Analysis. I show the BABOK purpose. Then I discuss the impact on who and how in projects leveraging progressive elaboration, incremental delivery, close customer engagement, ongoing learning, and self organization.

Prioritize Requirements

Organize Requirements

Specify and Model Requirements

Define Assumptions and Constraints

Verify Requirements

Validate Requirements

Agile Requirements Analysis
All of the tasks in Requirements Analysis are important on Agile projects. The primary distinction in this Knowledge area is the support for the emergence of the solution over time. Particularly interesting is Define Assumptions and Constraints. While many Agile teams focus on the impediments to delivering code, they fail to manage the bigger risks and constraints associated with getting to business value.

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.

One of the hot topics at Agile 2009 was scaling agile and the Agile Enterprise. As we work toward a book on Big Agile:  Incremental strategies for Enterprise Agile adoption I want to establish a clear definition on what I mean by enterprise Agile adoption and what the Agile Enterprise is.

First off, The Agile Manifesto really applies to software development. Small Team Agile is about getting teams together to develop software in a way that meets certain criteria. Agile teams operate as a healthy team and they reliably deliver a continual stream of high-quality valuable software. Valuable means that it serves some purpose for the customer. There are engineering practices, management practices, and leadership practices that combine together to enable Agile teams to be successful. A key benefit of Agile teams is that you can produce the most valuable features first, and continue to invest until the economic value of the code has been realized. Agile teams are different then most traditional software development teams because of the focus on small incremental delivery of always releasable code and the focus on pushing decision rights down to (empowering) the team.

Scaling Agile

I believe there are four distinct levels of Agile adoption. This is not four maturity levels. It is distinct levels where the engineering, management, and leadership capabilities express themselves differently to support the expanding context. In most organizations the scaling will not be linear – it will be implemented across these levels of scaling based on the needs of the business.

Horizontal Scaling is the first level of scaling. This is the ability to get multiple teams to deliver a continual stream of high-quality valuable software. What happens when you begin to have the ability to spread Agile across teams is you begin to have the ability to strike a new bargain with the business. You can help product management interface with the business and customers in a new way where you can be responsive to individual customer requirements and changes in preferences in the market.

First Order Scaling is where multiple teams are coordinated across a common project or product. Once you have teams reliably performing, a new level of coordination arises. Your constraint is no longer in the pace of development. New opportunities to exploit speed and responsiveness arise across product development are possible. Taking advantage of these new opportunities requires the engineering, management, and leadership practices to be expressed in new ways. For example, Architecture becomes more important from a common perspective. Agile, this raises the ability to strike new bargains with the customer. Complex projects can be developed in a more responsive fashion.

Second Order Scaling is where multiple teams are coordinated across multiple projects and products. This is where you may begin to see economic benefits from reuse across products. The new bargain you strike with the business is now at the portfolio level. The business can be more flexible in investment into products and projects and then shift to other efforts when the economic benefit has been maximized.

Third Order Scaling (the Agile Enteprise) is where the Agile Enterprise exists. This is where the business leverages the ability to continually deliver high quality valuable products beyond the product development effort. New bargains can be struck in Customer Service, Sales and Marketing, Invoicing, and every customer facing part of the business. Faster learning from the market, customer preferences, and other environmental inputs is leveraged to rapidly produce products that profitably adapt to what we learn.  Other internal functions are also impacted. In fact, third order scaling often comes into play in even Small Team Agile. Once you can benefit from (or have to take into account) making changes to the way value is delivered to your customer beyond the product development organization, you need to think about Third Order Scaling.

Big Agile and Orders of Scaling

Scaling Agile has different meanings depending on the respective scale. From effective small teams, to reliable small team adoption, through products, portfolio’s to the organization -the focus is on achieving scale appropriate outcomes and purposes while maintaining focused value creation at the Agile team level. You can’t execute an Agile strategy from the top if you can’t first operate in a reliable agile fashion at the small team level.

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.

I am always interested in researching existing Frameworks and Models. Today I am talking about John Boyd’s O-O-D-A model. O-O-D-A, or Observe-Orient-Decide-Act, is part of the basis for the Marine Corps Doctrine of Maneuver Warfare – the doctrine that shaped the strategy applied in Operation Iraqi Freedom.  This model is interesting because it has been applied in multiple environments to help achieve many of the things we are looking for in Agile Enterprises. It is a framework for exploiting uncertainty in the environment. It not only enables but depends on a reduction of command and control. And as a knowledge framework pattern it can be applied to small teams, products, and organizations.

O-O-D-A talks about gaining an advantage by operating inside the decision cycle of your competition. This is desirable because the faster we can learn what to deliver – and the faster we can improve our ability to deliver what is needed – the more effective we will be. If we can to this faster than our competition, we can be successful in our market.

A Knowledge Framework for Exploiting Uncertainty

The model is pretty simple. It describes a decision loop. We Observe the unfolding environment, noting mismatches between what we think it should be and what is actually happening. We Orient our mental model to what is actually happening. We Decide what is important; what our options are for acting and form a Hypothesis for our action – including how we will measure the outcome. Then Act according to the decision. Action tests our hypothesis, hopefully moves us toward our goal, and changes the environment we are observing. This takes us back to the beginning.

At a more complex level there may be multiple decision loops overlapping in your environment. The Decision process may bring up possibilities that send you directly back to Observe. And we maintain guidance and control over the entire process.

This model looks a lot like our Agile development cycles.  Every time we visit the backlog we are basing our selection on what we currently understand. New events in the market, what we learned from our last iteration and new ideas all impact the backlog. We decide what is most important, build it in small increments, and then test it against our understanding. O-O-D-A in action.

Reduce Command and Control

Top down command and control not only doesn’t support this approach, it hinders it. We need each team make their actions serve the strategic intent in terms of what is to be accomplished. The teams need a wide freedom to exercise their imagination and initiative in terms of how intent is to be realized. Teams have freedom to self-organize, but freedom within the strategic framework.

According to Chet Richards, who wrote “Certain to Win: The strategy of John Boyd applied to Business”,

“It is not more command and control that we are after. Instead, we seek to decrease the amount of command and control that we need. We do this by replacing coercive command and control methods with spontaneous, self-disciplined cooperation based on low-level initiative, a commonly understood intent, mutual trust, and implicit understanding and communications.”

The secret is in the clear communication of intent – coupled with discipline on the part of the performing team. Again, this is completely aligned with what we have found works in Agile development.

Scaling to the Enterprise

As a knowledge framework O-O-D-A has been shown to work at the small team level. It also works at the product and the Enterprise level. For example, since October of 2001 there have been 19 releases of five different IPod models. This rapid cycle of release allows Apple to Observe the unfolding environment of customer preferences and emerging competitive products, Orient their product direction, then Decide and Act in a faster decision cycle than any other player in the market. Apple excels in all four activities and this garnered 90% market share and a continued advantage over the competition.

What is particularly interesting is that this framework scales up better when it is modeled at lower levels. Apple is able to release product faster because they are good at developing software rapidly. At the Enterprise level, effective Agile development allows us achieve the four strategies of Agile Portfolio Management Jim Highsmith wrote about last week:

1. focus on strategic advantage projects,
2. keep projects short,
3. re-align portfolios quarterly,
4. implement value-driven success criteria.

Enterprise Agility

I think this is a useful model. It is not a process model like Lean. It is not a capability model that is limited to a single domain like development or projects management. It is a model that helps us think about and improve knowledge work. Like Agile, O-O-D-A helps move faster by incorporating learning with action. Like Agile, O-O-D-A operates best when teams are empowered and highly disciplined within clear strategic guidelines. I believe that, like O-O-D-A, the principles of Agile can be scaled to the Enterprise to create competitive advantage.