The Rock Crusher Canvas

Most enterprises treat their backlog like most people treat their car’s engine as something that powers the car and can be safely ignored beyond taking it in for regular service.[1]. Like our automobile engine, the backlog powers our team. It is the single repository from which a team can pull their next most valuable work. Unlike the automobile engine, ignoring it leads to low economic performance. Unfortunately, most organizations ignore their backlog, treating it as a passive reservoir of pre-committed requirements. In a previous blog post ( What did 50 Business Analysts Say Were their Biggest Challenges with Backlog Management?,) some 50 business analysts described the problems they were experiencing with their backlogs. Many of the problems could be distilled down to a lack of active backlog management and clarity on responsibilities for backlog management.

This is why my co-authors and I wrote “The Rock Crusher” to explain how the traditional backlog management model, which we labeled the stack of plates model, breaks the value stream and impedes flow. This has severe economic consequences for an enterprise. The worst part of these consequences is that they do not visibly manifest themselves as some general ledger item. Rather, they manifest as lost competitiveness, declining market share, lost goodwill, and staff turnover. (See It’s not all about costs, its about all costs)

The key theme in The Rock Crusher is using our backlog to actively manage the flow of value rather than merely serving as a passive reservoir of requirements. A system for active value management is significantly more complex than a passive reservoir and needs careful design and management. This is why we offer you the Rock Crusher canvas to help you design and improve your backlog management.

These days, it’s become de rigueur to call everything to help you organize your thoughts and ideas a “canvas.” But that is exactly what the Rock Crusher Canvas is for. Based on The Rock Crusher chapter 15 – Implementing Your Rock Crusher, the canvas walks you through the 8 steps for using the Rock Crusher model to think about how to build a better backlog.

  1. Why the Rock Crusher? Form a Rock Crusher Hypothesis describing the problem you are trying to solve, how the rock crusher will solve it, and what data you need to collect to validate or reject your hypothesis.
  2. Choose a value stream. (Where will the Rock Crusher reside?)
  3. Identify your village. (Who will play the various Rock Crusher roles?)
  4. Visualize your Rock Crusher. (How will you visualize the rocks flowing through the Rock Crusher?)
  5. Establish your intake policies. (Where are the front and back doors into the Rock Crusher?)
  6. Establish your Waste Gate policy. (What are your policies for disposing of or managing the rocks ejected through the waste gate?)
  7. Schedule the ceremonies. (What is the cadence and attendance list for the various Rock Crusher ceremonies?)
  8. Continuously improve your Rock Crusher. (How will you apply continuous improvement concepts to the Rock Crusher you are implementing?) Goto 1

These eight steps ask how we will apply lean and agile thinking with our backlog to create the best economic outcomes for our enterprise. Even for me, who often writes excessively long blog posts, we only have space to examine a few steps in a blog post.

Step 1 Why the Rock Crusher?

The first step is the most important. Ask, “Why the Rock Crusher”? Before you start disrupting and transforming your way of working, can you clearly state the problems you are experiencing with your present backlog management strategy and how the Rock Crusher approach may mitigate them? Most importantly, how will you know if it is working? What leading indicators could you measure to test your hypothesis? Do not adopt the Rock Crusher because it seems cool. Adopt it because you believe it can help you solve a problem.

Step 3 Who is part of the village?

Our assertion is it takes a village to manage a backlog, and that backlog management is far too complex and demanding to rest on one individual’s shoulder – usually, the poor person designated as the “product owner.”  The Rock Crusher Village <see It Takes a Village to Own a Product> identifies seven collaborative roles for managing a backlog and deciding on “precisely what to build.”  One of the most important outcomes of this step is identifying the Backlog Owner and Solution Owner(s). Are the Backlog and Solution Owners the same or different individuals? Are there multiple Solution Owners? How will the Backlog Owner and Solution Owner collaborate if they are different individuals? Who is responsible for supporting them? Who plays the role of the Analyst? Who are our Subject Matter Experts? Who do we need to input from to guide our decision making? Who are our stakeholders and customers? Could you clearly answer these questions now in our context? For example, do you know if the individual playing the role of Product Owner in your environment is a Backlog Owner, a Solution Owner, or both? This is the clarity the Rock Crusher canvas helps us establish. It shows who how content authority may be scattered across multiple individuals and makes conflicting overlaps visible.

Step 6 is establishing Waste Gate Policy.

The Waste Gate is a distinguishing trait of the Rock Crusher. The Rock Crusher has a pithy definition for flow: what goes in, must come out. Far more ideas enter the Rock Crusher than a team can deliver. If we are to have a relentless focus on value delivery, then we need to drain away the less valuable ideas. If you were to look in your backlog right now, how many user stories are over 100 days old?  500 days old? 1000+? Unfortunately, if you have numerous stories that are over 1000 days old, you’re in good company.  Numerous enterprises have stagnant backlogs. One of the best quotes about value creation comes from American economist Michael Porter: “Strategy is the art of knowing what not to do.” The humble waste gate is your powerful strategy tool for draining away what you are not going to do.

Step 8 Continuously Improve your Rock Crusher

Finally, step 8 makes it clear the way we work together is agile, which means we embrace change. Just as we experiment, learn, and improve our product, we experiment, learn, and improve our way of working.

To Learn More

The current version of the  Rock Crusher Canvas is available as a free download from Rock Crusher Canvas

This is still a draft version, and we are working with the IIBA to create a more visually pleasing Rock Crusher Canvas.

Of course, if you get a copy our book chapter 15 provides a detailed description of the eight steps for designing and evolving a Rock Crusher.

[1] As an old petrolhead who used to maintain his car (69 Dodge Dart with the 225 slant six engine), I would not dare touch a modern engine. I hate to say it, but that takes all the fun out of owning a car.

The Rock Crusher: It Takes a Village to “Own a Product

The Rock Crusher Village

One lesson most agile practitioners learn quickly is that it takes a village to own a product. Most agile frameworks present backlog management as a collaboration between an omniscient and omnipotent Product Owner and a team. In theory, this is a beautiful model for realizing the economic benefits of agility. The backlog minimizes coordination delays because its the single authoritative source the team pulls work from. The product owner works with the team adding, deleting, and changing backlog items in response to learning from Agile’s fast feedback cycles. The team is always working on the backlog items that should yield the best economic outcomes.

The reality is that this model does not work for most organizations because the Product Owner role is so demanding that one individual cannot successfully perform it. In a blog post, Lor Steyn described what we ask of the product owner [1]:

  • Gather specifications from various stakeholders within the business and build the stories from which the team will work.
  • Manage the backlog’s priorities, deciding which features will give the most business value.
  • Have excellent communication skills to understand the business users and the development team.

“….so we have a role defined that requires high-level strategic thinking around business value and priorities, with a need for highly detailed thinking on stories, and the ability to understand the highly technical needs of the developers as well as the business needs of the users.”

An early study of the customer role in extreme programming led the researchers to conclude “….customers have a pressured and stressful role, leading to issues of sustainability”[2]

In his book “The Art of Agile Product Ownership,” Alan Kelly suggests “…only superhumans need to apply”[3]. Is it any wonder why product ownership issues often top surveys of problems agile teams experience?

The agile textbook agile image of an omniscient and omnipotent product owner has likely resulted in serious economic damage to many IT organizations because many laid off their business analysts, believing the responsibility for “determining precisely what to build” could be shouldered exclusively by an empowered product owner. Unfortunately, many of these organizations soon learned why the business analyst role was created in the first place.

Most agile frameworks suggest that the team and others assist the product owner. However, they provide little guidance for how the product owner and those other roles interact and collaborate. The Rock Crusher is a flow-based model describing roles, practices, and artifacts and provides guidance for these interactions and collaborations.  As we developed the Rock Crusher model, we observed many successful collaborative product ownership patterns, which became the Rock Crusher Village.

The Rock Crusher deconstructs the role of the classical Product Owner into seven constituent roles. Roles are not individuals and only describe a function that must be provided. In a very small system, it is conceivable that an individual could play all roles – the classical product owner. In reality, for any real system, multiple individuals playing multiple roles must collaborate to “…determine precisely what to build”.  The notable exception is the Backlog Owner, which is always a single person and not shared among several individuals. Roles are categorized as either accountable, responsible, or supporting.

Accountable Roles

Backlog Owner has the final say on the sequencing /prioritizing of work for a team. The backlog owner has the final say because they are accountable for ensuring the team always works on the most valuable work.

Solution Owner is a customer-facing role that is accountable for which features make into a Solution but does not have the final say on the prioritization of work for an individual team. 

The need to distinguish between these two roles is driven by the observation that in many environments, the individual often designated as the Product Owner is only interested in Rocks that are related to a pet Solution and is not interested in or capable of guiding the Team in other Rocks in their backlog. I noted this issue in a previous post Are You Really the Product Owner? Furthermore, the team may be responsible for supporting multiple Solutions. For example, in a project-oriented environment, a team may work on several projects simultaneously. Someone must ensure team member priorities align with strategic enterprise goals.

In many organizations, both roles may be played by one individual. However, our observation was that organizations that clearly distinguished their ownership roles also avoided messy priority ambiguities, prioritization conflicts, and coordination delays.

Responsible Roles

Analyst is an individual responsible for transforming the sometimes competing wants, hopes, interests, and aspirations of the Customer, Stakeholder, Solution Owner, and the contributions of the Subject Matter Expert into a shared clear understanding of precisely what to build. They are responsible for progressively creating a better understanding of precisely what to build – the Solution.

Team members are responsible for collaborating with all roles to decide precisely what to build, and they are accountable for delivering on their commitments to the Backlog Owner.

Supporting Roles

Customer is the receiver or beneficiary of the Solution. May be consulted or informed about decisions on precisely what to build

Stakeholder is any individual who cares about the outcome of the solution and must be consulted about precisely what is being built and may also have decision-making authority in deciding “precisely what to build”. A Customer may also be a Stakeholder if they need to be consulted about decisions on precisely what to build.

Subject Matter Expert (SME) has deep knowledge of the relevant problem domain and/or technology and development practices. SMEs use their knowledge to advise other roles, “deciding precisely what to build”. They are responsible for providing the expertise other roles may need to perform their jobs. For example, a medical doctor may act as a domain expert for an organization creating electronic health records. An architect may be a technical expert in determining a solution’s technical scope and complexity.

The Rock Crusher Canvas is a tool that can help you identify your village and the roles individuals play. The simple truth is that whether you acknowledge it or not, the village is there. Acknowledging its existence and the roles individuals play now enables opens the opportunity for systematic experimentation and improvement of our practices. Ignoring the village means our success strategy is based on hope and ad hoc heroics.   

If you want to learn more about the Rock Crusher, you can order a copy of our book from the IIBA Bookstore.


[2] A. Martin, R. Biddle and J. Noble, “The XP customer role in practice: three studies,” Agile Development Conference, Salt Lake City, UT, USA, 2004, pp. 42-54, doi: 10.1109/ADEVC.2004.23.

[3] Kelly, A. (2019). The Art of Agile Product Ownership. Apress

What did 50 Business Analysts Say Were their Biggest Challenges with Backlog Management?

Our May 8th 2023 BBC Workshop : The Backlog is Broken – Here is How We Can Fix It

During our Rock Crusher workshop at Building Business Capability (BBC) we asked 50 Business Analysts to call out the challenges they were experiencing managing their backlogs. This is the raw data, and it is revealing:

    • Hard to prioritize among 3 different departments
    • Not enough developers or QAs
    • Hard to prioritize among 3 different departments
    • Backlog more about the process than business value
    • No clear goals
    • No fully transformed projects coming in with long end dates [that are] years out
    • No understanding or definition of ready
    • Too much work coming in
    • Doing work the old way
    • Fractured resources
    • No clear leadership for backlog
    • Siloed Dev/QAs
    • Never know what is enough or too much detail
    • Things change, and updates to are had to do in most places
    • Organizing takes thought
    • Scope changes and additions
    • Establishing priorities.
    • Large teams, greater than 20 “resources.”
    • Hybrid approach and not doing either well
    • Developers dictating code writing
    • Our products are small, and we don’t have a deep backlog. We work on multiple products at a time
    • Unnecessary user stories
    • Obsolete stories
    • Using Kanban instead of sprints
    • Loose prioritization
    • No discipline to follow the backlog and limit WIP
    • Not enough leadership support
    • User stories with end dates estimated poorly / unrealistically.
    • Making sure acceptance criteria is on user story
    • Changing priorities and assigning priorities
    • The external to do list that does not get proper prioritization or discovery work
    • Fluff in the backlog to justify needing more resources
    • Cross team planning and prioritization creates conflicting priorities
    • Lack of backlog grooming and clean up
    • So many parties involved with pulling from the backlog with lack of collaboration or prioritization.
    • Fear of forgetting a great idea
    • Many “shell” cards
    • Help find the “walking skeleton” and be confident it’s a good start
    • Too old not accepted as a reason to delete
    • Who owns the backlog? Makes the decisions? Too many cooks in the kitchen
    • Nice to have versus must have, MVP mis-understanding
    • Backlog not cohesive
    • Switching resources in the middle of projects
    • Prioritization! How?
    • Team maturity, some do not know where to start. Some don’t want to be told what to do
    • Tech debt sticks around
    • Prioritize once and don’t revisit
    • Backlog tool, new and different tools across company. Different ways to use it
    • Maturity
    • We say “later” and not “no”
    • Priority by line of business but value lost at solution level
    • Dependency management
    • Articulating the business value…who? Why?
    • Lack of discipline in ceremonies
    • How to stack up the non value add stories against the value add
    • Story writing
    • Prioritizing key items
    • Size of stories , right sizing for consumption
    • The requirements are not correct

I want to thank all our workshop participants for sharing with us. My first sad reaction to this data is there is nothing new here. I have seen this data before. I suppose there is some comfort in knowing colleagues from across the industries are experiencing similar challenges, and we are not some outlier.

There are numerous themes in this data, from too much WIP, lack of discipline, to no clear priority. It’s the “no clear priority” theme that really concerns me because this is pretty much why the backlog exists. The backlog is the single source of prioritized work the team pulls from. Prioritizing work means the team is working on the most valuable backlog items. Pulling work balances the limited capacity of the team with the demand for work by the enterprise. Pull systems avoid the coordination delays associated with high levels of work in progress and congestive collapse. For organizations that know their priorities, it is a system that predictably delivers superior economic value.

Unfortunately, this data suggests that for most of these enterprises, they do not know their priorities and the backlog is just a reservoir of un-prioritized pre-committed work for the team. What is worse is the data reveals numerous examples of where backlog items are pushed into the team rather than the team pulling the work (e.g. too much WIP, not enough team members, unrealistic due dates). The backlog is just a Gantt chart in disguise. As one participant called out “…hybrid approach [waterfall and agile] and not doing either well”.

Here is the bottom line, if our enterprise is not capable of saying “this before that” and is not capable of saying “no”, and if our enterprise cannot work as a pull-based system, then you will not gain any economic advantage from agile practices. Our workshop offered the Rock Crusher as a modern model for better backlog management. However, if an enterprise is incapable of deciding its priorities, then there is no agile framework or methodology that will do that for them, (outside of a random number generator). After all, the Rock Crusher and agile practices in general provide the fast learning cycles that can help you make better decisions. But they cannot make the decisions for you.

Where the < bleep > is my car? An Overlooked Lesson from Toyota

We in the SAFe community love to tell the story of Toyota and how its development and implementation of Lean concepts manifested by the Toyota Production System gave Toyota a massive manufacturing advantage. We love presenting the House of Lean and wowing our clients with words like Kanban, Kaizen, Muda, and Gemba. We love coaching organizing around the value stream and delivering a flow of value. We love this because we see the real benefit Lean and Agile thinking brings to an enterprise. However, there is another valuable but lesser known Toyota story we should tell and and that is the harsh economic consequences of a “broken” value stream

A value stream represents the series of steps for how we go from some trigger event to the delivery of value, or as we often like to say, “concept to cash”. Value stream thinking encourages us to take a systems view and optimize for delivery of outcomes rather than taking a more siloed view and optimizing for perceived local “efficiency”.  

A simplified example of a value stream

Mapping the value stream helped Toyota engineers learn where there were wasteful delays resulting and remove them. Taiichi Ohno’s dream was to minimize the time from when a customer ordered a car until when it was delivered.

A broken value stream is when the flow of value is interrupted and delayed because organizational silos or practices artificially segment the value stream. Up until the mid 1980s Toyota was hampered by a broken value stream. In a situation we often find ourselves in, the cause of their value stream breakage was their artificial distinction between “business” and “technology”.

In their book “Competing Against Time” and also in an HBR article [Time- The Next Source of Competitive Advantage, HBR July 1988], George Stalk and Thomas Hout tell the story of Toyota’s “broken value stream” and how it effectively squandered their manufacturing gains. Until the 1980s Toyota was organized as the Toyota Motor Manufacturing Company which built cars and the Toyota Motor Sales Company which sold and distributed cars – technology and business. In the late 1970s the Toyota Motor Manufacturing company could manufacture a car is less than two days. However, the Toyota Motor Sales company’s entrenched bureaucratic organization squandered this gain taking nearly a month to process a sales order and deliver a vehicle. According to Stalk and Hout:

“Twenty to thirty percent of the cost of the car – more than it cost to actually manufacture the car – and more than 90% of the time the customer had to wait was consumed by the sales and distribution function” [Stalk and Hout, Competing against Time, pg. 68]. 

We can imagine the frustration this created for Taiichi Ohno where the whole point of the Toyota Product Systems was to “…reduce the time line from when the customer gives us an order to the point we can collect the cash”.

In 1982 the frustration boiled over and two companies were merged. The executives and directors of Toyota Motor Sales were replaced by executives and directors who trained in Lean thinking. New processes and management information systems supporting those processes were developed. By 1987 the sales cycle was reduced from a month to 6 days from order to delivery of the vehicle. The benefit of this time compression was far more than just a cost saving exercise. The ability to compress time in this manner gave Toyota a massive competitive advantage because they were able to go from “selling whatever was on the lot”, to “selling what the customer wanted”. The benefit of this is huge because the short cycle times meant Toyota was able to exploit fast learning cycles and discover what cars customers wanted. By reducing their timelines and embracing change they not only were able to turn over units more quickly, they could also command higher margins on their sales.

What is the lesson we should take from this lesser known Toyota story? Far too many digital transformations follow the pattern of Toyota’s broken value stream with the same results. While our clients obtain some economic gain from the ability of their technology teams to predictably create economic value we may not have really made a significant difference in our client’s ability to deliver value to their customer. Technology is only one part of the value stream just like Toyota Motor Manufacturing was only one part of Toyota’s vehicle delivery value stream. To deliver customer value Toyota had to receive an order for a car, manufacturing the car, and then deliver the car. Just manufacturing a car creates little value.

A common example of a “broken value stream” in software development is the hybrid agile implementation , often referred to as “agi-fall”, or waterscrumming used by many organizations. Even in organizations adopting SAFe to inform their way of working we see this pattern. The technology teams eagerly organize around the flow of value, but only within their silo.

Broken Value Stream resulting from a hybrid agile implementation

While in this model we may be able to predictably create software in a very short period of time what have we gained if it takes a year or more to ideate, review, analyse, and fund a project before it is even seen by the technology organization? What have we gained if it takes several months to release software after its done?

In the Age of Software and Digital, just like Toyota, we risk squandering the gains of Lean-Agile adoption when our focus is only the technology side of the value stream or just a short segment of our value stream. To compete in the Agile of Software and Digital we need to learn Toyota’s lesson and not squander our technology gains. We need to remember Lean and Agile are not just IT or engineering science experiments.  Rather as Toyota learned they are strategies for successfully competing in the time compressed era of the digital business. 

It’s not ALL about costs. It’s about ALL costs.

Good cost discipline is a core capability of any successful enterprise and every manager knows the consequences of runaway costs. If not outright risking the viability of the business, broken careers, and loss of trust are often result of blown budgets. Software development gets a lot of attention because it is frequently one of the biggest – if the not the biggest – costs for many organizations. It is therefore not unreasonable for organizations to seek ways to reduce their software development costs. 

Agile methodologies and practices are often offered as an approach for not only reigning in but also reducing development costs. I have been at many clients where the primary motivation for adopting agile or going through a “digital transformation” was to reduce IT costs by some significant percentage, often 30 to 40% within two years. This is mis-guided. First, this turns the agile coaches into the hatchet people because everyone knows staff are the biggest component of software development costs. A 30 to 40% cost reduction means reducing head count by 30 to 40%. This is not going to inspire a lot of trust, cooperation and enthusiasm for adopting agile practices.

Second, focusing almost exclusively on development costs reduction risks increasing costs in terms of delays, inventory, over-processing and movement – the wastes of lean. While development costs is accounted for and visible, these wastes of lean are invisible and unaccounted for. Yet their impact can be more devastating than the development costs that appear as line items on the corporate ledger.

To illustrate this, let’s examine a past client to demonstrate how a sharp focus on development costs creates waste. At this client management was judged on their development cost performance and there were six teams working on a variety of different projects. Well the term team may be a bit of an aggrandization, because these were not dedicated agile teams. Rather these were project specific work groups with a Scrum Master and Product Owner.  Each “team” had responsibility for one project. People were frequently allocated to multiple “teams” to ensure their skills were efficiently utilized.

This multi-tasking across multiple projects increased the organizations work-in-progress, a source of waste. Most developers were on at least 2 teams and often had other operational responsibilities. The result was at any one time there were a large number of incomplete projects with incomplete features in progress. There was a lot of activity taking place but very little value delivered.  This is a classic example of the lean waste of inventory. Where is the line item for inventory? At least in manufacturing they do account for work in progress and manage their inventory levels. Why don’t we do this in software? The cost this inflicts is very real, yet we ignore it.

Worse, it is well known that such multi-tasking introduces a context swap tax – the time it takes an individual to switch from one task and get into the flow on another. Some studies place this tax at approximately 20%, while others suggest this may even be higher – up to 40% (Psychological Review, 104, 749-791, Multi-tasking: Switching Costs.   Retrieved July 17, 2012, from]). The implication of this is that to “efficiently utilize our staff” by keeping them close to 100% busy, we are effectively reducing their effective work week by at least one day, and perhaps even 2. In lean terms this is the waste of unnecessary motion, moving the machine or staff more than necessary. Where is the line item for this in our cost accounting?

Another cost saving was supposedly achieved by outsourcing testing to an overseas company some 12 time zones way. I’m assuming part of the pitch for outsourcing testing was not only were the overseas testers a quarter the cost of the domestic staff, but development work could take place around the clock. While it may be enticing to believe in a 24 hour development cycle story, it is certainly hard to achieve. Outsourcing of testing introduced the classic lean waste of transport where work is regularly shipped from one organizational  silo to another.  This created significant coordination delays between developers and testers. Clarifications, explanations, and rework cycles were significantly slowed by the time zone delay and this was exacerbated by the lack of a shared clear understanding of the system between development and test. These coordination delays along with other bottlenecks in the testing pipeline meant that test often ran two, and even sometimes three sprints behind the development teams, further increasing the work in progress. Of course there was no line item for capturing cost incurred for “transportation”

In an attempt to reduce these coordination delays, the organization unbeknownst to themselves, added in the waste of over-processing – doing more work than necessary to create value – to their invisible waste ledger. The business analyst wrote highly precise specifications that approached pseudo-code in their formality and it was not unusual to see 6 page user stories. The assumption was of course writing precise user stories would compensate for the lack of a shared clear understanding between development and test and therefore reduce coordination delays. This approach completely defeats the intention of a user story. User stories are not requirements that are thrown over the fence to an unsuspecting team. Rather, user stories facilitate development speed because they encourage a conversation between the team and the stake holders. These conversations quickly align the team and stake holders and reduce the coordination delays. Ironically writing detailed user stories didn’t have the intended effect because they just tended to confuse the test team even more. Where is the line item for the cost of over-processing?

So how could we start making these costs – the wastes of lean – visible? There are several tools we can use. First the use of a Kanban board can make “inventory” or work in progress immediately visible. Second, a cumulative flow diagram can show the relationship between work-in-progress and cycle time and help us answer questions like, how long does it take for us to get something done and what this the relationship between WIP and cycle time (getting something done).

Finally, show the true cost in dollar terms of all that “unfinished product” – that is value we cannot realize because the work is not done. Al Shalloway suggests “any waste in the system will show up as a delay” and this gives us a powerful tool to put a dollar figure to cost of this waste. All the wastes I described above, motion, inventory, transportation and over-processing will manifest themselves as delays in delivering value.  Let’s see if we can express in dollar terms the cost of these wastes by calculating the delay these wastes imposed on the initiative.

The goal of the initiative was to reduce call center costs and increase customer satisfaction by creating a self service portal for customers. We had a team of 11 people, and our “aggressive” plan forecast it would take at least 12 months to deliver the system. From my point of view, this just did not seem like a 132 staff month effort. It was mostly get some data from the data base, update it, put it back – bread and butter IT work. I asked the team, what would happen if we appropriated the conference room we were in, set up our workstations around the table and focused exclusively on this one system? The consensus was about 2 months, 3 months at the outside. So, call it 33 staff months.

It was estimated the self service portal would save about $45,000 per month for the organization. That means every month the self service portal was not in service, the organization gave up $45,000 of benefit. The invisible waste resulting from the near exclusive focus on development costs meant the company was delaying the release of the portal by 9 months and giving up $405,000 of benefit. Where is the line item for that? Of course the problem is this line item does not show up on the IT ledger, it is not IT giving up $405,000. Rather, it is some other siloed department in the organization. It’s not IT’s problem.

Not only were these costs another department’s problem, these delays were silently built into the project plan. Developers are asked for timeline estimates and gave those estimates based on their existing development practices, and then project management developed schedules, resource plans and business cases for these initiatives based on those estimates and resource allocations.  Now multiply that waste across multiple initiatives and you have a loss of value situation that should have impolite words coming out of the c-suite.

As a solution we proposed a simple backlog of initiatives, with true teams – not work groups with an Scrum Master and Product Owner – “pulling initiatives” when they were ready to swarm on it. In essence we proposed a simple form of lean portfolio management. When we proposed this alternative to our patron it was declined because it would mean risking the mandate to reduce per team cost. Our patron’s mandate was to get the cost of a “scrum team” down to 50K per month and he was now looking at completely outsourcing coding and testing. That was the line item on his IT ledger and not the loss of value the wastes created. His mandate was not maximizing throughput and delivered value.

Further, there were the political realities of the organization. Few project sponsors would accept their project being delayed so development teams could focus exclusively on getting another sponsor’s project done before starting theirs. Despite the fact they would get their project sooner, the thought of a “rival” manager getting their system earlier was so distasteful that they preferred to incur massive waste for the organization as a whole. Everyone acknowledged the cost of this waste, but there was no benefit to them for reducing that waste and in fact, there was a greater likelihood they would be sanctioned for not meeting their cost reduction targets if they tried.

While in my opinion this was not a successful agile organization, they were of the opinion their new operating approach was better than their previous classical waterfall approach. Their delivery was more predictable than what they had experienced in past. I suppose we can call that a success despite knowing how amazingly better the organization could be. The dark horse on the horizon is of course a competitor who does see how amazingly better they could be. A competitor who realizes it not all about costs, it is about all costs.

(c) 2020 Steve Adolph

Is Face to Face Still Ideal? Thoughts on Agile 2019

Note: I wrote this blog last year just after the Agile 2019 conference in August 2019. While interest in virtual consulting and training was finally moving from the fringes and into the mainstream, I thought it would be still at least 3 to 5 years before widespread adoption of virtual training and consulting. What a difference 9 months make. Now virtual could be the main service delivery mechanism as virtual work becomes the new normal. Tobias Lutke, CEO of the Canadian tech superstar Shopify said it simply, “…this is the end of office centricity”

The Agile Alliance “Agile” conference is arguably the premier agile conference. Each year some 2500 people gather together to learn, to see and be seen, to share ideas, and even share a few ideas over a few drinks.  The “Agile” conferences are great places to catch the pulse of the industry. Of course, business agility is the hot topic these days, but one undercurrent that really caught my attention this year at Agile 2019 in Washington DC, was the rising interest in online or virtual consulting and training. For the first time that I was aware of, there was a real buzz about delivering agile training and consulting services online. Not as a cheap substitute for development teams in far off lands, or those who do not apparently warrant “the luxury of in-person delivery” but rather as a legitimate and perhaps superior way of delivering services.

I was at agile to deliver an experience report which told the story of how we leveraged online assets to give everyone on a large globally distributed SAFe solution train an equal voice in the SAFe problem solving workshop. If you are interested in our experience report, you can find it at the agile alliance website “The Sun Never Sets on the Problem Solving Workshop”.  Our experience report was followed immediately by Joe Fecarotta of Accenture/SolutionsIQ who explained how he is successfully training and coaching Accenture staff online. Later Shane Hastie of IC-Agile (  lead a session on Training from the Back of the Room (TFTBR) online. For those not familiar with TFTBR, these are practices which move the instructor away from the classic “talking head, death by power point” model of course delivery to a more participative learning model. Take a look at Sharon Bowman’s website; if this interests you, and it should if you are doing any kind of training.  Shane’s session was about developing practices for developing online participative models that are consistent with the TFTBR principles. Looking around the well-attended session I noticed many agile coaches whom I consider thought leaders in our industry. Simply, virtual training is moving from the fringes to the mainstream.

I am convinced the time for virtual training and consulting has come for many reasons. First simply the collaboration technology has gotten way better. We have always believed that face to face is conversations are best, and in absolute terms this is true. However, online is beginning to offer a fair approximation of a face to face conversation. When the manifesto was written in 2001, the Internet and online collaboration technology were in their infancy. In 2001 I had dial up for access. Now I have 300Mbits/sec coming into my house.  It’s not just speed, it’s also the resolution of the HTML5 standards wars which means there are now amazing online collaborative tools. Second product development and especially software development is a global industry, and regular in person face to face meetings are often impractical. Third the millennials – sorry guys, I know you hate us old boomers referring to you this way –  are moving into leadership roles and with them there is a major organizational change in attitude towards online collaboration. These are people who grew up in an online environment and are totally comfortable working there. I often like to joke if educated and experienced engineers could do what my daughter does in Minecraft I would be out of a job – seriously, if you have kids watch them playing Minecraft. Fourth is cost, easily 20 to 25% of the cost of a consulting engagement is expenses. Either my customer would like to save that 20-25% or I would like to have that 20 to 25% go into my pocket rather than Air Canada’s and Marriott’s. But it’s not just monetary cost. It is also the physical and social costs on the people who have to regularly travel to deliver those services. There are fewer and fewer people who are willing to travel.

Given all this we have to ask, is it really necessary to have a coach or trainer onsite day after day, week after week? Recently a family issue prevented me from traveling to a coaching engagement, so I executed the engagement for the week using a variety of collaboration tools like Slack. In our opinions, I was just as effective working from home as if I had been onsite. Of course, I had already established a strong personal relationship with my client because I had previously been onsite. However, this was a clear indicator that I did not need to be physically onsite every week.  Furthermore, I am currently working a completely online engagement with a client where we are successfully launching a number of Scrum teams. We have delivered the all the training and coaching online. Of course, as per Shane Hastie’s Agile 2019 session, we had to re-design our course delivery style to leverage the online capabilities, but we were still able to deliver an interactive and engaging experience. Trainers and coaches do not need to be onsite week after week after week to successfully deliver services.

Finally, and most importantly there is an environmental reason for moving more of our work online and that is the carbon footprint for air travel.  While air travel only contributes between 2 to 3 % of green house gasses, it is the small cadre of frequent flyers like myself who make up the bulk of airline passenger. For me it’s a bit of a personal paradox because I try to live a low carbon lifestyle.  I don’t own a car, I mostly use transit or ride a bicycle. Then every week I fly across the North American continent expelling the equivalent of a year’s worth of driving in green house gasses.  It is not hard to notice there is already a backlash starting against excessive air travel. Some academics in Scandinavian countries now have to justify their carbon budget if they choose to travel to a conference. It would not surprise me that if in 5 years frequent flyers like myself will be frowned upon much in the same way as smokers were.

I want to leave something behind for my children, and if I can reduce my carbon footprint, reduce costs to my client, be in my own bed at night, and deliver as good or better experience then I am all for it. It’s time to follow our children’s leadership and join them online.

Apollo’s Legacy: A personal reflection 50 years after the first Lunar Landing

Apollo 11 astronaut Buzz Aldrin stepping off the LEM onto the lunar surface

July 21st marked the fiftieth anniversary of Neil Armstrong setting foot on the moon culminating one of the greatest human engineering achievements in history. I remember watching that first step on a friend’s black and white 25 inch console television set.  My first thought after recalling that moment at the 50th anniversary was “am I really that old?” But after that shock wore off my thoughts turned to value of the Apollo program. Was it worth it? After all the cost of that first step was the equivalent of hundreds of billions of dollars in today’s money.

Most people argue the benefits of the Apollo program in terms of the technological spin-offs. It is often suggested the modern semi-conductor industry would not exist today at least in its present form if not for the Apollo program. That may be, but I think the greatest legacy of the Apollo program was how it inspired whole generations to become excited about engineering as a career. How millions of young men and women were inspired, became engineers and worked to make people’s lives better.

Many people remember the late 60s as a time of social upheaval but many of today’s engineers remember it as the time that inspired them to become engineers. Not only the moon landing, but also TV programs and movies like Star Trek and of course Stanley Kubrick’s classic space ballet – 2001.  Both painted a picture of a future we not only wanted to live in, but to also create. I wanted to design and fly amazing space craft. I wanted to be one of the pilots of the Orion space shuttle or one of the engineers who designed and built the Clavius lunar base. Or the creator of HAL – the amazing and psychotic Artificial Intelligence controlling the Discovery.  I was going to create and live in the world of 2001.

The world I thought I would help engineer

Of course it was not to be. The reality was that in 2001 I wasn’t designing cool space craft or lunar bases. Rather I was sitting in a rather ordinary conference room on Earth in yet another project status meeting during the development of a new cellular telephone system. Somehow my career placed me in a cube farm designing telephone switches, and railway signalling systems.  I can’t recall a cube farm in Star Trek, or 2001. Nor do I recall project status meetings. Worse, later in my career I became a candidate passenger for the Golgafrincham “B” ark, and became a management consultant. It’s really, really hard to be stuck on Earth when your imagination is in the stars. Or is it?

For those not familiar with Douglas Adam’s “Hitchhiker’s Guide to the Galaxy, the “B” Ark was an attempt by the Golgafrinchams to remove all the “useless” people from their society such as account executives, public relations experts, and of course management consultants by telling them the planet was doomed. The Golgafrinchams gave  them the “privilege” of being the first to leave Golgafrincham aboard a giant space ship called “B” Ark.

Where Project Managers and Management Consultants may end up

Even though I didn’t get to design moon bases and space craft, much of the work I did created value for a lot of people. The work I did with thousands of others designing digital exchanges and cellular telephone systems dramatically improved the communications services available to millions of people around the world. Railway signalling enabled cities to increase the capacity of their transit systems. Maybe not as cool as a lunar base, but we made a difference in peoples’ lives. More than that I got to work with many amazing people and I even had fun doing it – maybe with the exception of the project status meetings.

While the technological spin-offs of the Apollo program are always cited as its lasting economic legacy, I think it was how the program inspired so many of us to become engineers. We didn’t get to build space stations or lunar based or psychotic AIs, but we created wealth and comfort for many.  Every day people make phone calls, take a train to work, watch television, drive their car, turn on an electric light and get a drink of water without any thought does of the extraordinary efforts made to create this world.  For me this is what it means to be an engineer, we make people’s lives better, and no one has to give a second thought about it.

So, what will be the next great engineering achievement that will inspire the upcoming generations of younger engineers. While I would like to think of an Apollo repeat, that is a Mars landing, I don’t see that has having the same impact as the original moon landing. We have done our job well and space exploration is just yet another interesting domain, one among many. What, I see in the so called “millennials” and generation “z” is an overpowering desire to make the world a better place. David Pink argues that people are purpose driven and the current generations of children and young engineers are inspired by making the world a better place more than ever. Coping with climate change, developing new energy sources and distribution systems, ensuring there is enough food, clean water, and proper shelter for a future with 8 billion people.  Building the systems and creating the wealth that allow all those 8 billion people to live in comfort and dignity while realizing their aspirations will be our greatest engineering achievement.

Is “Business Agility” the Future of Agile? – Thoughts from XP2019

The Future of Agile Panel at XP2019

I just got back from a week inMontreal where I had the opportunity to actively participate in XP2019, the Agile Alliance’s 20th International Conference on Agile Software Development (, co-chairing the experience report track with Rebecca Wirfs-Brock and filling in as the Leadership symposium chair. XP2019 describes itself as a forum where Agile researchers, practitioners, thought leaders, coaches, and trainers get together to present and discuss their most recent innovations, research results, experiences, concerns, and challenges, and debate the latest trends. It’s a small and intimate conference where both practitioners and researchers are able to look beyond “the edge”. In keeping with this billing, and with it being nearly 20 years since the fabled Snowbird meeting, the theme for this conference was “Agile – The Next 20 years”.

With the growing awareness of “business agility”, one question raised was “is business agility the future of the agile movement?” There is no shortage of pundits now pitching “business agility” and, in this age of disruption, only the agile will survive – so clearly it’s time for agility to move beyond the data center to across the enterprise. I was able to “officially” contribute my point of view as a panelist on the Business Agility panel. From my perspective, the thought that somehow the agile software community is leading business to a bright “business agility” future is somewhat strange because, in my humble opinion, agility was a well known business competition strategy long before the famed skiing vacation at Snowbird.

We in the agile software development community can be a little myopic, only seeing the world through the lens of the Agile Manifesto. Agility as a business strategy is an old concept – perhaps a century old, perhaps even older. One only has to do a little research to find many writers and business thought leaders, such as Stalk and Thomas – Competing Against Time , Verne Harnish’s Rockefeller Habits, Chet Richard’s Certain to Win, and of course Jim Collin’s Good to Great all describing agility as a business success strategy in the mid 80s and even earlier. My favourite definition of agility comes from Colonel John Boyd who, in the 1950s, developed the so called Observe-Orient-Decide-Act (OODA) model []. To paraphrase Colonel Boyd, agility is “learning faster than your competitors and/or the rate of change”. Lovely, simple, succinct. It does not take a manifesto of software development, or much imagination, to know what happens if you are learning slower than your competitors or slower than the rate of change. This definition moves agility from an inward software-centric focus of “…better ways of developing software…” to a focus on business outcomes – business success. The corporate landscape is littered with marquee companies who learned more slowly than the rate of change or their competitors. I am willing to wager some of those failed companies even had agile software teams – anyone remember Nokia? In the age of digital disruption it would seem that business agility is certainly a concept whose time has come.

However, I am ambivalent about the term “business agility”. For better or worse, we in the software community appropriated the term “agile” without fully acknowledging agile history. There is much we can learn from others and from history. Optimistically, I hope the term “business agility” will be the solvent that finally dissolves the artificial barrier between “the business” and “IT” because, the last time I looked, IT is part of the business and not some bag on the side. This artificial barrier not only delays the ability for the business to bring new products and services to market – think a bank wanting to offer a new kind of bank account or loan service – but also delays validating the business hypothesis of that product or service. We only learn if the product or service is valuable when it finally goes into service. This artificial barrier slows the build-measure-learn cycle. I am excited by the possibility of large enterprises becoming more nimble and able to respond faster to their customers needs and changing market dynamics. Business agility could create powerful teams that can exploit all of an organisation’s capabilities to quickly learn and validate a new business hypothesis. IT is no longer a cost center, but rather a strategic part of the business.

My greatest concern is that “business agility” will become a sales mantra to bring a myopic manifesto to the business. “Business agility” will be used to sell certification courses beyond the software teams, such as Scrum for HR, Product Owner training for marketing, “agile” accounting for CAs and CPAs. People will be able to add additional two and three letter designations to their e-mail signatures. Retiring project managers will have a second career as certified agile business coaches. Organizations will prefix their operations with “agile” and someone will claim to have a magic recipe that turns a company into a fast moving agile business. We’ve seen this movie before and it does not end well.

Two underlying themes emerged at XP2019… Has agile been commodified and gone off the rails? Is there a future for agile as we currently know it? These are juicy topics for future posts. For now, we need to focus on taking a pragmatic approach and recognizing that “agile” has a rich history and encompasses a wide range of ideas, and is continuing to evolve. There is no “one size fits all” solution. We need to help companies identify what they need to learn and understand in order to grow into more profitable and sustainable enterprises. Our pursuit of “business agility” is just beginning and there is a lot for us learn.

Are You Really the Product Owner? No Really?

Are you really the product owner?

The product owner role is a manifestation of the agile manifesto’s values, particularly – “Customer interaction over contract negotiations” and  “Individuals and Interactions over processes and tools”.  The product owner provides delay busting leadership and clarity for the team. The conversations with the product owner facilitated by user stories align the product owner and the team on a shared vision.  Rather than slow the development cycle and suppress learning through comprehensive documentation and change control boards, the product owner directly interacts with the team to learn what is really needed. From that learning the team and product owner refine, and reprioritize the backlog to maximize value. The product owner is a value manager, exploiting fast learning cycles to re-prioritize the and revamp the backlog. Without an engaged product owner there is only at best incremental development. There is no agility.

One of the most common bad smells in many agile environments is the disengaged or unavailable product owner. However, there is a more insidious variant of this problem, one that can creates the appearance of an engaged product owner but in reality the product owner is dis-interested in and disengaged from the majority of the work team is responsible for.

In this variant of the dis-engaged product owner, the supposed PO is responsible for a specific project – or even a set of projects – that the team is works on.  The problem is the team has other work in their backlog besides the PO’s pet projects. This may be more than the usual on-going maintenance, support, defect fixes, and the inevitable shoulder taps a development team must cope with, but also possibly work on other projects that are not in their PO’s portfolio. The team is effectively left to fend for themselves on prioritizing and managing this “dark” or “off balance sheet” work.

i uses the term dark work as a metaphor for matter that is invisible but has significant affect. The problem with this dark work is that it is invisible, and therefore not managed. But like dark matter its effect on the team is significant, even destructive. Or as  my other metaphor “off balance sheet” work implies, dangerous liabilities that is not being accounted for.   It is critical that all team work is visible because if it is not visible then value cannot be managed. Very simple, if you are the product owner, then you are responsible for all work in the team’s backlog.

Bad smells that are symptoms of this problem include team members talking about their “day jobs” or a team with multiple backlogs. One backlog that is well managed by the PO and the other that is managed ad hoc by individuals of the team. This blindness lets us live for a while in fool’s paradise. For the product owner they are not forced to make hard choices between their pet project and all the other work the team needs to do to keep the lights on. And then we wonder why so many agile teams have lousy SAY/DO metrics.

Personally I think the term “product owner” is misleading because it implies responsibility for a specific product. In the modern agile context, a product may only be a subset of the teams overall work. The term product owner is a carryover from the early days of agile methodologies when the exemplar teams in the early textbooks were focused building a single product and the product owner represented the beginning and end of the value stream. Today most agile teams work in complex multi-system environments, and all of that work from multiple sources comes to the team and all of that work should be in one team backlog. The agile development team is one step in the value stream. So our model of the agile development team also needs to be updated.

I think we need to start thinking of the product owner as a “backlog owner” who is responsible for everything the team works on. Those who own a specific initiative or product are not “product” owners unless they can also take on the backlog owner role. The Scaled Agile Framework actually explicitly calls this out these different roles distinguishing between an “epic owner” role and a product owner role. While the same person may fulfill both roles, it is clearly states the interests of the EO may diverge from the PO role.

So be honest with yourself, are you really the product owner? Are you really interested and capable of working with the team to prioritize all the work in the backlog. You don’t have deep technical knowledge of everything in the backlog. The team can advise you and make recommendations. While the buck does stop with you, product ownership is still a negotiation, but it’s a negotiation about all the work, not just the bit you are interested in.

Put the Backlog at the Center of the Team!

The Backlog at the Center of the Team

Most models of agile software development portray the product backlog outside of the team. This is because, with the original small team focus of agile methodologies, the world began and ended with some kind of customer representative. For example, in Scrum, there is a Product Owner who is responsible for ensuring the team has a “ready” supply of backlog items and accepts the increment of working software delivered. What happens beyond the Product Owner is apparently not the team’s concern, and the team does not care how the Product Owner got the concept, how the analysis was performed, or how the design was created, just as long as they are not starved for stories.

“Coding centric” view of the backlog

From my point of view, this traditional view encourages a coding-centric view of agility and is misleading because it implies the purpose of the entire organizational ecosystem is to supply a software team with near “ready” backlog items which the team codes and tests into “working software”.

Coding is but one step in the creation of a valuable product, and to view agile teams strictly as just “design-build-test” teams is to completely devalue the work done by everyone else in the value stream. Nearly 40 years ago, in an article entitled “No Silver Bullet: Essence and Accidents of Software Engineering” (IEEE Computer, Vol. 20, No. 4. April 1987. pp. 10-19. Accessed 7 July 2019., Frederick Brooks wrote:

The hardest single part of building a software system is deciding precisely what to build.”

While there is clearly no valuable software product without “working software”, there is certainly no valuable product without the analysis and design to determine precisely what to build. It’s not enough to build the thing right, to create value we also have to build the right thing. It is wrong to offload and sweep under the carpet the hardest part of systems development to some undefined upstream process just to create the illusion of coding agility. Analysis and design still matter.

What if, rather than representing the backlog as a means for just “feeding” a development team, we call out ALL the work required to create a product or service and show EVERYTHING the team is fully responsible for. They are responsible for all the work which must be done to deliver each increment of working software –  not just coding and testing, but also analysis, design, and whatever other upstream and downstream activities are necessary to go from concept to cash. We have seen far too many organizations where analysis and design work is “invisible” or managed using a traditional stage gate model.

A More Comprehensive View of the Backlog

Placing the backlog at the center of the team is an attempt to create a new visual where the whole team is responsible for all the steps required to create product, from ideation to delivery. The whole team not only builds the system, but is also involved in “…deciding precisely what to build”. The whole team performs the analysis, design, implementation, and deployment steps.

This means that everything we pull into planning will not necessarily be written as a traditional user story that yields some idealized slice of feature functionality. There are going to be backlog items representing analysis, design, packaging, and other work. For example, during a Scrum-style sprint planning meeting, a Business Analyst may take on the work to model some of the backlog items, perhaps to create a use case brief for a feature.

Don’t get me wrong, I am not advocating for traditional long drawn out analysis. Agility is about fast learning cycles, and our analysis and design needs to be part of the fast learning cycle. While the output may not be production ready “working software” – the output still needs to add verifiable knowledge that creates valuable learning. Pulling a line from the Scrum guide, any work we pull into a sprint from the backlog should still “… include test descriptions that will prove its completeness when done”. Just showing a “textbook-perfect” use case diagram at a sprint review is not useful.  Rather, if we pull a backlog item to “analyze and design,” there still has to be value generated in the form of validated learning. There has to be some demonstration, some proof that the model works – perhaps a code fragment implementing a slice of the model, an executable simulation, or even just a walk through. While we are arguing against a coding-centric view of agile teams, the intent behind the Agile Manifesto value statement “working software over comprehensive documentation”, that is getting something valuable done still applies.

Some may legitimately raise a red flag here suggesting that I am encouraging the waterfalling of sprints – a sprint to analyze, a sprint to code, a sprint to test. This can indeed happen, but I would prefer this problem be explicit and an issue the team can work to resolve in a retrospective, rather than sweeping it under the carpet and having the team believe they are truly agile and righteous. My argument is for making ALL the work visible. Placing the backlog at the center brings all those other people, who are traditionally thought of as being on the outside, and makes them visible and part of the team. It encourages us to apply agile thinking to analysis and design and whatever other processes are required to transform an idea into a valuable product or service.