Table of Contents
How Do We Initially Setup an Executive Scrum Team?
I often get a request to facilitation of a planning session to get an Agile Transformation started, supported and eventually sustained in their organization. The question is how to organize these people and start the process.
John Kotter in "Leading Change" talks about 8 enablers needed in order to have a successful transformation (be it Agile, or other significant change). The enablers are:
|Number||Kotter Enabler||Sample Actions|
|1||Establishing a Sense of Urgency||Message from leadership.|
|2||Creating the Guiding Coalition||Establish “Agile Center of Excellence” and the role of “Agile Coach”.|
|3||Developing a Vision and Strategy||Clear understanding of “why”.|
|4||Communicating the Change Vision||Constant communication. Include “dog fooding”.|
|5||Empowering Employees for Broad-Based Action||Message, then celebrate when it happens.|
|6||Generating Short-Term Wins||Iterations, Pilots, Successful plans, Stories about success.|
|7||Consolidating Gains and Producing More Change||Make it easy to do the right thing.|
|8||Anchoring New Approaches in the Culture||Reinforce. Communities of practice. Supporting infrastructure. Next improvement.|
Before you start going down an Agile implementation path it is worth the effort to capture and document why you are doing this change, what problems you expect to see, and how you will know you are successful. These need to expressed in terms of business drivers, not in terms of Agile, so everyone is aligned on the objective. For example, you might think that you want more transparency as a result of you Agile implementation, and that is probably a good thing to want. But there is more to it than that. The business outcome you really want as a result of transparency might be “best use of scarce Team capacity, where 'best' is defined as aligned focus on high priority strategic requirements”.
The “why” part is particularly important. Organization change is hard, and your organization will often push back (what I call “organization anti-bodies”). Having a solid understanding of why we are doing this will help us maintain the resolve, the urgency, to get through the complex issues. In other words it helps with enablers 1, 3 and 4.
The other thing that I’ve found helps a lot when doing this kind of transformation is when leadership lead by example by adopting the new framework for themselves for their work. By working the change management associated with the move to Agile through Agile processes (it is after all just another form of knowledge work) the leadership demonstrates that what is good for the organization is also good for them.
This helps in many other ways as well. It helps leadership really understand what the new approach is, what it is like to be on a Team, what the roles are, and so on. It also helps set clear messages that we want in the organization. Take “transparency of decision making” for example, which is something we want in an Agile implementation. If management is in a Team, does and tracks work as stories, “demonstrates” results in a Iteration (Sprint) Review (including talking about what they’ve learned when they missed a commitment), it will do more to get the message across than any number of presentations etc.
To understand business objective of transformation to agile, to determine basic approach, potential obstacles, and metrics for success and set up the project for the work to be done.
What I have found effective in developing the “why” and also gaining a degree of buy-in is run a assessment workshop. Once we have this in place we can pull together a Sprint Plan for the executive team.
Expect leadership to be involved two days set of activities. “Leadership” in this case is the guiding coalition for the roll out of agile to the organization.
In addition to the team make-up we need to identify the Product Owner and the Scrum Master for the team. We also need to start thinking about identifying someone as the “Agile Coach” for the organization. The idea here is that you build your own expertise in Agile as it is applied to your organization so that you become self sufficient.
Day 1 – Why
- “Business reasons” workshop. All leadership. 2-3 hours. What are the business reasons we are going toward agile? What business problems are we trying to address? Which of these makes sense to address through an agile transformation. Result – prioritized list of objectives that will be used to drive the implementation of agile.
- “Obstacles” workshop. All leadership. 1-2 hours. Based on our current understanding of agile, what problems do we expect to see as we roll out the next phase of agile? Result – prioritized list of obstacles that we will need to address in the short term. Note: “obstacle” is defined as “anything which will slow the adoption down”.
- “Metrics” workshop. All leadership. 1-2 hours. How will we know we are being successful with the agile implementation? What metrics do we want to track? What kind of assessments do we want to run? Result – list of approaches we will need to track, with a plan to develop “baseline” information.
- “Training and Tooling Discussion”. 1-2 hours. Understand what kind of training / tooling we think we’ll need and look at kind of training / tooling that is available
- “Summary and Review” workshop. All leadership. 1 hours. Gather up results from workshops and interviews. Pull together base plan for training and coaching. Determine next steps and coaching required to get started. Result – documents (simple i.e. This is not a book) set of results and basic plan.
- “Retrospective” of day’s events.
Day 2 – How
We now need to determine what to do – who needs training, what kind of tooling, etc. Idea is to run this as a Scrum Project with the user stories in this case being related to the work of transforming the organization.
Pull together plan for first Sprint of the executive plan:
- “What is Scrum”: Review of Scrum / agile process
- “Team Name”: Create team name for the executive team
- “Objectives”: Identify preliminary objectives for first quarter of operation (i.e. rough, starting roadmap that we will come back and review).
- “Roles Identification”: Who are we providing value for as we do this rollout work?
- “Story Generation”: Brainstorm stories as a result of understanding what we want to achieve (yesterday’s work).
- “Acceptance criteria”: Make sure we know when the story is done.
- “Estimation”: Affinity based estimation to start with.
- “Team Capacity”: Realistic view of time team members can actually spend on this work. Also determine does sprint start and end dates.
- “Prioritization”: What order should we attack these in?
- “Split Stories”: If something is high priority and too big, work to split those stories and still provide value.
- “Commitment”: Break down top items into a series of tasks. Thinking about pairing on these. Determine whether can actually get the work done. Make commitment.
- “Working Agreements”: What do we want to do about daily scrum meetings, where will our work be tracked, what reporting will we do, pairing arrangements, etc.
- “Parking Lot”: Anything outstanding.
These workshops work best when done without having proxies do the work in the place of leadership.