Star of India, San Diego, CA

Star of India, San Diego, CA

I wasn’t born on the 4th of July, but my wife was.  This week we have a perfect storm of activities that have conspired to postpone the second installment of the Re-read of The Mythical Man-Month: Essays on Software Engineering this Saturday. Birthday day for my wife, national holiday and family reunion are keeping me away from the keyboard today.  So please pardon the interruption!

Individually, each boy is a project. Together they're a program to be managed.

Individually, each boy is a project. Together they’re a program to be managed.

Scaling Agile project management to large, complex endeavors requires an Agile Program Manager to address the big picture coordination of programs.  Program management is the discipline of coordinating and managing large efforts comprised of a number of parallel and related projects. Scrum leverages a concept called the Scrum of Scrums to perform many of the activities need for program management.  Agile Program Management is not just repurposed project management or a part-time job for a Scrum Master.

Agile Program Managers coordinate and track expectations across all projects under the umbrella of the program, whether the projects are using Agile or not. Coordination includes activities like identifying and tracking dependencies, tracking risks and issues and communication. Coordination of the larger program generally requires developing a portfolio of moving parts at the epic or function level across all of the related projects (epics are large user stories that represent large concepts that will be broken down later). Agile Program Managers layer each project’s release plans on top of the program portfolio to provide a platform for coordinated release planning. Techniques like Kanban can be used for tracking and visualizing the portfolio.  Visualization show how the epics or functions are progressing as they are developed and staged for delivery to the program’s customers.

Facilitating communication is one the roles of an Agile Program Managers. The Scrum of Scrums is the primary vehicle for ensuring communication.  The Scum of Scrums is a meeting of the all of the directly responsible individuals (DRIs) from each team in the program. The DRI has the responsibility to act as the conduit of information for his or her team to the Agile Program Manager and other DRIs. The DRI raises issues, risks, concerns and needs. In short, the DRI communicates to the team and the Scrum of Scrums. The Scrum of Scrums is best as a daily meeting of the DRIs chaired by the Agile Program Manager, however the frequency can be tailored to meet the program’s needs.  A pattern I have seen used to minimize overhead is varying the frequency of the Scrum of Scrums based on project risk.

Another set of activities that generally fall to the Agile Program Manager is the development and communication of program status information. Chairing high-level status meetings, such as those with sponsor or other guidance groups, is a natural extension of the role. However this requires the Agile Program Manager to act as a conduit of information by transferring knowledge from the Scrum of Scrums to the sponsors and back again. Any problem with information flow can potentially cause bad decisions and will affect the program.

It is important to recognize that Agile Program Management is more than a specialization within the realm of project management or a side job a Scrum Master can do in his or her spare time.  Agile Program Managers need to be well versed in both Agile techniques and in standard program management techniques because the Agile Program Manager is a hybrid from both camps. Agile Program Managers build the big picture view that a portfolio view of all of the related projects will deliver. They also must facilitate communication via the Scrum of Scrums and standard program status vehicles.  The Agile Program Manager many times must straddle the line between both the Agile and waterfall worlds.

Team members working together.

Team members working together (or not).

In Agile projects, the roles of the classic project manager in Scrum are spread across the three basic roles (Product Owner, Scrum Master and Development Team). A fourth role, the Agile Program Manager (known as a Release Train Engineer in SAFe), is needed when multiple projects are joined together to become a coordinated program.  The primary measures of success in Agile projects are delivered business value and customer satisfaction.  These attributes subsume the classic topics of on-time, on-budget and on-scope. (Note: Delivered value and customer satisfaction should be the primary measure of success in ALL types of projects, however these are not generally how project teams are held accountable.)

As teams learn to embrace and use Agile principles, they need to learn how to make decisions as a team. The decisions that teams need to learn how to make for themselves always have consequences, and sometimes those consequences will be negative. To accomplish this learning process in the least risky manner, the team should use techniques like delaying decisions as late as is practical and delivering completed work within short time boxes. These techniques reduce risk by increasing the time the team has to gather knowledge and by getting the team feedback quickly. The organization also must learn how to encourage the team to make good decisions while giving them the latitude to mess up. This requires the organization to accept some level of explicit initial ambiguity that is caused by delaying decisions, rather than implicit ambiguity of making decisions early that later turn out to be wrong. The organization must also learn to evaluate teams and individuals less on the outcome of a single decision and more on the outcome of the value the team delivered.

Teams also have to unlearn habits, for example, relying on others to plan for them. In order to do that, all leaders and teams must have an understanding of the true goals of the project (listen to my interview with David Marquet) and how the project fits into the strategic goals of the organization.

Teams make designs daily that affect the direction of the sprint and project. The faster these decisions are made the higher the team’s velocity or productivity. Having a solid understanding of the real goals of the project helps the team make decisions more effectively. Organizations need to learn how share knowledge that today is generally compartmentalized between developers, testers or analysts.

The process of learning and unlearning occurs on a continuum as teams push toward a type of collective self-actualization. As any team moves toward its full potential, the organization’s need to control planning and decisions falls away. If the organization doesn’t back away from the tenants of command and control and move towards the Agile principles, the ability of any team to continue to grow will be constrained.  The tipping point generally occurs when an organization realizes that self-managing and self-organizing teams deliver superior value and higher customer satisfaction and that in the long run is what keeps CIOs employed.

Listen Now

Subscribe on iTunes

The Software Process and Measurement Cast features our interview with Woody Zuill.  We talked about the concept and controversy swirling around #NoEstimates. Even if the concept is a bridge too far for you, the conversation is important because we talked about why thinking and questioning is a critical survival technique. As Woody points out, it is important to peer past the “thou musts” to gain greater understanding of what you should be doing!

Woody Zuill has been programming computers for 30+ years. Over the last 15+ years he has worked as an Agile Coach, Trainer, and Extreme Programmer and now works with Industrial Logic as a Trainer/Coach/Consultant for Agile and Lean software development. He believes code must be simple, clean, and maintainable to realize the Agile promise of Responding to Change.

Contact Information
Mob Programming:

Call to action!

I have a challenge for the Software Process and Measurement Cast listeners for the next few weeks.  I would like you find one person that you think would like the podcast and introduce them to the cast.  This might mean sending them the URL or teaching how to download podcasts.  If you like the podcast and think it is valuable they will be thankful to you for introducing them to the Software Process and Measurement Cast! Thank you in advance!

Re-Read Saturday News

We have just begun the Re-Read Saturday of The Mythical Man-Month. We are off to a rousing start beginning with the Tar Pit.   Get a copy now and start reading!

The Re-Read Saturday and other great articles can be found on the Software Process and Measurement Blog.


Remember: We just completed the Re-Read Saturday of Eliyahu M. Goldratt and Jeff Cox’s The Goal: A Process of Ongoing Improvement, which began on February 21nd. What did you think?  Did the re-read cause you to read The Goal back up for a refresher? Visit the Software Process and Measurement Blog and review the whole re-read.

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

Dead Tree Version or Kindle Version 

Upcoming Events

Software Quality and Test Management 

September 13 – 18, 2015

San Diego, California

I will be speaking on the impact of cognitive biases on teams!  Let me know if you are attending!


More on other great conferences soon!


Next SPaMCast

The next Software Process and Measurement Cast is a magazine installment.  We will feature our essay on Agile Testing. The flow of testing is different in an Agile project.  In many cases, organizations have either not recognized the change in flow, or have created Agile/waterfall hybrids with test groups holding onto waterfall patterns.  While some of the hybrids are driven by mandated contractual relationships, the majority are driven by lack of understanding or fear of how testing should flow in Agile projects.

We will also have new installments from Jeremy Berriault’s QA Corner.  Jeremy, is a leader in the world of quality assurance and testing and was originally interviewed on the Software Process and Measurement Cast 274. The third column features Steve Tendon discussing more of his great new bookHyper-Productive Knowledge Work Performance.


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 Mythical Man-Month: Essays on Software Engineering was originally published in 1975. That was the year I took my first course in programming – FORTRAN, at Memphis State University. Mythical Man-Month has been a must read for every professional involved in delivering value since it was published. The core themes in the book, which include Brook’s Law (adding people to a late project just makes it later – more in a future installment), are just as important today as they were when they were published because they still true for all types of software development and maintenance.   The Mythical Man-Month, I think on reflection you will agree, is still important because we are still trying to come to grips with most if not all of the concepts that Brooks exposed.

Here is the game plan for the Re-Read. We will be reading from Anniversary Edition of the Mythical Man-Month (Addison Wesley 1995). My copy is the 14th printing from 2014. Part of this re-read will actually be a first read for me. I believe I originally read Man-Month in the early 1980’s, and this edition has a new preface and four new chapters. My intent during the re-read is to cover two essays/chapters per week so the re-read takes ten weeks “ish.”  Today will be the exception to the rule. We will tackle the first essay, The Tar Pit (I already used the ideas in the essay to make a point in the essay on Scrum of Scrum membership).

The original preface provides background for Brooks’ perspective. Brooks came to his conclusions based on a history as a hardware architect then as the manager of the OS/360 project (IBM’s highly successful mainframe operating system). In the preface Brooks telegraphs one of his central theorems – large projects are different than small projects. It took a few years and the Agile Manifesto (2001) to recognize this fact and begin to act on it.

The anniversary edition includes a new preface in addition to the original. There were two notes in the new preface that caused me pause. The first was the observation by Brooks was that few of the central thoughts in the book had been critiqued, proven, and disproven by research and experience. I would like your feedback as we review the essays. I will explicitly point those points out during the re-read and if miss any skip ahead to Chapter 18 to keep me honest. The second point, based on my interest in the publishing industry,  from the new preface was that Brooks was able to publicly thank Addison Wesley staff that he found instrumental when preparing the first edition. The publishing world has changed. The question I pose to the Software Process and Measurement Cast blog readers is has our profession changed as much?

Chapter 1: The Tar Pit

In the Tar Pit Brooks sets the context for the system programming as a craft that is more than just the lone coder sitting in his or her office creating a stand alone app but rather a member of a team building large scale systems. The Tar Pit describes why the complexity and level of effort is different and then exposes the joy and woes of the profession.

The first takeaway from the Tar Pit is that as the product of a piece of work progresses from the delivery of a single program to programming product or system then to a programming systems product, the complexity of managing and understanding the work increases. As size and complexity increase so do tasks and activities to ensure the product works together. Brook suggests that the difference between level of effort between the creation of stand-alone program and a systems product is 9 times! The complexity of coordinating all of these additional tasks and activities while solving complex business problems impacts our ability to deliver on-time, on-budget and on-scope. At times, it also impact our ability to deliver WOW.

The second takeaway are the joys of programming.  Joys motivate programmers to put forth the effort needed to deliver value while trying to navigate the tar pit.  Brooks points out that the rewards of programming are at least four fold:

  1. The joy of making things.
  2. The joy of making things that are useful to others.
  3. The joy of problem solving.
  4. The joy of learning.

These joys are offset by several woes.  These woes are the part of the tar pit that make programming hard.

  1. Expectation of perfection. Unless the code is correct and solves the requirements, it is wrong. There is little to no gray area.
  2. Dependence on others. Others set your objectives, provide resources and often control the source of information. This often leads to the tension caused when individual or teams have the responsibility to deliver without commensurate authority. Agile principles, when applied to teams, are a start to addressing these woes.
  3. Finding the bugs in the big picture.  Designing the big picture is significantly more fun than the tedious effort required to find bugs.
  4. Dead on arrival projects.  Long running projects are occasionally dead on arrival or the market has changed and what has been delivered is not what is needed.

In 1975 when this essay was published Agile was not a word one would attach to building applications or systems. However I think we can see the seeds of the Agile revolution in this essay.

Pick a direction?

Pick a direction?

A Scum of Scrums (SoS) is a mechanism that has been adopted to coordinate a group of teams so that they act as a team of teams.  Historically the concept of a SoS was not part of the original Scrum framework and is considered an add-on to the framework.  In other words a Scrum of Scrums is an optional technique that can be added to more canonical Scrum framework if useful however because the technique is optional the amount of guidance is patchy.  For example, when an organization adopts a SoS who should participate is often hotly debated.  The participation debate popped up after we published Scrum of Scrums, The Basics. I had a number of conversations with readers to discuss the topic. Consolidating the discussions suggest the type of membership the person supports depends on what they want to get from using the SoS. All of the readers felt that the SoS should always be focused on coordination however there can be two flavors; one focused on activities and the second on technical questions.

Coordination of Activities:  Those that believe the SoS is primarily a tool for coordinating team activities support the idea that Scrum Masters should be chosen for SoS membership.  The rationale put forward focuses on the idea that the Scrum Master is uniquely positioned to gather and communicate information related to the coordination of teams. Readers in this group view feel that since Scrum Masters interact with all team members as a facilitator rather than a technical leader they are better coordinators. The alternate view held by many Agilistas believe that Scrum Masters acting in this role violate Scrum principles and represent a prima facie reinstitution of the role of the project manager. Further the Agilista view suggests that when technical issues need to be dealt with in SoS meetings populated with Scrum Masters they can’t make decisions rather often need to act as a conduit between technical team members. When SoS become a conduit, a version of the classic telephone game, decision making effectiveness is reduced..

Technical Coordination:  Fred Brooks in his essay Tar Pit (foreshadowing the next installment of Re-Read Saturday) suggests that software development increases in complexity as it progresses past development of an individual program. Integrating work with the work of other requires sharing technical information and making technical decisions that often can impact more than a single person or team. Scrum of scrums that are being used for technical coordination require participants with relevant technical acumen.  Participants with technical acumen generally come from the technical part of the team (developers, architects or testers).

Pushing aside the noise of whether the coordination of activities is less Agile than using the SoS for technical coordination, a more pragmatic approach is to recognize the needs of the team of teams is context driven.  The type of decision the team of team needs to make will change across a sprint or a SAFe Program Increment therefore who should attend a SoS needs to vary. The downside to varying membership is ensuring the right people are in attendance to address the SoS’s current need. One solution I have observed is to develop a cadence for topics.  For example tackle coordination every fourth SoS gathering with other more technical topics being focused on in-between.  Predictability makes it easy to plan who should attend.  Regardless of approach I suggest that any SoS should agree upon a mechanism to decide on the type of to hold. Flexibility to identify the type of SoS will ensure the team does not fall prey to meeting schedule paralysis or the equally evil telephone game.

Scaling - going from one project to two (or more!)

Scaling – going from one project to two (or more!)

The Scrum of Scrums (SoS) is a technique for scaling Scrum and other Agile techniques to larger efforts. On paper, the SoS is a simple extrapolation of the daily Scrum or stand-up meeting that has become a hallmark of the practice of Agile. A typical stand-up meeting occurs on a daily basis so that all of the team members of can coordinate and plan daily activities. Classically the team uses the three question technique to organize the meeting. In a similar manner, a typical Scrum of Scrums acts as a focal point to help synchronize a team of teams or even teams of teams. There are four basics of a SoS that need to be understood before any nuances can be addressed.

  1. Who Attends: There are two basic schools of thought in picking SoS attendees. The first (and most common) school suggests that the Scrum Master attend the SoS. The Scaled Agile Framework Enterprise (SAFe) is an example of a methodology that leverages the Scrum Master during both the planning event and during the program increment. Alternately, the second group takes a more egalitarian approach (possibly more pragmatic) allowing the each team to select an attendee that can most easily convey or understand the current issues the team and the larger group are having at the time. For example, if design decisions are at the front, perhaps team members with the most UX acumen would make sense. In this scenario attendees would vary over time.
  2. Who Facilitates: Small SoS groups, for example a handful of teams that are co-located, may not require facilitation. The SoS can self-organize and execute the meeting with little overhead. However as the number of participants increases (I bound SoS meetings using the same 5 -9 members rule used in Scrum teams) or as the distribution of the members becomes more varied facilitation becomes more important. Facilitators help the team use the SoS practice, ensure logistics are set up and champion the schedule. In larger efforts, a program manager often delivers facilitation, or if practicing SAFe the Release Train Engineer performs the facilitation role.
  3. Frequency: Scrum of Scrums often follows the same pattern as the daily Scrum/stand-up meeting. A second frequency pattern is risk-based; the frequency of the SoS meetings varies depending on need. Early in a project the SoS meets daily as teams are forming, norming and as early decisions are being made. The SoS meeting become twice weekly in the middle of the project and then returns to daily as a release approaches.
  4. Format: Daily stand-up meetings commonly leverage the classic three question approach (What did I do? What am I going to do? and What are my blockers?). The Scrum of Scrums generally follows a VERY similar format with each participant answering the following four questions:
    1. What did my team do since the last meeting?
    2. What will my team do before we meet again?
    3. Is my team experiencing blockers?
    4. Is my team going to put something in another team’s path?

The meeting follows the same round robin approach with each participant interacting with each other. The facilitator (if used) should never be the focal point of the meeting, nor should the SoS devolve into a purely a status meeting.

The daily stand-up and the SoS are very similar meetings. Both meetings are held to share information, coordinate activities and to identify problems. The scope of SoS meeting is broader than a single team with the meeting providing coordination and planning activities within and across teams.

Next: Using the Scrum of Scrums to Scale Planning and Scrum of Scrum Anti-patterns


Get every new post delivered to your Inbox.

Join 4,454 other followers