Re-Read Saturday: The Goal: A Process of Ongoing Improvement. Part 2

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 3^rd 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.

 

Internal Applications Are Products Too!

Without a roadmap and a value focus it is easier to perceive that the current “project” might the last one in a while, therefore you need to ask for the moon.

It is often more difficult to take a product focus for applications that will be used internally than for an application that will be used by or sold to an external customer. Part of the issue seems to the distance an application from the ultimate end of the value chain and therefore revenue. The further away from revenue, the harder it is to view the user of the software as a customer. Therefore providing support for tools that enable or support non-customer facing work is often viewed as less critical than customer facing applications or tools. The difficulty in considering internal software as a product is less an artifact of any real difference between internal and external facing applications than perspective. Differences in perspective are typically built on minor differences in organization and market attributes. These differences include:

Ability to switch – Internal “customers” often are hostages to the services provided by internal IT organizations, at least in the short run. While that sounds strong, internal customers often do not have the option to shift providers if they don’t like the service or quality they receive. In the long run, switching can and often does occur either through outsourcing, formation of shadow IT groups in the business or changes in IT leadership. Less flexibility in the short run can often lead to a lack of discipline when it comes to defining product roadmaps or defining the true value any specific feature or function might deliver. Without a roadmap, a form of fatalism can set in, in which users always ask for more than they need at the moment but usually accept what they are offered (after a lot of noisy conversation).

Internal politics – The value of work that is sold or used by external customers is usually easier to measure. Functionality either solves a need and generates revenue or increases customer satisfaction. Developing a value for work to be consumed internally is rarely that cut and dry. Priorities are often defined by considerations that don’t reflect the true quantitative value of the work. Priorities often reflect the requestor’s (or requestor’s group) positional power. In my first job, the head of accounting requests always floated to the top of the list even though we were a garment manufacturer with a sales focus. Prioritization by factors that don’t relate to value makes it difficult to develop roadmaps or plan release for applications that don’t have the same level of political clout. Remember when you hear the saying, “the squeaky wheel gets the grease,” it often means that the organization has a project rather than a product focus.

Talking with Customers –  Another of the differences between internal applications and external products that impacts whether an application is viewed as a product is who needs to have input into direction. Products require discussion not only with internal stakeholders, but also with external customers. Internal applications supported by individual projects only require discussion with internal stakeholders. The lack of a perceived impact outside of the company’s boundaries makes it difficult to generate the motivation to get involvement across the IT/business boundary. For example, it is often harder to identify and get product owner involvement to support planning and work to be used internally. Agile techniques are often a tool to remove the barriers between IT and internal business groups. However it is easier to generate the involvement needed facilitate developing plans, road maps and communication when revenue is involved, which tends to yield a project perspective (short term) rather than a product perspective.

Perceived differences between work done for internal and external use tend to drive internal customers into a more transactional mode. Without a roadmap and a value focus it is easier to perceive that the current “project” might the last one in a while, therefore you need to ask for the moon.

 

Product and Project Perspectives: You Can’t Live Without Both

You need both the big and the small picture to deliver value.

The concepts of project and product provide two alternatives that might lead readers to believe that one perspective is more important than another. You need both sets of behaviors generated by the project and product perspective. How these behaviors are incorporated into roles on teams is not as straightforward as designating a role representing project concerns and a role representing product concerns and never the twain shall meet. Both roles do not have to be separate people. Agile spreads the project-centric behaviors across the entire team. Even the product owner typically absorbs some of the project-centric activities. However, other than at a philosophical level, the team is not typically charged with performing the product-centric activities. Agile techniques spread project behaviors across the team while product driven behaviours are more concentrated.

Project-centric behaviors are focused on the delivery of the tactical plan, while the product owner has more of a focus on the vision of the long-term future, i.e. the product roadmap. Even though the product owner has a distinct interest in the tactical (what is to be accomplished in a sprint or release), the team has a more focused interest in day-to-day activities. The team must plan, monitor and adjust the day-to-day activities needed to meet their commitments during the sprint (commitments in Agile are by definition tactical). The product owner can contribute, however they typically do not have the technical acumen to deliver functional software. However, without a product view, the day-to-day project considerations will typically trump long-term considerations. In a mature Agile environment, the product view interacts with the project view to generate an equilibrium between long- and short-term perspectives.

Project and product focuses require a different measurement. The project focus on delivery/short-term goals generates a need to understand, pursue and measure delivery efficiency. Efficiency is a measure of transformation; how much of a set of raw materials is needed to create an output. Efficiently producing any output is only valuable, IF what is being produced is what is needed and can be actually delivered. Interestingly most software is a step toward a different product that is bought or used. Because the software being developed or enhanced is a step along a path, the value assigned often does not represent the ultimate impact to the organization (See our Re-Read Saturday series on The Goal for more on this topic). The product owner, as the steward of the product perspective, owns the definition and measurement of value. He or she needs to take the big picture view of what the market needs AND what the market will pay for. What the market will pay for is just as important for an internal product as an external. In order to understand the value a product delivers, the product owner must ask whether the result of a sprint or release positively impacts ROI, profit and cash follow. Efficiency is a mechanism to determine whether a team is making the most out of their “raw material,” but it does not provide feedback on whether what is being produced is the right thing, or whether the functionality delivered yields value to the organization.

In general the product owner will be the champion for the product perspective, however every team member needs to have an understanding of the how the future should unfold and the value they are being asked to deliver. The team will need to temper the product vision based on the constraints that the day-to-day environment provides. Both the project and product perspectives are needed to maximize value. Putting either perspective ahead of the other for any length of time will create an imbalance that will reduce team effectiveness.

 

SPaMCAST 330 – Anthony Mersino, Agile Project Management

http://www.spamcast.net

Listen Now

Subscribe on iTunes

This week’s Software Process and Measurement Cast features our interview Anthony Mersino, author of Emotional Intelligence for Project Managers and the newly published Agile Project Management.  Anthony and I talked about Agile, coaching and organizational change.  It is a wide ranging interview that will help any leader raise the bar!   We also talked about his new venture: Vitality Chicago.

We are having a contest! Anthony has offered a copy of his great new book to a randomly selected SPaMCAST listener, ANYWHERE IN THE WORLD.  Enter between February 22th and March 7^th.  The winner will be announced on March 8^th.  If you want a copy of Agile Project Management you have two options: send your name and email address to spamcastinfor@gmail.com (I will act as the broker and notify the winner at which point we can deal with other types of addresses), OR you can buy a copy.  Remember buying a copy through the Software Process and Measurement Cast helps support the podcast.

Dead Tree Version or Kindle Version

Anthony’s bio:
Anthony C. Mersino, PMP, PMI-ACP, CSP is an Agile Transformation Coach and IT Program Manager with more than 28 years of experience.  He has delivered large-scale business solutions to clients that include Abbot Labs, IBM, Unisys, NORC, and Wolters Kluwer, and provided Agile Coaching for The Carlyle Group, Northern Trust, Bank of America, and Highland Solutions.

Anthony is the author of Agile Project Management, and Emotional Intelligence for Project Managers.  He is also the founder of Vitality Chicago, an Agile transformation consulting firm focused on helping teams THRIVE and organizations TRANSFORM.

Contact information:

Email:
Anthony@ProjectAdvisorsGroup.com
AMERSINO@VITALITYCHICAGO.COM

Websites:
http://projectadvisorsgroup.com/about.html

http://www.vitalitychicago.com/

Call to action!

Can you tell a friend about the podcast?  Even better, show them how you listen to the Software Process and Measurement Cast and subscribe them!  Send me the name of you person you subscribed and I will give both you and the horde you have converted to listeners a call out on the show.

Re-Read Saturday News

The Re-Read Saturday focus on Eliyahu M. Goldratt and Jeff Cox’s The Goal: A Process of Ongoing Improvement began on February 21^nd. The Goal has been hugely influential because it introduced the Theory of Constraints, which is central to lean thinking. The book is written as a business novel. Visit the Software Process and Measurement Blog and catch up on the re-read.

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 

Upcoming Events

CMMI Institute Conference EMEA 2016
March 26 -27 London, UK
I will be presenting. My presentation is titled “Agile Risk Management.”
http://cmmi.unicom.co.uk/

 

Next SPaMCast

In the next Software Process and Measurement Cast we will feature another magazine feature.  The features in next week’s podcast include columns from Gene Hughson, discussing micro-services. Jo Ann Sweeney Explaining Change and our essay on Agile Coaching.  Coaches help teams and projects deliver the most value, however many times organizations eschew coaches or conflate management and coaching.  Both actions rob teams and organizations of energy and value. We discuss why next week.

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: “This book will prove that software projects should not be a tedious process, neither for you or your team.” Support SPaMCAST by buying the book here.

Available in English and Chinese.

 

Re-Read Saturday: The Goal: A Process of Ongoing Improvement, Part 1

Today we begin the re-read of The Goal. 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 

Eliyahu M. Goldratt and Jeff Cox’s wrote The Goal: A Process of Ongoing Improvement (published in 1984).  The Goal was framed as a business novel. In general, a novel presents a story through a set of actions and events to facilitate a plot. A business novel uses the plot, interactions between characters and events to develop and illustrate concepts or processes that are important to the author.  Bottom line, a business novel uses metaphors rather than drawn out scholarly exposition to make its point.  The Goal uses the story of Alex Rogo, plant manager, to illustrate the theory of constraints and how the wrong measurement focus can harm an organization.

I am using the 30^th anniversary edition of The Goal for this re-read.  This version of the book includes two forewords and 40 chapters.

The two forwards to The Goal expose Goldratt’s philosophical approach.  For example, in the forwards, science is defined as a method to develop or expose a “minimum set of assumptions that can be explained through straightforward derivation, the existence of many phenomena of nature.” Science provides an approach to develop an understanding why something is occurring and then to be able to test against that understanding. We deduce based on observation and measurement to develop a hypothesis and then continue to compare what we see against the hypothesis. Good science is the foundation of effective process improvement. Good process improvement is simply a requirement for survival in today’s dynamic business environment.

The characters introduced in chapters 1 – 4:

• Alex Rogo – the protagonist, manufacturing plant manager
• Bill Peach – command and control division vice-president
• Fran – Alex’s secretary
• Bob Donovan – Production Manager
• Julie Rogo – Alex Rogo’s wife

Chapter 1:

In the first chapter we are immediately introduced to Alex Rogo, plant manager, and his boss, Bill Peach.  Our protagonist, Alex Rogo is immediately thrown into a crisis, revolving around a late shipment that his boss has arrived, unannounced, at the plant to expedite. Bill Peach begins by interfering with plant operations, which leads to a critical mechanic quitting and to a broken and potentially sabotaged machine.  Remember back to Kotter’s eight stage model for significant change in his seminal book, Leading Change (the last book featured in out Re-Read Saturday feature).  The first step in the model was to establish a sense of urgency. Goldratt and Cox use chapter one to establish the proverbial burning platform.  The plant is losing money, orders are shipping late and Peach has delivered an ultimatum that unless the plant is turned around, it will be closed.

Chapter 2:

The immediate crisis is surmounted, the order is completed and shipped. The plant focused on getting a single order done and shipped. Bob Donavan noted that everyone pulled together, behavior that the Agile community would call “swarming.”  A thread running through the chapter is that the plant has aggressively pursued cost savings and increased efficiency. This thread foreshadows a recognition that measuring the cost savings or efficiency improvement in any individual step might not provide the results the organization expects. Rogo reflects at one point that he has the best people and the best technology, therefore he must be a poor manager.

Chapter 3:

This chapter develops on the corporate culture by exposing the fixation on efficiency and cost control as the basis for measurement and comparison.  The whole division is on the chopping block and an endemic atmosphere of fear has taken hold.  For example, Rogo’s and Peach’s relationship that had, in the past, been marked by camaraderie is a reflection of the fear and animosity that has been generated. Fear hinders the collaboration and innovation that will be needed to save both the plant and the division.  W. Edward Deming in his famous 14 principles explicitly stated “drive out fear, so that everyone may work effectively for the company.” My interpretation of chapter 3 is that fear and the tools that generate fear will need to be addressed for the division to survive.

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.

Next week we begin the path toward redemption!

What are your thoughts on the forwards and first 3 chapters?

 

Product versus Project: Exposing Behavior Differences

Organizations with a product perspective generally have an understanding that a project or release will follow the current project reducing the need to get as large a bite at the apple as possible (having tried this a child, I can tell you choking risk is increased).

The concepts of product and project are common perspectives in software development organizations. A simple definition for each is that product is the thing that is delivered – software, an app or an interface. A project reflects that activities needed to develop the product or a feature of the product. Products often have roadmaps that define the path they will follow as they evolve. I was recently shown a road map for an appraisal tool a colleague markets that showed a number of new features planned for later this year and areas that would be addressed in the next few years. The map became less precise the further the time horizon was pushed out. Projects, releases and sprints typically are significantly more granular and with specific plans for work that is currently being developed. Different perspectives generate several different behaviors.

1. Roadmap versus plan: The time-boxed nature of a project or a sprint (both have a stated beginning and end) tends to generate a focus planning and executing specific activities and tasks. For example, in Scrum sprint planning, accept and commit to the user stories they will deliver. There is often a many-to-one relationship between stories and features that would be recognized at by end-users or customers. Product planning tends to focus on the features and architectures that meet the needs of the user community. Projects foster short-term rather than long-term focus. Short-term focus can lead to architectural trade-offs or technical shortcuts to meet specific dates that will have negative implications in the future. The product owner is often the bridge between the project and product perspectives, acting as an arbiter. The product owner helps the team make decisions could have long-term implications and provides the whole team with an understanding of the roadmap. Teams without (or with limited) access to a product owner and product roadmap can only focus on the time horizon they know.
2. Needs versus Constraints: Projects are often described as the interaction between the triple constraints of time, budget and scope. Sprints are no different; cadence – time, fixed team size – budget, and committed stories – scope. There is always a natural tension between the business/product owner and the development team. In organizations with a project perspective, product owners and other business stakeholders typically have a rational economic rational to pressure teams to commit to more than can reasonably accomplished in any specific project. Who knows when the next project will be funded? This behavior is often illustrated when the business indicates that ALL requirements they have identified are critical, or when concepts like a minimum viable product are met with hostility. Other examples of this behavior can be seen in organizations that adopt pseudo-Agile.  In pseudo-Agile backlogs are created and an overall due date generated for all the stories  before a team even understands their capacity to deliver. Shortcuts, technical debt and lower customer satisfaction are often the results of this type of perspective. Organizations with a product perspective generally have an understanding that a project or release will follow the current project reducing the need to get as large a bite at the apple as possible (having tried this a child, I can tell you choking risk is increased).
3. Measuring Efficiency/Cost versus Revenue: Organizations with a product perspective tend to take a wider view of what needs to be measured. Books such as The Goal (by Goldratt and Cox) make a passionate argument for the measurement of overall revenue. The thought is that any process change or any system enhancement needs to be focused on optimizing the big picture rather than over optimizing steps that don’t translate to the goals of the organization. Focusing of delivering projects more efficiently, which is the classic IT measurement, does not make sense if what is being done does not translate to delivering value. Measuring the impact of a product roadmap (e.g. revenue, sales, ROI) leads organizations to a product view of work which lays stories and features out as portfolio of work.

These dichotomies represent how differences in project and product perspectives generate different behaviors. Both perspectives are important based on the role a person is playing in an organization. For example, a sprint team must have a project perspective so they can commit to work with a time box. That same team needs to have a product view when they are making day-to-day trade-offs that all teams take or technical debt may overtake their ability to deliver. Product owners are often the bridge between the project and product perspectives, however the best teams understand and leverage both.

 

Product versus Project: Related but Different

 

Learning to pour sidra (cider) – product or project?

A product is something that is constructed for sale or for trade for value. In the software world that product is often software code or a service to interface users to software. Typically a project or set of projects is required to build and maintain an IT product. If we simplify and combine the two concepts we could define a product as what is delivered and a project as the vehicle to deliver the product. The idea of a product and a project are related, but different concepts. There are several differences in common attributes:

Agile pushes organizations to take more of a product than a project perspective, however arguably parts of both can be found as the product evolves. A sprint (or even a release) will include a subset of the features that are included on a product backlog.  The sprint or release is a representation of the project perspective.  As time progresses, the product backlog evolves as customer or user needs change (the product perspective). In the long run the product perspective drives the direction of the organization.  For example, a friend that owns a small firm that delivers software services maintains a single product backlog. In classic fashion the items near the top of the backlog have a higher priority and are more granular. The backlog includes some ideas, new services and features that won’t be addressed for one or more years. The owner acts as the product owner and at a high level sets the priorities with input from her staff once a quarter, based on progress, budget and market forces. The Scrum master and team are focused on delivering value during every sprint, while the product owner in this case is focused of building greater business capabilities.

IT in general, and software development specifically, have historically viewed work as a series projects, sometimes interlocked into larger programs. A project has a beginning and an end and delivers some agreed upon scope. When a project is complete a team moves on to the next job. A simple and rational behavior for a product owner who might not know when the next project impacting his product might occur would be to ask for the moon and to pitch a fit when it isn’t delivered. Because the product owner and the team are taking a project perspective it is impossible to count on work continuing forcing an all or nothing attitude. That attitude put the pressure on a team to accept more requirements than they can deliver leading an increased possibility of  disappointment, lower quality and failure. Having either a product or project perspective will drive how everyone involved in delivering functionality interact and behave.