Project managers as scrum masters? (Know your attractors!)

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.

Attractors

• 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.

What scrum is (not) – a meme

Although it's difficult to test or otherwise corroborate in any way, I have the feeling that 'the agile community' has been trending negatively over the last couple of weeks. At the very least there has been much to-do in my personal infosphere on the evils of agile (aficionados). The debate as to what agile, and specifically scrum, is seems to have been revived via a couple of slightly bad tempered posts by Ken Schwaber. Even well-loved fixtures of scrum lore like the chicken and the pig are coming under fire.

A framework that has inspect&adapt as one of its central tenets should obviously itself be under constant review, but what surprises me about some of the negative utterances I have come across recently is the vehemence with which they are delivered. Onediatribe in particular caught my attention, not only because (in a discussion of scrum) it ranged – in a series of three articles - over politics, (social) history and religion (subjects close to my heart), but most especially because of its toxicity. This guy really has a bee in his bonnet. His central metaphor, of priests and followers, is not without its worth though, and the unthinking uncomprehending dogmatists that seemed to have riled him so are definitely not a figment of his imagination – I have met them too. As for the parasitic consultants; I don't doubt they're out there either.

However.

Lambasting scrum as a religion, when it is explicitly constructed on empiricism, is a bit like creationists claiming that the theory of evolution is just one more belief system.

One of the issues that came up in discussions engendered by said article (also re-posted to LinkedIn) was the Scrum Alliance and its certification (specifically the Certified Scrum Master). I do not want to get into a discussion on the Scrum Alliance but I will defend the CSM, at least as delivered by Jeff Sutherland; not that everybody who attends the course comes away a good scrum practitioner but then again not everybody with a university degree in computer science is a good programmer.

Two days is enough time to get through the basics of scrum, scrum is simple and incomplete; that's the beauty of it. More importantly, Sutherland starts by introducing scrum as, above all else, a frame of mind; the way. He then goes on to explain shu ha ri and states that although it is good to follow the rules to the letter initially, gaining understanding is the goal and that once that goal has been attained the rules can be left for what they are; useful guidelines. He also explicitly includes XP and Lean as means to maximising the efficacy of scrum. Scrum as taught by Sutherland is therefore anything but an exclusive collection of dogma and rites. 

Further; the belief that agile development equates to no documentation, no planning and no commitments abounds. I have met teams that claimed to be running scrum when sprints were not fixed-length, team composition was wildly variable, random managers could change the 'sprint backlog' whenever it suited them, and most importantly, delivery of working software was haphazard at best. I have known team leads and scrum masters who 'itched' at the idea that 'their' charges were not all fully allocated – that their team was thus inefficient – and therefore assumed responsibility for sprint planning. With so much confusion out there some attempt at certification is absolutely necessary. If someone is a CSM then you know at least that they have been exposed to a version of scrum that will work if applied as learned.

But the CSM is not enough, Sutherland & Schwaber on the topic: certifications do not guarantee excellence

That is to say; scrum is a meme. And just as with the its physical cousin the gene, it is as good as impossible to make a perfect copy of a meme. Everybody who has ever learned anything about scrum has their very own unique scrum meme, some of which will be instantly recognisable as incomplete or otherwise faulty, some of which will be more difficult to assess, unless you test them. In that regard, it could be a good idea to view certification as a necessary, but not a sufficient, condition for recognising the owner of a good scrum meme. An agile hiring process could be even more useful – new scrum masters are hired initially on a one or two month contract, their performance (basic understanding, facilitation & communication skills, removal of impediments) can then be tested over a small number of sprints whereupon the team can decide whether the new scrum master is the scrum master they have been looking for.

I sincerely hope that the agile community succeeds in keeping its conflicts positive.