Coaching Beyond The Team

This post is a re-print of my article originally appearing on the Scrum Alliance website on 3 March 2011.

As an external coach, I am often brought in to teach a new team the Scrum framework and to personally coach the ScrumMaster, Product Owner and Scrum Development Team Members in their new roles. However, the coaching does not stop with the Scrum Team. Scrum does not limit its organizational impact to just the Scrum Team. Therefore, coaching must also extend beyond the team. To explore this extension, let’s look at an example of a traditional role often shaken up by the introduction of Scrum, the Resource Manager, and how coaching might impact this individual’s development path.

In organizations that use a matrix or pool for staffing, the Resource Manager allocates people to projects, while balancing capacity, availability, and demand. Resource Managers are often faced with more demand than supply. This imbalance results in the Resource Manager assigning individuals to 2 or more initiatives simultaneously. The pressure to spread people across multiple projects is increased further in organizations that reward high “utilization.” Since the individual projects start and stop on various dates, the Resource Manager has a busy job planning who is to be working on what projects at what time. The work is complex and the job thankless, but that is why the Resource Manager is paid the big bucks.

Enter Scrum. Scrum initiatives are often staffed with dedicated teams. In other words, the individuals on the core team are fully allocated to the team. If the Scrum adoption starts with a single pilot project, this dedicated team usually has a limited impact on the staffing pool and the project portfolio. Some other projects may be delayed and some people outside the Scrum pilot may take on more work — inconvenient, yes, but workable.

The problem for the Resource Manager arises when the pilot is successful and more initiatives are launched using Scrum. Each of these new efforts demands its own dedicated team. As the number of dedicated teams grows, the complexity of the Resource Manager’s high paying job dwindles to the point of becoming trivial. The role of Resource Manager as master of a staffing shell game is no more. The Resource Manager’s problem now is how to remain relevant to the organization.

For the Resource Manager, this shift can be scary. What does a Resource Manager do when the job becomes trivial? How long will the organization continue to pay big bucks for this job? At this point, the Resource Manager may be thinking only of how to preserve his or her job. The job of the coach is to help this individual work through this problem. For one Resource Manager, who we will call Paul, here is how the coaching process played out.

In a conversation with Paul, he revealed that he actually hated his job. Paul had been promoted into a management position only because he had hit the top of his pay scale and the organization was afraid that they might lose him to the competition. Paul’s real passion was in technology. He found no satisfaction in moving assignments around in a spreadsheet. Paul’s only contact with the technology now was from a distance. Dealing with the politics of too much demand for too little supply took most of his attention. The only part of the job Paul liked was getting to know the people in his staffing pool and helping them develop professionally.

With some encouragement, Paul described his ideal job. What he really wanted to do was to mentor technical employees and create a learning environment where employees could develop and share technical skills and knowledge. Paul wanted to combine his technical knowledge and his people skills to improve the technical competence of the entire organization by encouraging learning and sharing across teams.

Following our conversation, Paul proposed a new position to his manager. Noting that the creation of dedicated cross-functional teams had broken down the traditional organizational silos based on job function, he argued there was now a need for a position to support technical cohesion and collaboration across the organization. This new position would focus on individual and team professional development and organizational learning. The new role would be a sort of internal consultant who would ensure cross-pollination of technical ideas and competencies across teams. Ultimately, Paul got his new position and helped establish a new non-management promotion path for technical workers in his organization.

Paul was successful in figuring out how to navigate the changing organizational landscape. Coaching didn’t solve Paul’s problem. Rather, coaching helped Paul figure it out for himself.

It is easy to underestimate the seismic shift people throughout an organization experience as the development processes and underlying organizational structures react to changes made in response to Scrum’s inspect and adapt cycle. Paul, our Resource Manager, is but one example. People in leadership, portfolio management, operations, finance, customer support, audit, marketing, sales, and so forth all feel the impact. Coaching doesn’t stop at the Scrum Team boundary — organizational change requires coaching beyond the team.

Less is More

With sequestration and furloughs a reality and demand for services still high, organizations are dealing with the question of how to do more with less. I submit that how to do more with less may not be the right question. Instead of doing more with less, perhaps the right question is how to do less. In a world of tightening budgets and forced reduction in staff, we don't have the option to do more. Pushing more demand onto a smaller capacity only slows things down. Take, for example, road maintenance on a multi-lane highway that requires shutting down one or more lanes of traffic. The remaining lanes have to take on the amount of traffic that the previous larger number of lanes handled. Inevitably, traffic backs up. It takes longer for each vehicle to reach its destination. The backup happens even though no additional vehicles have been added to the road.

Now, add more vehicles. The backup gets even worse. Little's Law predicts this outcome. The only ways to eliminate the backup are to increase capacity, reduce the amount of time each vehicle spends on the constricted section of the road, or limit the arrival rate of vehicles.

Increasing capacity often requires an increased investment, for example, adding temporary lanes to replace the lanes taken out of service. In this road construction example, reducing the amount of time a vehicle spends on the constricted section of the road has limits constrained by physics and safety. Limiting the arrival rate could be manipulated by offering options, such as a detour around the affected section, or an informational campaign that encourages drivers to avoid the area during peak usage times.

Now, think of your projects as if they were vehicles approaching this construction zone. Though, instead of a construction zone, the projects are entering a delivery process that is constrained by budget cutbacks. Just like there are fewer lanes to support the vehicles in the construction zone, there are fewer people, teams, and infrastructure to support the arriving projects in your delivery system. The reduced capacity also impacts the projects that are already in process. If you don't want to increase cycle time, that is, the time it takes a project to be completed, you must do something. According to Little's Law, there are only 3 options: 1) Increase capacity, 2) Improve flow, or 3)Limit the arrival rate.

Given sequestration, increasing capacity may not be an option.¹ Improving flow can be achieved by adopting Agile practices that speed up the delivery process. This solution is analogous to reducing the amount of time a vehicle spends in the construction zone. If the cycle time increases to an unsatisfactory level despite flow improvements, the only remaining option is to limit the arrival rate of projects.

Which projects to do and which to delay or put off altogether is a portfolio management problem. Little's Law and Pareto are useful techniques for analyzing this problem, but the ultimate goal is to pick which projects generate the greatest return and focus on those.  Directing the limited capacity of the organization at a smaller set of high value work is not "doing more with less," but rather doing the right work, at the right time, within capacity constraints, which is, by the way, what we probably should have been doing all along. Sometimes it takes a crisis, like sequestration, to force the issue into action. So, this is an opportunity to do the right thing.  Don't waste it.

¹Depending the organization's business model it may be opportunistic to increase capacity at a time when others must cut back, but that is a topic for another day.

The Virtue of Small



"A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away." - Antoine de Saint-Exupéry One of the tricks that makes Agile work is keeping things small.  In practice, small may be the "secret sauce" in Agile.

Small releases, small iterations, small teams, small queues, small user stories (the "S" in the "INVEST" acronym) -- Small is good.  Small is beautiful.


One of the tricks to keeping things small is Pareto. Also known as the 80/20 rule, the Pareto Principle basically states that 80% of the effect comes from 20% of the cause.

To see how the Pareto Principle applies in Agile, consider a feature. Most of the value of a feature is in the happy path, the default scenario. The happy path is the scenario where everything works as intended with no missteps. The edge cases or exception paths carry different values, but none are likely to trump the happy path -- not by a long shot. Quality specifications inform the value of  edge cases, and quality specifications may dictate that some edge cases are essential for a production release. Regardless, the happy path is where most of the value lies.  Very likely the 80% value or "effect" is in the happy path.

Product Owners can break a complex user story into multiple smaller stories by separating the happy path and the exception cases into separate user stories with each story representing a unique and distinct path through the feature. The order of these stories in the product backlog would be the happy path first, followed by the next highest value exception path scenario, and so on.

Since product backlogs almost always contain more than one feature, the stories associated with one feature would almost always be interleaved with stories from other features. The Pareto Principle tells us that the value in the subsequent stories after the happy path story starts to fall off at a very rapid rate. The diminishing returns of these exception path stories means that, at some point, the value of the happy path of a "lower" value feature might exceed the value of the next "not yet started" exception path story of a "higher" value feature.

In this way, the Product Owner plays a value optimization game, sequencing the items in the product backlog by comparing exception paths of one story to happy paths of others. As stories are completed or "done," the Product Owner determines readiness for production by considering the appropriate level of quality required for the features to be deployed.

The Macro is in the Micro

The applicability of the Pareto Principle doesn't stop at a user stories and the product backlog. It applies equally well at the product portfolio level.  The Pareto Principle shows us how small is beautiful. In truth, less is more.

Agile Portfolio Management

Recently a colleague emailed me seeking advice for setting up a program management office (PMO) using lean and agile principles.  After replying, I reflected on the fact that his query is pretty common in my practice.  And so, I’ve decided to share my brief reply here. His first email asked for guidance in setting up the PMO.  I replied that, for PMOs, my stance is to use lean and agile thinking in their setup and operation just as you would in project execution.  Projects must compete with one another to deliver in line with corporate strategy and realized business value.

He next emailed asking how he was to sort out the priorities of the hundred or so ideas vying for attention in the portfolio.  My simple reply to this query was that each idea needs a champion who is willing to put in the time and energy to provide him, the portfolio manager, the information needed to determine the value of their idea so that a rational prioritization can be done.  No champion -- no actionable idea.  This criteria tends to reduce the list of actionable ideas considerably.  Next, he needs to understand his organizational constraint on the number of teams his organization can field and sustain effectively to deliver rapidly on the ideas.  This constraint will tell him how many ideas can be executed simultaneously with maximum throughput.

Simple ideas really, but I rarely see these basic concepts well executed in large companies.

My parting bit of advice:  Beware taking on someone else's championing role.  It will come back to bite you.