Stop on Red!

Stop on Red!

One of the most common indicators used in measurement and status report are traffic light indicators.  Traffic light indicators are most commonly shown as a set of red, yellow and green lights.  The metaphor draws from the nearly ubiquitous traffic light seen at nearly every intersection.  Traffic light indicators are part family of indicators of that combine indices and scales. Indices are typically used when a single measure or metric does not tell the story. An index reflects a composite of measures. Measures and/or metrics are averaged together or combined using complex mathematics.  The index is then transposed onto a scale so that it can be interpreted and used.  For example, wind chill is an index that combines temperature and wind speed into a temperature perceived by the skin. Wind chill once calculated is shown on a temperature scale. As a project status indicator, a traffic light indicator typically reflects a synthesis of many attribute.  The traffic light uses a simple scale in which red means trouble; yellow means caution and green means clear sailing. Traffic lights are adopted for three highly related reasons.

  1. Traffic lights are easy to recognize. The traffic light is a common symbol that every driver has been taught to recognize. Attaching a traffic light instantly indicates that a summary of status is being communicated.
  2. Traffic lights provide a consolidated view of complex attributes. The traffic light scale is a simple metaphor with three possible indications of overall performance.  Even in a simple project attributes such as budget, client satisfaction and risk must be synthesized into single perception of status that can be communicated. Traffic light indicators force a synthesized view.
  3. Traffic lights are easy to explain. Once an organization reaches a consensus on the business rules that set a traffic light indictor to red, yellow or green, is easy to explain. Red is bad and requires immediate action, yellow means caution, performance issues require mitigation and green mean business as usual.   Paul Byrnes, CMMI Lead Appraiser, when asked why people are drawn to traffic lights noted that “colors are easy…except for people that can’t see them… .”


Karl Jentzsch, a colleague at David Consulting Group summarized the case for traffic light indicators as “the appeal is that it provides an easily manageable number of ‘buckets’ to drop things into where the categorical distinctions are still fairly clear and inherently understood – good/go (green), bad/no (red), and in between (yellow).”

I often hear traffic lights defended with the statements like “we have always used traffic lights” and “or they are required by the PMO.” These are excuses that reflect an abrogation of thought and responsibility. It is too easy to succumb the simplicity of the indicator without reflecting on all the hard work and analysis needed to set the indicator. Typically this should be a lot of math and analysis to set the traffic light to red, yellow or green.  The math and the analysis is where the real magic happens and requires thought and understanding. As an indicator, the traffic light is elegant in its simplicity; however that simplicity can also be its undoing.



Summary of The Goal so far:

Chapters 1 through 3 actively present the reader with a burning platform. The plant and division are failing. Alex Rogo has actively pursued increased efficiency and automation to generate cost reductions, however performance is falling even further behind and fear has become central feature in the corporate culture.

Chapters 4 through 6 shift the focus from steps in the process to the process as a whole. Chapters 4 – 6 move us down the path of identifying the ultimate goal of the organization (in this book). The goal is making money and embracing the big picture of systems thinking. In this section, the authors point out that we are often caught up with pursuing interim goals, such as quality, efficiency or even employment, to the exclusion of the of the ultimate goal. We are reminded by the burning platform identified in the first few pages of the book, the impending closure of the plant and perhaps the division, that in the long run an organization must make progress towards their ultimate goal, or they won’t exist.

In the next 3 chapters Alex commits to change, seeks more precise advice from Johan, brings others into the discussion and perhaps destroys his marriage (it is a business novel after all).

Chapter 7

We are presented with a short inner monologue in which Alex decides that he won’t call a headhunter to find a new job. He wants to find a solution, and to not leave the town where his mother lives and he grew up. Running away is not an option in his mind. This decision marks his commitment to change. In a Scrum team, this commitment is very similar to the commitment the team makes to goals of a sprint. The impact of commitment in a larger group can be seen in the SAFe release planning event (PI) which involves 50 to 125 people. In the release-planning event, everyone involved in the release reviews and commits to the plan. Commitment locks in the sense of urgency needed to drive change.

Chapter 8

Alex finds a means to reconnect with Johan by searching through his school papers. When Alex connects with Johan, Johan immediately asks him whether he has come up with the answer for the question, “What is the real goal of a manufacturing organization?” The goal is to make money. Having the answer to that question is the key that unlocks further advice. Given the goal, Alex explains that the organization’s current measures are not telling him the whole story, and therefore the plant and division are failing. The discussion of the problem illustrates that there are many ways to express any goal, which will have an impact on how it is measured. Expressing a goal holistically lead to measuring and understanding the big picture.

Without directly identifying it as such, having a holistic vision is a reference to systems thinking. Systems thinking is an approach to problem solving that emphasizes the whole process, including the environment within which system operates.  The critical aspect of systems thinking to understand at this point of The Goal is that in a system the overall impact of a change to any individual component may or may not affect the performance of  the system.

By the end of the chapter, Alex and Johan settle on 3 metrics that, taken together, are equivalent to the goal of making money. They are:

Throughput – the rate at which the system generates money through sales.

Inventory – all of the money the system has invested in purchasing things it intends to sell.

Operational Expense – all the money the system spends in order to turn inventory into throughput.

The 3 metrics provide a broad view of the flow of product and money through the plants, and would be very useful in any IT organization. They all focus on getting product into the hands of paying customers. Many in software development would argue that the work they do isn’t related to a product. As have noted in earlier blog entries, I approach this argument with the belief that all applications are products and someone is paying for what you do!

Chapter 9

Alex widens the circle of people “in the know” about his revelations. He takes his senior staff through his revelations. He uses his the realization that the robots used to automate production have not reduced costs (because no workers have been displaced), have increased inventory (the parts being made are not being used fast enough) and are causing other orders to be late (maintenance requirements and resources) to make the point. While using the robots has optimized part of the system, the overall system has not improved and perhaps is doing worse than before. In lean terms, optimizing part of the system is known as a generating a local optimum. In this case, that optimization does not seem to benefit the whole system. Chapter 9 foreshadows the ideas of how constraints and bottlenecks affect the overall system and the theory of constraints. However, the robots have become celebrities. The company president is coming to the plant to be filmed with the robotic machinery which is a reflection of the fact that no one is connecting the dots between local optimums and performance of the system.

You get what you measure. In this case, we see measures of efficiency being used at the level of part production, but not at the level of whole orders or even sales. The corollary to ‘you get what you measure’ is that if you measure the wrong thing …you get the wrong thing. Johan has helped to open Alex’s eyes now that he has the urgency and commitment to make a change.

Note: If you don’t have a copy of the book, buy one.  If you use the link below it will support the Software Process and Measurement blog and podcast. Dead Tree Version or Kindle Version 


Chapters 1 through 3 actively present the reader with a burning platform. The plant and division are failing. Alex Rogo has actively pursued increased efficiency and automation to generate cost reductions, however performance is falling even further behind and fear has become central feature in the corporate culture. If the book stopped here it would be brief tragedy, however Chapter 4 begins the path towards the redemption of Alex Rogo and the ideas that are the bedrock of lean.

New Characters

  • Jonah – advisor
  • Lou – plant’s chief accountant

Chapter 4:

In Chapter 3, Alex was at a company meeting that communicated the depths of the problems the division was having and to search for answers. The meeting was not holding Alex’s attention. He found a cigar in his jacket and flashed back to a chance meeting in an airport lounge. While smoking a cigar, Alex recognizes and strikes up a conversation with a professor from grad school. The discussion turns to the problems at the plant, and even though they have pursued changes that have yielded great efficiencies the problems still exist and perhaps are getting worse. Alex proudly shows Jonah a chart that “proves” that a 36% improvement in efficiency from using robots and automation. Jonah asks one very simple question: was profit up 36% too? Alex struggles and answers that, “it is not that simple.” In fact the number of people in the plant did not go down, inventory did not go down and not one additional widget had been shipped. This interaction foreshadows one of the key ideas that The Goal presents to the reader. We are measuring the wrong thing! When we measure the wrong thing we send the wrong message and we get the wrong results. Chapter 4 closes with Johan and Rogo talking about the real meaning of productivity. Productivity is defined as accomplishing something in terms of a goal. Without knowing the goal, measuring productivity and efficiency is meaningless.

Chapter 5:

In Chapter 5 we snap back to the all-day meeting to discuss the division’s performance (Chapter 3). Alex continues to ruminate on Jonah’s comments. Alex leaves the meeting under the pretext of a problem back at the plant. As he drives back to the plant he begins to reflect on the “the goal” in the definition of productivity identified in Chapter 4.  As Alex drives back he decides that he will not have time to think due to the day-to-day demands (also known as the tyranny of the urgent but not important – See Habit 3 of Stephen Covey) therefore heads to a favorite pizzeria for pizza and beer. Goldratt and Cox use Alex’s inner dialog show why most of current internal goals and measures Alex is being asked to pursue miss the point. The bottom-line goal is that the plant’s goal is to make money. If it does not make money, the rest does not matter. While The Goal is set in a manufacturing plant, the point is that unless any group or department does not materially impact the real goal of an organization it should not exist.

Chapter 6:

Chapter 6 begins with a search for the overall measures that contribute (or predict) whether the plant is meeting the goal of profitability. One the first questions Alex poses to himself is whether he can assume that making people work and making money are the same thing. This sounds like a funny question, however I often see managers and leaders mistake being busy with delivering value. Alex and Lou brainstorm a set of 3 metrics that impact the goal. They are: 1. net profit, 2. ROI, 3. cash flow. In this conversation Alex tells Lou the truth about the state of the division and the potential closure of the plant. The 3 metrics sound right, however Alex does not see the immediate connection between the measures and day-to-day operations. The chapter ends with Alex asking the 3rd Shift Supervisor how is activities impact net profit, ROI and cash flow. He simply gets the deer-in-the-headlight look.

Chapters 4 – 6 shift the focus from steps in the process to the process as a whole. Organizations have an ultimate goal. In this case the ultimate goal of the plant is make money. The goal is not quality, efficiency or even employment because in the long-run if the plant doesn’t deliver product that can be sold it won’t exist. Whether an organization is for-profit or non-profit, if they don’t attain their ultimate goal they won’t exist.

Metrics Are About Prediction

Metrics Are About Prediction

There are three reasons to measure. The first is to guide specific behaviors. The second is to provide information on the status of process. And the third is as a tool to help predict the future. At a team level it is easy to take a very narrow view of metrics and measurement, however the organization is another significant stakeholder in the collection and consumption of metrics information. Teams and other organizational stakeholders have different metrics needs for each of three basic reasons for measuring.  Part of maturing as an Agile organization is the development of a common understanding of metrics needs that includes the differences between groups.  Reaching a common understanding is a step toward developing the mechanisms to accommodate all of the relevant metrics needs within the organization.


Reason to Measure

Agile Team Perspective Organizational Perspective
Guide Behaviors The goal of metrics and tools at a team level are to support tactical behaviors focused on the delivery the functionality the team has committed to delivering.  Metrics can be delivered with tools such as card walls (the simple metric of a card moving across the board), burn-down charts or story completion charts.  These tools (also known as information radiators) provide information that teams generally find useful for guiding behaviors such as swarming, collaboration and continuous re-planning. The goal of measurement that guides behavior at the organizational level is to reinforce desired overall Agile behavior. The metrics needed to support and reinforce Agile behavior will evolve as an organization completes its Agile transformation.  Examples of organization metrics that guide behavior include Ka8znztcskills/capabilities tracking (gamification – Gamification is a mechanism that leverages the competitive attributes of the target audience). [As the transformation matures, measurement against Agile Maturity Models can be leveraged to guide behavior.
Provide Status Tactical Perspective: The team shares status on a daily basis during the stand-up/Scrum meeting while leveraging tools line the card wall and burn-down charts as metrics and informational radiators. Burn-down chart provides team level status information that can by share across multiple layers of the organization hierarchy, however team level data tends to be seen as too granular as projects morph into programs and status is passed up the organizational hierarchy. Program level burn-up charts and story maps provide quantifiable measurement feedback that is accessible to senior leaders.
Predict Future Scrum and Scrumban teams need to be able see the work in front of them to understand how to plan both at a short, medium term and long term basis.  Tools like burn-down (short term), burn-up (program level view), story maps and product roadmaps (both long-term) provide a quantified view of progress. Organizations need to develop tactical and strategic plans that are supported by software functionality.  Portfolio metrics and information radiators (story maps and product roadmaps) leverage naturally occurring data from project performance.

Different stakeholders have different measurement needs and perspectives.  Occasionally there is a suggestion that the only measurement data that Agile should generate is what the team needs.  While teams and other organizational stakeholders, such as product, IT and executive management, can (and should) use similar tools, organizational data needs extend to being able to monitor and guide the Agile transformation and other process improvement efforts. Those needs will require everyone involved collect a wider range of data and generate different metrics.

This measurement that encourages behavior.

This measurement that encourages behavior.

Discussions of software development, maintenance and enhancement measurement are generally tense, even at the best of times. Measurement has a significant amount of baggage, ranging from using measures to grade individuals for team activities to measurement without sharing the results with those being measured. Add the philosophies of Agile into the mix and the discussion becomes even more difficult, because, to be optimally efficient, Agile measurement requires an organization to adopt a different set of measurement philosophies that are more inline with the principles found in the Agile Manifesto.

  • Reinforce desired Agile behavior – Measurement has a very strong behavioral competent. You get what you measure, therefore the measures selected need to support and promote the behavior you want in the organization. For example, organizations often try to measure individual productivity or velocity, which reinforces individualism. Where the more Agile behavior would be team collaboration, asking for help and swarming to problems. Measure team productivity and velocity rather than focusing on individuals.
  • Focus on results – Agile techniques are geared to delivering potentially implementable functionality early and often. Potentially implementable functionality equates to value for the organization. Agile measurement should focus on the value that is delivered. Examples of value would include functionality delivered, stories completed or estimated business value.
  • Measure trends – The direction a measure is trending is typically more important than an individual observation (common cause versus special cause variation). Given the short cycles (sprints) most Agile teams use, teams can accumulate enough observations of their processes and the functionality being delivered to understand whether they are improving or not.
  • Easy to collect – All measurement requires effort, typically from both the people doing the measurement and those being measured. The overhead of measurement is time that is not being used to deliver value therefore it should be minimized. The measurement information you collect should be easily collected (or in perfect world) be a natural byproduct of the tools and techniques being used on the project.
  • Includes context – Just knowing black and white numbers does not allow nuanced interpretation of performance. Collecting and storing (write story down and save it as text attached to the measurement data) the context that helped generate a specific result will help teams and managers to understand and use the data.
  • Creates real conversation – Measurement needs to generate a dialog in which all stakeholders of IT and projects can understand the value that is being delivered, discuss performance and find ways to improve the delivery of value.
  • Measure only what is absolutely needed – Define and collect measures and metrics that will be actively used to guide the organization or make decisions. Collecting more information than you will need to answer questions and make decisions will generate more overhead for teams to overcome.

All organizations and teams need the feedback that measurement generates. Organizations typically measure for two reasons. The first is to generate specific behaviors, and second to predict the future.  Organizational goals provide the rational for what to measure and the type of measure determines whether it drives behavior or provides direction. In organizations that leverage Agile techniques measurement will be more effective if it embraces Agile measurement philosophies.

Cultural disconnects are a major contributor to problems in outsourcing.

Cultural disconnects are a major contributor to problems in outsourcing.

Managing risk is one of the keys to success in an outsourcing arrangement.  There are many control mechanisms used to manage outsourcing deals.  Control mechanisms can range from full-scale contract offices, PMO’s, metrics, scorecard reporting, audits, CMMI assessments and on-site oversight teams.  In real life, typically these are applied in combination.

Cultural disconnects are a major contributor to problems in outsourcing that increase as the distance between client and outsourcer grows.  Sounds like a truism, however examples abound even today as organizations fall prey to misunderstandings driven by cultural disconnects.  The misunderstandings that can occur can range for differences in semantics to deep-seated cultural differences.

A tool to manage/minimize this type of disconnect is to co-locate an on-site account management team with the outsourcer.  This type of arrangement provides an avenue to mitigate cultural differences, translate both intent and words and mainly to build trust.  All positives; however darker possibilities exist, and as personal observations prove, they do happen!

On-site management of outsourced projects provides a number of impressive benefits that other forms of control do not provide.  The first and most important of these is a simple visible presence that reinforces that work is important.  Secondly, an onsite presence can provide a bridge between cultures (both organizational and sociological cultures).  Further, a presence provides a mechanism for translation, and for ironing out semantic differences quickly and efficiently.  Finally, an onsite presence is a basis to build a common history and understanding, which yields trust.

A powerful tool with equally powerful drawbacks: what happens when an onsite lead or team loses perspective?  I participated in an assessment of team that supports a group of outsourced applications.  During initial discussions it was impossible to determine who worked for the outsourcer and who worked for the onsite account management.  Collaboration you might ask?  True, but only if the arrangement is structured as such and all parties perceive it that way, which was not the case.  The on-site team had lost perspective and aligned themselves with organization they were overseeing, an application of the ‘Stockholm Syndrome’.

When an onsite team gets too close, they lose perspective, and they begin to believe they are part of the company they supposed to interface with.  When perspective is lost, who will they advocate for the project or how will a critical point of translation be interpreted?   Even if the closeness is merely an appearance, it will be difficult for others to understand how to act.

How do the best make co-located teams work?  The best observed application of the techniques begins with the sourcer deploying a cross-functional team.  The skills that are required include project management, business and systems analysis.  The very best include personnel with both facilitation and negotiation skills (negotiation is more typical). All team members require a strong sense loyalty to their company.  Note that if the work is ’offshored‘ (not just outsourced), then the team members must have command of the local language.  The rational for teams rather than an individual is two-fold:  The first is that a team can field more skills.  The second is that a team is far less likely to “go native” than an individual (teams create their own support structure).  Note, using teams is a best practice only if the amount of work supports it.  Smaller outsourcing agreements may not have the luxury, which means they must roll all of these skills into a single individual.

Despites the downside risks, co-locating sourcer and outsourcing teams of any size are a best practice.  How organizations structure their co-location program to keep the personnel fresh and useful is what separates the wheat from the chaff.  Observed tactical best practices to maintain the crispness of on-site teams include:

  • Rotation of personnel (not everyone at once unless there is only one person) re-enforces the attachment to the parent company.  A secondary form of rotation includes making a spot on the team a step on a job progression.
  • Leveraging PPQA reviews provides an assessment of whether the outsourcers processes are being followed.  Non-compliances are identified and an action plan is put in place for remediation.
  • External audits, using models such as the CMMI, ITIL or ISO Standards, provide a far more formal reading of whether processes are followed (typically with more consequences if they are not).

On-site teams are a best practice for reducing the risk of an outsourcing agreement, but it is a best practice that has a downside unless they are carefully managed.

photo (1)

Why do some products make a bigger splash than others? I recently heard an analogy, which explains why some products have naturally higher market demand than others. The analogy stated that there are really only three macro classes of products; products that avoid problems, solve a specific pain and provide new functionality. The analogy used vitamins, aspirin and the little blue pill as a metaphor for these three categories. Process improvement can easily be classified using these metaphors. As change agents, we can use this analogy as a tool to guide how we conceive and implement process changes within our organizations.

One of the failings of many software process improvement programs is that they are framed as means of avoiding a problem. I call this the futurist point of view. The futurist point of view translates to the “vitamins” for the organizational change world. If I asked you directly I am certain that you would understand the need to take precautions so that the future we will be better. The big unvoiced “however” in your answer would be that it is hard get motivated to make a change now for a nebulous payoff in the future. Just remember the last time you toyed with the idea of starting an exercise program. The linkage between a current change in behavior (taking vitamins) and future benefits is just not direct enough to create a groundswell of acceptance. Bottom-line: Selling potential benefits in the future is it best of times a difficult proposition.

A few years ago I took sales training (and I am proud of it). I learned how to identify pain during the training program. Ask any professional salesperson and they will tell you that an immediate pain is an important motivator to making a sale, maybe the most important motivator. At least 99.9% of the people in the world want pain to go away when they have it, which is why an aspirin is an easier sale than an exercise program for back pain. The “gotcha” is that pain initially expressed is usually not the root cause of the pain (there are a lot reasons for this behavior, but that is topic for another day). The art of persuasion, sales and requirements gathering is the ability to peel back the layers until you can expose the root cause so the pain can be solved, not just masked. The ability to successfully navigate the “pain” conversation to get to the root cause and not irritate person feeling the pain is a skill not consistently found on IT project teams. Bottom-line: I highly recommend a course in salesmanship for all project managers and requirements analysts, make sure your process improvement program solves current problems and always carry aspirin.

I have been shocked and amazed at how the little blue pill and other similar drugs became and stayed blockbuster drugs. Going back to our analogy, the little blue pill represents products that deliver additional functionality. The little blue pill of process improvement projects delivers the ability to either do something that was not possible before, provide greater flexibility in how work is done and/or greater flexibility in the decision making process. I believe that most IT personnel have a bit of a libertarian streak, which conflates flexibility and choice in how we accomplish our job with the functionality of the process. For example, having more than one way to do a retrospective and the choice of which technique to use makes a process for retrospectives better than one without options. IT personnel are problem solvers, solving problems is central to our identity. Process improvement projects that deliver functionality which make it easier (or even possible) to deliver solutions to IT’s customers addresses the core needs of IT developers and IT leaders. Bottom-line: Make sure your process improvement projects make it possible to do work that could not be done before or at the very least provide a more flexible, choice driven approach.

The analogy of vitamins, aspirin and little blue pill frames a discussion that many process improvement leaders do not have when choosing process improvement projects. I suggest that to survive when budgets are being cut, process improvement programs must deliver real benefits NOW, to solve pain IT organizations have NOW, but to be true to our nature, changes must also provide for a better future. These considerations are not just packaging or salesmanship, addressing these considerations is central to providing real value now and in the future.

PS: Take your vitamins, carry aspirin and if you have processes that stay the same for more than four cycles seek medical attention immediately.


Get every new post delivered to your Inbox.

Join 4,880 other followers