Inspired by a flattering response to a couple of tweets of mine at the weekend, which were a condensed paraphrasing of the Cynefin model's approach to complex problems, and keeping in mind @0x17h's (via @RonJeffries) paraphrasing of Arthur C. Clarke, “Any sufficiently advanced catchphrase is indistinguishable from wisdom”, I decided to try and illustrate my statement with an example problem and how it might be dealt with.
The (combined) tweets:
Similarly constrained self-organising systems will tend to organise towards one of a few attractors (patterns), the trick is getting the constraints right & then damping, or encouraging, patterns as they emerge. Know your attractors!
Problem statement
What to do with the project manager when transitioning to scrum?
Constraints
- There are only three roles in scrum; PO, scrum master & team
- Team should plan it's own work for a sprint and meet daily during the sprint to take stock and make any adjustments necessary to stay on track
Project managers often have former lives, meaning that many see a transition to scrum as a natural way for them to return to the work they actually love without losing face, i.e. they become team members. Others are naturally inclined to assume the Product Owner role. Some consider themselves good candidates for scrum master, or are cajoled into it, as the scrum master role is often, erroneously, seen as equivalent to the project management role.
Whether or not a PM will be a good scrum master is a problem in the complex or chaotic domain because, even if it were possible to identify all the variables involved, they are usually fuzzily defined and (therefore) difficult to measure – e.g. scrum master competencies – which means that causality is often discernible only in retrospect, if at all (retrospective coherence).
According to the Cynefin model's probe-sense-respond approach to problems in the complex domain it should be possible to observe the scrum for one of a few known attractors (this is what differentiates action in the chaotic & complex domains – act vs probe – probe implies that you have some idea of the range of possible consequences of your actions) and amplify positive developments and/or dampen undesirable ones appropriately.
For the sake of brevity we will specify two (possibly overly?) simplified attractors and a number of patterns by which you might identify which attractor your situation is headed for, and how you might intervene.
- Command-&-Control (alpha male/the way things were)
- Subsidiarity/Distributed cognition (agility; the path you want to follow)
Probe: PM transitioning to Scrum Master
- Pattern: Scrum master as power broker, boss (Attractor – Command-&-Control)
- Sense
- Scrum master determines sprint scope (in committee with PO)
- Scrum master dictates tasking
- Scrum master assigns tasks
- Scrum board not a source of truth
- Scrum master unilaterally decides on action in the event of interruptions
- Little regard for sustainable pace
- Estimates as commitments, regular overtime
- Respond
- Dampen
- How
- Insist that PO prioritises and Team forecasts
- Insist that scrum teams must organise their own work to be successful
- Insist that tasks be pulled, during the sprint, and not assigned (pushed) during planning
- Ensure that only work represented on the scrum board gets done
- Ensure that interruptions are triaged with team input, and resultant outcomes agreed with the team
- Ensure that variance in velocity is recognised as normal, coach the team and the PO to create stories small enough (~10 per sprint) such that (occasional) failure to fully meet the sprint forecast should not cause any serious business issue
- Pattern: Ingrained habits and perspectives difficult to displace (Attractor – Command-&-Control)
- Sense
- Scrum master plays an active role in task planning
- Daily stand-ups always convened by scrum master
- During stand-ups, team members look to scrum master when 'reporting status'
- Burndown updated by scrum master
- Burndown 'flatlines' till last day or two of sprint
- Stakeholders ask scrum master for status updates
- Scrum master coordinates effort to be able to demo during review
- Scrum master demonstrates new functionality during review
- Team communicates with other teams through scrum master
- Respond
- Dampen
- How
- Scrum master leaves the room while story is being tasked
- Schedule stand-ups for the same place & time daily, ask the scrum master to hang back until a few team members have approached the board
- Have team members pass a token during stand-up, whomsoever has the token, has the floor. Ask team members to update the scrum board as they talk. Have scrum master stand laterally to the group.
- Ask team members to rotate this duty, agree that the last to speak updates the burndown
- Encourage swarming, introduce explicit WIP limits
- Ensure scrum board is big, visible and kept current
- Make it clear that the scrum master's role is to facilitate the team's demo, not run it
- Introduce subject matter experts and leave the conversation, facilitate setting up communities of practice etc.
- Pattern: Scrum master facilitating & delegating (Attractor – Distributed Cognition)
- Sense
- Planning meetings not dominated by scrum master
- Retrospectives not about the scrum master
- Impediment list ordered, current & highly visible
- Team decides on sprint scope
- Tasking completed by the team
- Tasks pulled during the sprint
- Number of open stories less than number of team members
- Stand-up happens of its own accord, at the same time every day, in front of the scrum board
- Trust between PO and team evident
- Communities of practice emerging
- Respond
- Amplify
- How
- Ensure the scrum master does intervene when necessary (e.g. PO pressuring team)
- Have scrum master change format of retrospective on occasion to prevent stasis, ensure that PO allows for (a minimum of) one improvement story per sprint
- Ensure impediments are being cleared (list isn't just getting longer and longer)
- Ensure the team continues to challenge itself – organise it such that that variance in velocity is recognised as normal, coach the team and the PO to create stories small enough (~10 per sprint) such that (occasional) failure to fully meet the sprint forecast should not cause any serious business issue
- Challenge tasking outcomes; are we missing anything? etc.
- Remain alert to power distributions within the team
- Continue to try and minimise the number of concurrent 'open' stories
- Have the scrum master be the first to approach the board on occasion
- Continue actively encouraging transparency
- Bring people together, don't get in their way
This is anything but an exhaustive list dear reader, and in a real-life situation you will probably be both dampening and amplifying on different tracks simultaneously, but I'm sure you get the picture.
No comments:
Post a Comment