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.

4 things - self-organizing teams

Organizations steeped in a command and control hierarchical culture sometimes struggle with the concept of a self-organizing team. Releasing "control" to the team is a scary leap of faith and not a leap to be undertaken without proper preparation. Before setting a team loose to find it's own way, here are 4 critical things to put in place to increase the chances of having a successful self-organizing team.

  1. Shared Goal - Establish a shared understanding of the goal.  A shared goal focuses the the team members' energies in the same direction. This laser-like focus leads to quick, targeted results. The shared goal is an essential container for a self-organizing team's creativity, setting both boundaries and direction. Absent an effective container, prepare for chaos.
  2. Dedication - Ensure that each team member is fully available to the team. Part-time is only acceptable if it does not create impediments to the teams' progress (in practice, it is rare that part-time availability does not impede flow).  Dedicate space, equipment, and tools so these resources are always available without delay when needed. Waiting kills momentum and focus.
  3. The Right Stuff - Staff the team with a mix of people that in combination have the appropriate level of knowledge, skills, expertise, leadership, and accountability to get the job done. Attitude and aptitude play a big role as well. Also, provide the things the team needs to do the job including workspace, tools, and equipment. Don't starve the team!
  4. A Sense of Urgency - Give a deadline, leaning towards a shorter timeframe. Agile frameworks impose short iterations during which real, meaningful, and measurable progress is made towards the goal. Deadlines encourage action. As Samuel Johnson said, "Depend upon it, sir, when a man knows he is to be hanged in a fortnight, it concentrates the mind wonderfully."

And finally, listen and respond to the team's needs. A team starting out is never perfectly staffed and outfitted despite best efforts.  If a team discovers a way to improve and needs help to implement the improvement, give them the help they need. With the proper ingredients for success, self-organizing teams thrive and become a powerful, nimble, and effective engine for delivery.

"Draw Left": Why Communication Matters

"ROCK!!!" Despite my warning, the ominous scraping sound moments later told me we were leaving a bit of our canoe behind us on this trip down the Shenandoah River. This little encounter is an example of what my son jokingly calls "painting the rocks" based on the red vinyl marks we sometimes leave as reminders of our passage.

Normally, when canoeing, we try to avoid collisions, and at first I was puzzled and a bit upset that my son had not reacted in time to maneuver the bow of the canoe out of the way. He's a skilled paddler and a simple stroke of his paddle would have been all it took to slip by unscathed. Why hadn't he done what I expected?

Well, in the somewhat heated discussion that ensued, I discovered that I hadn't exactly been clear as to the location of said rock. Besides, I had the advantage of polarized glasses and despite being in the stern, generally was able to see submerged obstacles well before my son. Lacking this critical information, he simply pulled the business end of his paddle out of the water and let me steer assuming I had it all under control. Had I wanted him to do something, clearly I would have said so.

On reflection, admittedly much later and after much fuming, I realized that we could have avoided the rock if I had simply shouted "Draw left, now!" Never mind trying to point out the rock. Avoiding the rock was the goal. Getting the front of the canoe to shift to the left was what was needed now.

Our collision resulted from a failure to communicate. We had mastered the right paddling techniques. But, we hadn't mastered the practice of communicating in a language that would enable us to operate as a team. In the end, it shouldn't have mattered whether or not my son could see the rock. It only mattered that he know what was needed.

At the shout, "Draw left, now!", my son would have simply put into action what years of practice have make into muscle memory. He would have reached his paddle far out over the water to his left, slipped the blade into the water, and, with a quick stroke, pulled the flat side of the blade toward the side of the canoe. The bow of the canoe would have shifted to the left and aided by a stern draw or even a simple angling of my paddle on my part, the canoe would have slipped by leaving that rock unpainted.

In a team environment where a rapid response may be necessary, whether canoeing downriver with a partner or as a team member on an Agile project, it helps to have a common language or lexicon to foster quick communication. The right words spoken at the right time tend to lead to the correct action. The use of words outside the lexicon may lead to undesirable results.

It takes time and practice for a team to create a common language. Once developed, instructions like "Draw left" result in quick and efficient responses. Giving an instruction like "Rock!", which is not part of the language, is often inefficient and ineffective. Developing proficiency or fluency in the team's language is essential to the smooth flow of the team's work.

What is your team's language? How proficient are your team members in their way of communicating?  Consider both business language and technical language. What are the words that are unique to, or have a special meaning, in your environment? For example, the word "forging" means different things to a banker than it does to a blacksmith. The phrase "breaking the build" has a meaning unique to the practice of continuous integration. Knowing what this phrase means is essential to the team to know what action is required next. Investing a bit in creating and practice in learning a common team language will pay off well in improving your team's communications proficiency.

Agile Waves

If you’ve ever been to the beach and taken time out to truly watch the ocean, you have witnessed, in addition to the relentless ebb and flow of the tides, the constant, continuous train of waves crashing on the shore. The shore upon which the waves crash is altered by each wave, but remains fundamentally the same. A careful observer may notice a similar pattern in the steady stream of management theories and techniques expounding on how things could work better crashing onto the shores of our organizations and institutions, threatening the status quo. Like waves, the ideas come and go, but the shore is resilient.

The Agile Wave

A few years ago, a huge wave hit the shores of our organizations and, for a while, this wave seemed like it might have a lasting impact. This wave was the first “Agile” wave. It emerged in the early 1990s with Scrum and was quickly joined by other Agile frameworks such as Extreme Programming (XP). The first Agile wave was born of the deep energies of Lean Manufacturing, iterative and incremental development, empirical thinking, and many other time-tested principles and practices.

On the shore, this wave re-energized many IT departments, and organizations started realizing shorter release cycles and faster throughput of features and applications. For a while, things started to look better. However, as the wave receded, organizational leaders began looking around and discovered that in some cases they had simply become better and faster at delivering things that customers simply didn’t want or need. The wave had left many organizations with huge amounts of low value or worthless product. This result was not what they had expected or what agile had promised. They had little time to ponder this result before the second Agile wave loomed over their heads and came crashing down.

The Product Owner Wave

The second Agile wave started building in the early 2000s and took a while to gather its energies. While this second wave was making its way to the shore, many organizations were struggling with the implications of Agile and most had only scratched at the surface of the possibilities by restricting its adoption to the “IT shop”. Most paid lip service to the idea of business-driven development, choosing instead to retain decision making responsibility within IT. Sure, the teams had a customer proxy or Product Owner, but the reality in many teams was that this individual either wasn’t directly from the business or didn’t understand or play the role effectively.

The first Agile wave brought with it the possibility of organizational change, but many organizations caught up in this first wave were resilient to the change and that wave passed over with little lasting effect.

The second wave brought awareness of the importance of business direction and business decision making (i.e., product ownership in Scrum terms). By 2006, the Scrum Alliance responded to this need by adding a Scrum Product Owner certification to its already popular Certified ScrumMaster offering. Organizations that rode the energy of this second wave to shift business decision making to the business are beginning to realize some of the true potential of Agile.

The Third Wave

Already, on the horizon, keen observers are growing aware of a third Agile wave. While both the first and second waves had potential to make a lasting difference in the way organizations do business, very few organizations were able to tap that energy effectively. Time-to-market and business-driven decisions are good incremental improvements. However, the third Agile wave has the potential to be a real game changer.

The third wave is energized by the need for holistic organizational alignment, intense laser-like focus, and the agility to be a market leader. In addition to being able to respond to change, organizations riding the third wave will be generating change.

The first 2 waves have set the stage and have presented opportunity for learning. As this third wave approaches, it’s time for organizational leaders to be asking, “Will I be surfing this wave, watching it go by, or being pummeled by it as it crashes into the shore?”

The resilience of the organization’s shore serves well when it helps the organization stay true to its vision and purpose. However, that same resilience can work against the organization when it prevents it from benefitting from new opportunities. The waves are the opportunities. One thing is certain, the waves will keep coming. They always have and they always will. The question is not whether another wave will come, but rather, what will you do when it does? Are you ready for the wave? If not, what are you doing to get ready?

"Out of Sight Out of Mind" = "Invisible Idiot"

Translation is a tricky business.  What seems clear in one context is murky in another.  The translation urban legend*, abbreviated in the title of this blog entry, humorously captures the difficulty of communicating when those who wish to communicate speak different languages. When discussing Agile with executives, I often find that their perception of Agile differs depending on their own and their organizations’s underlying cultural values.  For example, I often hear that the adoption of Agile principles and practices is incompatible with a command and control culture.  I do not believe this statement to be true.

According to organizational psychologist, Bill Schneider, Control cultures value certainty in the attainment of organizational goals.  The organization is seen as a system built expressly to achieve those goals. While predictability, accuracy, dependability, safety are characteristics of certainty, these values are not fundamentally inconsistent with Agile.

I believe success with Agile in a command and control environment requires an accurate translation of Agile’s benefits in terms that resonate with the values and goals of the organization and its leaders.  There must be an alignment at the cultural level before execution can be successful.  To foster alignment, you must learn how to talk like a native.

I will be running a workshop helping others explore this topic (“Finding a Fit for Agile in Your Corporate Culture”) at the Quest 2011 Conference in Boston on 7 April.

* "The whisky was invisible", or Persistent myths of MT

John Hutchins, MT News International 11 (June 1995), pp.17-18]