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.

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.

There continues to be discussion about Scrum (as a brand) vs. Kanban (capital K) vs. Crystal vs. FDD, etc. If fact, I received a comment today on a March post discussing the Scrumbut test. My comment became to long and is so relevant to recent discussions that I turned it into a blog post. From my perspective these method wars tend to fall into “How Trap” discussions. How Trap discussions are not about specific outcomes you are trying to achieve and developing a situationally specific approach to achieving those outcomes.

Take a look at the Scrumbut test I learned about from Jeff Sutherland. Whether you are doing (or even like) Scrum – when viewed through an outcome lenses, these questions lead to discussion regarding clearly important outcomes. Below, I list the question category from the Scrumbut test, then the outcome that is desired from the practices described in the Scrumbut test, then a hopefully clarifying description.  The practices are detailed at the Scrumbut link.

Question 1 – Iterations: Limit Work in Process – don’t start anything you can’t finish

Question 2 – Testing within the Sprint: Maintain Code Quality – Shorten quality feedback loops to zero to maintain code quality and reduce the waste of rework

Question 3 – Agile Specification: Communicate Business Needs to Development – Ensure developers understand outcomes while minimizing coordination and transaction costs, maintain traceability to business need

Question 4 – Product Owner: Maintain Product Roadmap – The business communicates a plan of what is being built

Question 5 – Product Backlog: Prioritize Investments Based on Return – the business prioritizes work based on a current understanding of business value

Question 6 – Estimates: Provide Meaningful Effort Estimates – Understand rate the team can produce work to support planning, investment decisions, and customer commitments

Question 7 – Burndown Chart: Communicate Release Schedule – Be able to predict content and timing of future releases. This clarifies corrective action, next most valuable investment decisions, marketing decisions and customer commitments

Question 8 – Team Disruption: Maintain Productive Work Environment – Management understands and supports the focus on rapid delivery. Trust is established that the team will be able to meet current and future commitments.

Question 9 – Team: Develop an Empowered Team – The team feels empowered to make decisions about how to move forward. Management has provided sufficient guidance and direction that they trust the team will make operational and tactical decisions aligned with the best interest of the business.

Yes, Jeff has a brand he is protecting. If you think you are doing Scrum and you aren’t achieving these outcomes then you aren’t doing what was intended. Bad Scrum and Scrumbut hurts the Scrum brand. In fact, since Scrum is a dominant Agile brand, it hurts all of us trying to move Enterprises towards improved software agililty.

But, Scrum isn’t the only way to achieve these outcomes. I can map these outcomes to mature implementations of XP, DSDM, FDD, Crystal and Kanban (etc.). Now the interesting conversations sound like –

• In what situations does Kanban reduce transaction and coordination costs more than Scrum?
• In what situation does one method lead to better adoption over another? Why?
• In a specific organization, what approach to developing empowered teams and upstream trust will be most likely to succeed?

The outcomes described in the Scrumbut test can be achieved by applying specific strategies that are consistent within an organization’s environment. When these outcomes are adopted development teams tend to become more mature, better at delivering software (many times dramatically), and improve their work environment. Regardless of method, you need to be focused on the outcomes that result in improvements in productivity and find the way that works in your organization to adopt and sustain the outcomes.

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.