Onward and upward!

BASD.jpg

I always enjoy the comraderie of my fellow coaches at the Coaches Clinics and getting to meet the people who come to chat for a 15 minute coaching session. This year's Coaches Clinic at Big Apple Scrum Day in New York City continued the tradition. While every clinic is different based on who shows up, there are two clear constants. One is the coaches' earnest desire to help people with the next leg of their Scrum journey. The second is the energy of the attendees in seeking a way forward.

Everyone's Scrum journey is unique and that is what makes coaching such an interesting vocation. Certainly there are patterns — well worn paths that many have trodden in the search for improvement — but these paths crisscross, double back, circle around, and blend in innumerable ways.

For me, this year's coaching topics ranged from estimation (what a can of worms that one can be!), how to get started with agile, how to improve team focus and accountability when the team is distributed, and variations on how to be a better coach or trainer for the team and the organization. 

I often start the coaching conversation with the question, "What is the difference you want to make?" or a similar variation on the question, "Why?" The intent of this question is to turn the conversation inward to what the attendee really wants to accomplish. This focus is key to the journey. 

On the day following the conference, I went to the John Pierpont Morgan Library and Museum and found the following quote:

No problem can be solved until it is reduced to some simple form. The changing of a vague difficulty into a specific, concrete form is a very essential element in thinking.
— John Pierpont Morgan

The discovery of this quote is another reason I love to come to Big Apple Scrum Day in New York City. It's the people, the history, the learning, the ever changing, but still same enduring quality of what makes us resilient, adaptable, and successful. As J.P. Morgan's bookplates adorning his many thousands of books say, "Onward and upward".

Value Hunting with the Product Owner

Value Hunting with the Product Owner

I coach my Product Owners to ruthlessly refine their Product Backlog to prevent onset of an Agile death march. A lack of proper attention to Product Backlog Refinement can lead to product decay, premature end of product life, and demotivation of the Development Team. 

In light of these risks, it's important to get Product Backlog Refinement right...

Read More

4 things - Agile coach

When I tell someone I am an agile coach, I sometimes receive a puzzled response.

"Oh? What sport?"... or 

"Is that the thing where you train a dog to run an obstacle course?"

When I explain that I coach people and teams that create innovative products and services, they get even more confused. 

"Why do they need a coach? Aren't they professionals? Don't they know their stuff? Shouldn't we reasonably expect that they can get the job done?"...

Read More

4 things - ScrumMaster

In 1993, the first Scrum team introduced a new role — the ScrumMaster. This person was explicitly “not a manager — more of a servant-leader, something between a team captain and a coach.”¹ Instead of managing the team or the team’s process, the ScrumMaster:

  1. Facilitates the team’s meetings, fostering collaboration and enabling focus.
  2. Ensures that the process and its effects are visible to everyone.
  3. Helps the team figure out what is in their way of being an better, more effective team at delivering what their customers actually need.
  4. Champions improvements that the team is unable to make for themselves, influencing those with the power to enact change.

Fundamentally, the ScrumMaster role is about developing people... and the teams they form, helping both individuals and teams realize their potential. A good ScrumMaster accelerates the rate of improvement while enriching the experience for all involved.

¹Jeff Sutherland, Scrum, (New York, NY: Crown Business, 2014) p. 62

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.