Sometime the intangible obscures the tangible.

Sometime the intangible obscures the tangible.

In the Software Process and Measurement Cast 37, Kenji Hiranabe suggested that both software and the processes were intangible and opaque.  In SPaMCAST 36, Phil Armour put forth the thought that software is a container for knowledge.  Knowledge is only tangible when demonstrated, or in software terms, executed.  Combining both ideas means that a software product is a harness for knowledge to deliver business value; delivered using what is perceived to be an intangible process. The output of the process is only fully recognizable and testable for the brief period that the code executes. On top of all that, there is every expectation that the delivery of the product will be on-time, on-budget, high quality and be managed and orderly.  No wonder most development managers have blood pressure issues!

Intangibility creates the need for managers and customers to apply controls to understand what is happening in a project and why it is happening.  The level of control required for managers and customers to feel comfortable will cost a project time, effort and money that could be better spent actually delivering functionality (or dare I say it, reducing the cost of the project).  Therefore, finding tools and techniques to make software, and the process used to create software, more tangible and more transparent to scrutiny, is generally a good goal.  I use the term “generally” on purpose. The steps taken to increase tangibility and transparency need be less invasive than those typically seen in command and control organizations. Otherwise, why would you risk the process change?

Agile projects have leveraged tools like WIKIs, standup meetings, big picture measurements and customer involvement as tools to increase visibility into the process and functional code as a tool to make their knowledge visible.  I will attest that when well-defined Agile processes are coupled with proper corporate culture, an environment is created that is highly effective for breaking down walls.  But, (and as you and I know, there had to be a “but”) the processes aren’t always well defined or applied with discipline and not all organizational cultures can embrace Agile methods. There needs to be another way to solve the tangibility and transparency problems without resorting to draconian command and control procedures that cost more than they are normally worth.

In his two SPaMCAST interviews, Mr. Hiranabe laid out two processes that are applicable across the divide defined by waterfall and Agile projects.  In 2007 on SPaMCAST 7, Kenji talked about mind mapping.  Mind mapping is a tool used to visualize and organize data and ideas.  Mind mapping provides a method for capturing data concepts, visualizing the relationships between them and, in doing so making ideas and knowledge tangible.  In the SPaMCAST 37, Kenji proposes a way to integrate kanban into the software development process.  According to WIKIPEDIA,  “Kanban is a signaling system to trigger action which in Toyota Production System leverages physical cards as the signal”.  In other words the signal is used to indicate when new tasks should start, and by inference, the status of current work.  Kenji does a great job at explaining how the kanban can be used in system development.  The bottom line is that the signal, whether physical or electronic, provides a low impact means of indicating how the development process is functioning and how functionality is flowing through the process. This increases the visibility of the process and makes it more tangible to those viewing from outside the trenches of IT.

Executed code that does what was expected is the ultimate evidence that we have successfully captured knowledge and harnessed it to provide the functionality our customer requested.  The sprint demos in Scrum are a means of providing a glimpse into that knowledge and to build credibility with customers.  However if your project is not leveraging Scrum, then daily or weekly builds with testing can be leveraged to provide some assurance that knowledge is being captured and assembled into a framework that functions the way that you would expect.  You should note that demos and daily builds are not an either/or situation.  Do both!

The lack of tangibility and lack of transparency of the process of capturing knowledge and building the knowledgeware we call software has been a sore point between developers and managers since the first line of code was written.  We are now finally getting to the point where we have recognized that we have to address these issues; not just from a command and control perspective, but also from a social engineering perspective.  Even if Agile as a movement was to disappear tomorrow, there is no retreat from integrating tools and techniques like mind mapping and kanban while embracing software engineering within the social construct of the organization and perhaps the wider world outside the organization.  Our goal is to make tangible what intangible, and visible that which is opaque.

Less is more.

Less is more.

In terms of product owners, less is more. Any solution to the complications of scaling the product owner role for a specific piece of work should keep the product owner activities in the hands of a single person. For a single team, a single product owner should prioritize the backlog, and the team should hear the voice of a single product owner. However, as projects grow, eventually there will simply be too much for a single product owner. There will just be too many teams for a product owner to be effective. In that case, there are a number of techniques that can be used mitigate the complications so that the teams can tackle a larger effort.

  • A guidance team is a group of stakeholders that provide guidance to a product owner or group of product owners. A guidance team is also a ready-made pool of SMEs to provide product depth to the development team(s) as they flesh out, test and build functionality. The guidance team is conceptually similar to the classic steering committee used in many organizations as a governance tool; however the focus is on guiding the functional evolution of the project or product rather than acting as a mechanism to control the budget or to monitor status. The guidance team is a mechanism to consolidate guidance to a product owner or owners when there are multiple external constituencies. External constituencies can reflect the needs and wants of internal applications, functional department (eg marketing or accounting) or external customer groups.
  • Product management groups are like a specialized form of a guidance team that often exists in organizations that create products that are sold or are consumed by customers outside of the company. Typically, product management is a powerful force within product-oriented companies, and acts as the voice of the customer. Product management often guides product owners by developing an overall product roadmap that provides product owners, development and exteral customers with an understanding of how they intend the product to evolve. Roadmaps tend to be more specific in the short-term while more aspirational in the longer term. Note: Product owners are often members of the product management group.
  • The best ratio of scrum masters to product owners is 1:1. This increases the possibility of a close bond between the people playing the two roles. Every additional scrum master added to the equation requires the PO spread his/her attention and increases efficiency loss caused by switching between teams. One common coping mechanism in scenarios where a PO interfaces with multiple scrum masters is for the PO to be responsible for a single backlog. The product owner to backlog ratio of 1:1 provides an anchor for the PO’s attention. The anchor of a single backlog reduces the amount of overhead a bit so that a PO can support a few teams. The vagueness in the statement is intentioned as business and technical complexity and personalities affect whether a PO can interact with multiple scrum masters effectively.

Interactions between product owners and stakeholders, teams, scrum masters and even other product owners are part and parcel of how product owners work and a path for them to help to facilitate the delivery of value. As projects are scaled, the product owner’s role gets more complex. Finding a path to mitigate the complexity is rarely straightforward. Every organization adopts techniques that they feel will generate the most value by balancing overhead with outcome.

Listen Now

Subscribe on iTunes

This week’s Software Process and Measurement Cast features our interview with Chris Nurre.  Chris is a developer and Agile Coach extraordinaire. We explored the role of an Agile coach from the point of view of someone that is actively involved in delivering code, both technically and as a change agent.

Chris likes to keep his bio short and sweet:

Chris is an Agile coach, Apple developer and Clevelander. Co-organizer of Cleveland Agile Group #CleAG

Chris’s contact data:

Call to Action!

Review the SPaMCAST on ITunes, Stitcher or your favorite podcatcher/player and then share the review! Help your friends find the Software Process and Measurement Cast. After all, friends help friends find great podcasts!

Re-Read Saturday News

Remember that the Re-Read Saturday of The Mythical Man-Month is in full swing. This week we tackle the essay titled “The Whole and the Parts”! Check out the new installment at Software Process and Measurement Blog.

Upcoming Events

Agile Development Conference East
November 8-13, 2015
Orlando, Florida

I will be speaking on November 12th on the topic of Agile Risk. Let me know if you are going and we will have a SPaMCAST Meetup.


Agile Philly – AgileTour 2015
October 5, 2015

I will be speaking on Agile Risk Management


The next Software Process and Measurement Cast will be a special show.  We are going to feature the “if you could fix any two things” question I asks at the end every interview from the three most downloaded interviews of all times.

PS I will visiting Krakow and Prague over the next few weeks shoot me an email and let me know where the best places to get a beer are found!

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.



The Mythical Man-Month

The Mythical  Man-Month

The Whole and the Parts is the thirteenth essay of The Mythical Man-Month by Fred P. Brooks. In this essay, Brooks posits the question “How do you build a program or system to work?” The components of a system that “works” must operate together while delivering the functionality needed in a dependable manner.

The process of ensuring what is built “works” begins by designing bugs out. Brooks breaks this section down into four steps that build on each other.

  1. Bug-proofing the definition: The word “definition” combines the wants and needs of the users with the assumptions of developers or authors. Mismatched assumptions cause the most harmful and subtle bugs. Brooks circles back to the idea of conceptual integrity discussed in the essay, Aristocracy, Democracy and System Design. Conceptual integrity (the whole systems proceeds from one overall design) makes any piece of work easier to use, easier to build and less subject to bugs. Conceptual integrity also supports simplicity, one of the core principles of Agile.
  2. Testing the specification: Brooks suggests handing the specifications over to the testers before software code is written. The testers will review the specs for completeness and clarity. Peer review processes or test first development practices deliver feedback that improve the chances that the system will work.
  3. Top-down design: The concepts of top-down design are based on the work of Niklaus Wirth. Wirth’s methods are to identify the design as a sequence of refinement steps. Brooks describes the procedure as sketching out a rough definition and rough solution that achieves the principal result. The next step is to examine the definition more closely to see how the results differ from what is wanted (feedback). Based on the refinements, the next step is to break the large components into smaller steps (grooming).The interactive process of breaking working into smaller and smaller chunks while generating feedback sounds suspiciously like lean and Agile.A good top-down design avoids bugs in several ways. First, the clarity of structure makes the precise statement of the requirements and functionality easier. Second, the partitioning and independence of modules avoids system bugs. Three, the suppression of details makes flaws in the structure more apparent. Four, the design can be tested at each step during its refinement.
  4. Structured programming: Focuses on using loops, subroutines, and other structures to avoid unmaintainable spaghetti code.

In the second major section of the essay on component debugging, Brooks describes four types of debugging, including machine debugging, memory dumps, snapshots and interactive debugging. While each of these types of component-level debugging are still in use today, how they are done are fundamentally different. Very few developers under forty have ever read a dump or had to translate hex to decimal. While much of the section is a walk down memory lane, it is a reminder that testing and defect removal is not just an event after all the code is written.

In the third section, Brooks builds on his earlier comments about the unexpected difficulty of system testing. Brooks argues that the difficulty and complexity of system testing justifies a systematic approach. First begin by using debugged components for system testing. Beginning with buggy components will yield unpredictable. In other words, do system testing after component debugging. Second, build plenty of scaffolding. Scaffolding provides teams with the ability to begin system testing before all components are done generating earlier feedback. Third, control changes to the system. Testing a system that is subject to random changes will generate results that will not understandable, which increases the chance of delivering poor quality. Fourth, Brooks suggests adding one component at a time to the system test (incremental integration and testing). Building on a known system generates understandable results, and when a problem appears the source can be isolated quicker. Fifth, quantize updates (make changes of fixed size), which suggests that changes to the system should either be large (releases) or very small (continuous integration), although Brooks states the later induces instability. Today’s methods and tools have reduced the potential for problems caused by smaller quanta of change.

The ideas in this essay are a path to verifying and validating software. While it might seem like a truism, Brooks reminds us that building software that works starts well before the first line of code is eveN written.

Previous installments of the Re-read of The Mythical Man-Month

Introductions and The Tar Pit

The Mythical Man-Month (The Essay)

The Surgical Team

Aristocracy, Democracy and System Design

The Second-System Effect

Passing the Word

Why did the Tower of Babel fall?

Calling the Shot

Ten Pounds in a Five–Pound Package

The Documentary Hypothesis

Plan to Throw One Away

Sharp Tools

For a Product Owner, a larger teams means more complexity!

For a Product Owner, a larger teams means more complexity!

As organizations find that using Agile delivers higher levels customer satisfaction, higher quality and greater efficiency and effectiveness, they try Agile in more situations. One of the most common scenarios that organizations struggle with as they expand their use of Agile is with larger and larger projects. One common stumbling block is implementing the product owner at scale. Getting the product owner role wrong is a problem. The product owner plays a pivotal role in an Agile project. One of the critical aspects of the product owner role is the relationship between the product owner and the team, stakeholders/customers and Scrum masters. As projects are scaled, these relationships become more complicated.

Product Owner to Team(s): On paper, the relationship between a product owner and team is fairly straightforward. The product owner owns and prioritizes the backlog, provides a product vision, involves customers, users, and other stakeholders and collaborates with others on the team. But, the role is more complicated; the product owner is also a leader, mentor, politician, and confidant, just to name a few roles. Add more teams to a product owner’s plate, and the relationships get even more complicated because the number of possible combinations required at any one time increases.

Product Owner to Stakeholders/Customers: The product owner is the primary facilitator and connector between the team or teams and external stakeholders. The product owner gathers needs and priorities that he or she leverages to prioritize the backlog. As projects become larger, the pool of stakeholders and customers will increases, which will complicate the role of the product owner. It requires judgment and tools to balance needs as in order to prioritize. As a project grows the number of groups of customers and stakeholders generally increase.

Product Owner to Scrum Master(s): The relationship between the product owner and Scrum Master(s) should be fairly straightforward. The product owner prioritizes, makes decisions and connects the team with stakeholders, while the Scrum Master mentors and facilitates the team. My observation is that real life is more complicated. The two roles often blur based on the personalities of the people involved. As the number of teams and Scrum Masters increase things get messy if roles blur. Since the relationship between each combination of product owner, Scrum Master and team might be slightly different, it will be difficult to predict the outcomes of interactions as people and groups involved in the project randomly work together.

If a large project chooses to leverage several product owners, the potential combination of relationships between the additional product owners and the stakeholders, teams and Scrum Masters increases dramatically, as does the level of complexity. We will discuss this possibility later in this series on scaled product owners.

The relationship between product owners and other constituencies in a project gets more complex as the number of parties increase. Complexity requires a proactive mitigation to avoid the possible negative aspects, such as communication failure, quality issues, reduction in efficiency or simple project failure. We will tackle techniques to mitigate the complexity that scaling an Agile project can cause in the product owner role in the next installment.

Audio Version:  SPaMCAST 133


A burn-up chart is a graph that tracks progress by accumulating a measure of functionality as it is completed over time. The measure of functionality can be compared to a goal, such as a budget or release plan, to provide the team and others with feedback on progress. Graphically the X axis is time and the Y axis is accumulated functionality completed over that period of time. The burn-up chart, like its cousin the burn-down chart, provides a simple yet powerful tool to provide visibility into the sprint or program.

The burn-up chart can be thought of as the mirror image of the burn-down chart, but it is generally extended over multiple sprints to show progress as the project builds toward release and product delivery.


As with its close cousin, the burn-down chart, there is not really a formula for a burn-up chart as much as there are instructions on how to graphically represent progress against a goal. In its simplest form, the X axis represents time (days, sprints, or releases) and the Y axis represents the accumulated functionality completed over that period of time (stories, value or cost).

Using the basic form of the graph as a base, other data can be integrated. The release plan, which typically includes an outline of the funcitonaity (in story points or function points) for a number, can be overlaid on the chart to give visibility into the anticipated flow of the project. The project budget can be added to the chart to provide feedback on budget utilization; the budget line can be raised or lowered to show how much work remains as changes to scope are incorporated. Value can be tracked on a second Y axis to show the team the relationship between work and value. The burn-up chart is one chart covering the big three topics of on-time, on-budget and on-schedule.


The burn-up and burn-down charts have many similar uses such as planning and monitoring. Rather than repeat the discussion already published in the Metrics Minute: Burn-Down Charts, I will focus on the major distinctions between the charts. The unique power of the burn-up chart can be found in its ability to provide a holistic view for the project. The view is holistic because the chart can be used to show progress over sprints and releases. To use a photographic analogy, the burn-up chart provides a panoramic view rather than a normal picture, which is narrow slice of real life.

James Shore suggests developing a risk-adjusted burn-up chart to make and meet commitments.  It tracks commitments alongside progress. Adding a continually refined risk-adjustment to the burn-up chart accounts for Steve McConnell’s cone of uncertainty (the cone of uncertainty theorizes that plans are less accurate the farther in the future they are projected). Actual performance (delivered functionality) can be tracked against commitments; significant gaps would signal a need to adjust the release plan if performance strays to far from what is possible as established by the cone of uncertainty.


One issue is that a burn-up chart provides visibility at a high level, rather than progress at a story level. This causes some people concern. Burn-up, like burn-down charts, are not designed as a precise report on where each story is on a day-to-day basis, but rather as a view of how functionality or value has been delivered. The burn-down chart and the detail found in a card wall (or proxy) are better tools to drive a project on a day-to-day basis.

The second issue occurs because value is recognized only when a piece of work is complete.  In software projects, this equates to functional code that has been integrated and tested.  Value is not recognized until work in process is complete.   Alistair Cockburn suggests recognizing functionality when ‘done’ yields more reliable information about the projects actual state than the classic plan based mode. The problem is that if the increment of work is too large the graph will resemble a J with the majority of value accumulating late in the sprint leaving room from negative surprises. The way to avoid this issue is to increase the granularity of the units of work (break the work down in smaller pieces). This will allow the team to recognize value more quickly, and therefore smooth out the curve.

The third issue is also related to the choice of unit of measure for use on the vertical axis. The unit needs to be predictable early in the process. Most physical measures, such as lines of code, can’t be known until you’re very near the end of the sprint or projects. Leveraging a metric that can expand even though scope has not changed muddles the information provided by the chart, thus reducing its usefulness. This issue can be avoided by choosing unit of measure that can’t expand unless additional work is accepted into the sprint or project.  Functional measures, such as Quick and Early Function Points, that translate stories or requirements into numbers are a disciplined/formal mechanism for addressing the unit of measure issue without adding overhead.

Related or Variant Measures

  • Functional Size
  • Velocity
  • Burn-down Charts
  • Earned Value
  • Productivity
  • Cumulative Flow Diagrams


The most significant criticism of the burn-up chart is that, in its basic form, it does not reflect the flow of work.  Work in some sprints does not lead to completed functionality, therefore value is not accrued. This leads to a feeling that partial credit should be given, splitting stories using waterfall stages or other bad practices all in a rush to show progress.  One solution is to use flow metrics by using techniques like Kanban and cumulative flow diagrams is a way of accruing value on a more granular basis if the organization can’t find a measure to split user stories so they can be completed properly in a single sprint.

The final criticism is that burn-up charts do not predict surprises.  This is a false criticism as a surprise by definition is not predictable.  Use the value at risk metric as a risk management tool to help avoid surprises, but vigilance should never be supplanted by measurement.


Listen Now

Subscribe on iTunes

This week’s Software Process and Measurement Cast includes two columns.  The first is our essay on software measurement. When we measure we are sending an explicit message about what is important to the organization, and therefore sending an explicit signal about how we expect people to act. Remember the old adage, “you get what you measure.”

Our second column this week is from Gene Hughson and his Form Follows Function blog. In this installment Gene throws down the gauntlet to ask the questions, “Who needs architects?”

Call to Action!

For the remainder of September let’s try something a little different.  Forget about iTunes reviews, and tell a friend or a coworker about the Software Process and Measurement Cast. Let’s use word of mouth will help grow the audience for the podcast.  After all the SPaMCAST provides you with value, why keep it yourself?!

Re-Read Saturday News

Remember that the Re-Read Saturday of The Mythical Man-Month is in full swing.  This week we tackle the essay titled “Sharp Tools”! Check out the new installment at Software Process and Measurement Blog.


Upcoming Events

Agile Development Conference East
November 8-13, 2015
Orlando, Florida

I will be speaking on November 12th on the topic of Agile Risk. Let me know if you are going and we will have a SPaMCAST Meetup.

Agile Philly – AgileTour 2015
October 5, 2015

I will be speaking on Agile Risk Management

More conferences next week, including Agile DC!


The next Software Process and Measurement Cast features our interview with Chris Nurre.  Chris is a developer and Agile Coach extraordinaire. We explored the role of a coach from the point of view of someone that is actively involved in changing the world, one team at a time.

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.



Get every new post delivered to your Inbox.

Join 4,671 other followers