Notes from the field...
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.
About the Author
Jim York works with real teams doing real work. He coaches, teaches, writes, and speaks on Lean and Agile principles and practices. He has been the keynote and speaker at various Agile conferences and has held an number of leadership roles in the Agile community including the Scrum Alliance and the Agile Alliance. Jim is a Certified Enterprise Coach, Certified Team Coach℠, and a Certified Scrum Trainer®, one of only a handful of people world-wide to hold all top-level guide certifications from the Scrum Alliance. As a licensed facilitator for the Agile Fluency™ Suite, Jim uses the Agile Fluency Model in his coaching with clients. He has coached several organizations through their adoption of Agile including NPR, McKinsey & Company IT, GE Healthcare, and Capital One.
- Aug 28, 2019 Where do you sit as your Agile team's designated business expert? Aug 28, 2019
- Jun 28, 2019 Doing what matters most Jun 28, 2019
- May 2, 2019 Agile over the next 20 years May 2, 2019
- April 2019
- Feb 26, 2019 I'm a new Scrum Master. Should I be updating the team's burn charts? Feb 26, 2019
- Dec 3, 2018 What is your agile aspiration? Dec 3, 2018
- Nov 13, 2018 Context Considered: Focusing Agile Investments for a Better Return Nov 13, 2018
- Nov 2, 2018 Decouple Release Timing from Sprint Boundaries Nov 2, 2018
- Oct 1, 2018 Off the Bookshelf Oct 1, 2018
- Sep 2, 2018 4 Things - Transforming Harley Davidson Sep 2, 2018
- Jul 31, 2018 Continuous improvement is not an option Jul 31, 2018
- May 13, 2018 Onward and upward! May 13, 2018
- February 2018
- Jan 5, 2018 Sometimes we can’t see the tree for the forest Jan 5, 2018
- Nov 1, 2017 Which days of the week to start and end your Sprint Nov 1, 2017
- Sep 22, 2017 Uncertainty Sep 22, 2017
- August 2017
- Jun 26, 2017 Magic Words, Jargon, and Gibberish Jun 26, 2017
- Mar 4, 2017 Lift Off: Start and Sustain Successful Agile Teams Mar 4, 2017
- Jan 24, 2017 The Agile Habit — How 2 minutes a day can make a big difference Jan 24, 2017
- Oct 3, 2016 The Mailbox Oct 3, 2016
- Aug 23, 2016 Simple Rules! Aug 23, 2016
- Jul 21, 2016 Scrum Values Take 1st Place Jul 21, 2016
- Jun 6, 2016 Agile n+1 Jun 6, 2016
- Apr 29, 2016 Scaling — What's it all about? Apr 29, 2016
- Mar 23, 2016 The Elusive Product Owner Mar 23, 2016
- Feb 17, 2016 The need for simplicity Feb 17, 2016
- Jan 7, 2016 An argument for a look ahead Jan 7, 2016
- Oct 22, 2015 Common Misperceptions about Agile Oct 22, 2015
- Oct 12, 2015 To be or not to be?... Product Owner versus Scrum Master Oct 12, 2015
- Jun 2, 2015 The Role of the Project Manager in Scrum Jun 2, 2015
- April 2015
- Mar 23, 2015 Unintended Consequences - The Agile Death March Mar 23, 2015
- January 2015
- Oct 4, 2014 4 things - before starting a large Agile project Oct 4, 2014
- Aug 27, 2014 4 things - Product Owner Aug 27, 2014
- May 2, 2014 Coaching Beyond The Team May 2, 2014
- Apr 18, 2014 4 things - self-organizing teams Apr 18, 2014
- Mar 11, 2014 4 things Mar 11, 2014
- Nov 14, 2013 What's in Your Agile Toolkit? Nov 14, 2013
- Jul 1, 2013 Scrum Beyond Software Jul 1, 2013
- Apr 4, 2013 Less is More Apr 4, 2013
- Mar 22, 2013 5 Hints to Being a Better ScrumMaster Mar 22, 2013
- Feb 28, 2013 The Virtue of Small Feb 28, 2013
- Feb 12, 2013 Avoiding Costly Mistakes: Agile's Impact on Capitalization Feb 12, 2013
- Jan 12, 2013 Where do you want to get to? Jan 12, 2013
- Dec 21, 2012 Why Exercise? Dec 21, 2012
- Nov 12, 2012 "Draw Left": Why Communication Matters Nov 12, 2012
- Oct 10, 2012 "I got quarters in my loafers..." Oct 10, 2012
- Sep 4, 2012 Succeeding with Scrum Sep 4, 2012
- Aug 24, 2012 The Baby and the Bath Water Aug 24, 2012
- Jul 17, 2012 Agile Waves Jul 17, 2012
- Apr 25, 2012 Advice for Starting Your Agile Project Apr 25, 2012
- Mar 23, 2012 The Widening Gap Mar 23, 2012
- Mar 22, 2012 Minding the Gap: Making Sense of the Release Burndown Chart Mar 22, 2012
- Jan 24, 2012 The ABCs of Agile Leadership Jan 24, 2012
- Nov 30, 2011 Jim's 80/5 Guideline for Engaging the Product Owner Nov 30, 2011
- May 18, 2011 Are We There Yet?: The Shu Ha Ri of Becoming Agile May 18, 2011
- Mar 28, 2011 "Out of Sight Out of Mind" = "Invisible Idiot" Mar 28, 2011
- Dec 9, 2010 The Architect Dec 9, 2010
- Mar 28, 2009 Get Rid of the Product Owner? Mar 28, 2009
- Jan 29, 2009 Agile Portfolio Management Jan 29, 2009
- May 7, 2008 The Way We See the Problem is the Problem May 7, 2008
- April 2008
- Jul 18, 2007 Going Nowhere Fast: Scrum without a Product Owner Jul 18, 2007
- Jun 19, 2007 What's up with the fox and the hedgehog? Jun 19, 2007