Pagina's

Wednesday 30 May 2012

Calmly going where no (wo)man has gone before (or have they?)


My colleague and I are setting up an agile consultancy within an existing consulting firm, Qualogy. Our mission is twofold – spread the agile word, increase agile expertise among our own consultants and build and promote an agile services portfolio. I've been involved for about a year and although we have a long way to go, things are really beginning to take shape.

Because of the nature of our mission we are always looking for ways of killing two birds with one stone. For instance, we offer (agile) training to our partners and clients, but also to our own consultants, which has the double function of increasing agile expertise all round while hopefully making a name for Qualogy as an agile provider. This is easier said than done however and we're not the first to think along these lines; the market is nearing saturation point. We try and set ourselves apart by concentrating on technique over process and by getting the very best to come and offer courses not easily available elsewhere (in the Netherlands). For example, Ron Jeffries & Chet Hendrickson have been to Qualogy twice to deliver hands-on agile development training.

Recently we added Gojko Adzic's Specification by Example training to our portfolio. As is our policy, Wouter & I attended this first instance of the course at Qualogy. Due to some late cancellations from our own consultants we could only claim a tarnished victory – good service to our clients, not much penetration among our own consultants. This slight disappointment did not impinge (much, after a while :-)) on my enjoyment of the course though. As is always the case with when attending these courses, I'm not just interested in the material but also in how the course is run. Adzic was a joy to watch.


This post is not however about the course itself, or even Gojko's admirable delivery of same. As Adzic himself writes, and as was clear from how he delivered the course, Specification by Example is method/framework/etc. agnostic. He tended to use lean terminology during the course, speaking as he did of bottlenecks and/or the theory of constraints as opposed to impediments for instance, while at the same time, his explicit insistence on cross-functional collaboration smacked of agile. What I would like to share from my learning is the realisation that Specification by Example (or BDD or A-TDD) might well be the M (mashup) we so badly missed at CALM alpha!

At CALM alpha, Dave Snowden named three heuristics that seemed to offer common ground between (social) complexity, agile and lean; fine-grained objects, cognitive spread and dis-intermediation. Fine-grained objects meaning; small well-defined stories, short clearly-demarcated iterations etc, cognitive spread meaning; input and reasoning from multiple perspectives & interests, set-based design etc and dis-intermediation meaning; visualisation, no separation of design & implementation, narrowing the gap between information and meaning etc.

Back to our Specification by Example course – Gojko was prompted a number of times during the course to state that any specification which required an ever-growing list of examples to illustrate it should be split. While working on turning 'classic' requirements into specifications with examples, merge&diverge was explicitly employed to ensure the best results. But it was while examining a bunch of specifications with examples for how useful they might be as respectively, a tool for shared understanding, acceptance tests and/or documentation, that I was struck by why I had found this idea of living documentation so powerful all along.

Requirements that are tests that are documentation – no handovers, no translations, no interpretations, no esoteric jargon pitting one guild against another – that's lean, that's agile. Specification by Example is the ultimate in dis-intermediation!

Tuesday 15 May 2012

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.