The DM Who Couldn’t Let Go

This is part of a 3 post series chronicling my real-world Scrum Master experiences on a major Digital Transformation Programme in Government in the United Kingdom.
1. Scrum master for 25 people
2. Scrum master for 25 people – What happened next
3. The DM who couldn’t let go (this)

This week it finally came to a head with the Delivery Manager (DM). Heated exchange, but luckily not in a personal way that should limit our working relationship going forward. But an encounter. And I think in a strange way it has now illuminated the root cause of issues in the team and explains why we see a lot of the perverse ‘on the surface’ behaviour…

Before Christmas, Product A, which had been in research and design for the prior 6 months culminating in a high fidelity prototype covering a number of road mapped releases (don’t ask me about this, I wasn’t employed at the time…), had their whole development team allocated to Product B to get that out the door first, just as they were preparing to start building Release 1.0 of Product A. 

The DM gave assurances to the Product Owner (PO) for Product A, that even though development was going to be delayed until the new year, they would still have enough capacity to meet the Release 1.0 planned deadline. 

Fast forward… Product A’s Product Owner started to get a bit nervous last week, so I had one of the BA’s put together an initial development backlog for Release 1.0 by extracting the relevant journeys from the prototype, agreed with the DM to convene a planning meeting with the PO, BA, Tech Lead, Researchers etc, to go through the stories and commence development. [nb. Instead of explicitly scheduling a planning meeting myself, which was my behaviour previously as the “Scrum Master”, this time I piggybacked off an existing, regular PO catch up meeting so that responsibility for attendance remained with the PO…]

The meeting happened… (nb. the DM was absent but that was usual for the PO catch ups with the team) Synopsis: lots of talking around the stories, BA stood at the front with stories on screen, frustrated, waiting for the team to want to step through the detail of each – which didn’t happen. Tech Lead, who had been aware of the meeting and backlog ahead of time, threw up his hands saying “I don’t currently have any developers free to work on this, looking at the backlog takes me away from my development duties on Product B, and the scope is already fixed for Product A Release 1.0 so we’ll just have to build whatever the stories say when I get given some developers by the DM”

We agreed to defer the planning until next week’s catch up, given indications that developers should be becoming free shortly. My catch up with the PO separately after the meeting went well, there was an acknowledgement that whilst the meeting felt very awkward, it was a good step in the right direction and with a bit of practice it would become normal. I also ensured the PO understood there was a development board, which is presented daily without fail (some tech and environment setup tasks are in progress on it currently), and once development stories are started, this will be a primary way to visibly track progress for all involved.

The next day, the DM got really quite angry with me, saying things like

• “The PO has no right to be involved in development matters”
• “You have no right to talk about development with the PO”
• “I’m in charge of who does what in the development team” (nb. The dev team is large enough to have a dedicated Tech Lead, and 2 sub team leads)

I basically responded by saying, “before the meeting, you said clearly to me in front of the team ‘you are running the planning meeting for Product A this afternoon at the PO catch-up slot, aren’t you?’  What did you expect for me to do there?” In short, he said “look at the stories, t-shirt size the stories, have them ready to give to developers – but nothing more”. ie. have them stacked up ready to build in one fixed scope Release 1.0, without the PO involvement at all except for demo attendance.

When I really pushed for when and how the tickets would actually be assigned to developers, ie brought out of the backlog and put into the current sprint and moved onto the board (I put it bluntly to the DM: “I open up my calendar and see not a single ceremony to do this…”), he said very clearly “on a daily basis, as I direct, at the standup or otherwise, as and when developers become free”. It also became known that his view of “agile” was “reactively responding to requests on a daily basis” and that agile practices were “purely theoretical” in the team given his need to control what goes on.

I conveyed the additional thoughts during the conversation:

• I wasn’t going to conduct another planning meeting on his behalf, he would have to do it himself if he needed to do so, as without dedicated development team members, I couldn’t be responsible for planning work
• I will communicate to the PO, that the planning meeting for the following week wouldn’t happen and that to speak directly to the DM regarding any delivery matters
• Although the whole team has complained of an “absent PO”, working in this manner has likely disempowered the PO completely from anything to do with delivery, and leaves them only able to design future releases (in isolation)
• I’ve been disempowered as the Scrum Master and that it is unreasonable to expect that I could be able to run a planning meeting and embed transparency to the PO in this arrangement

I’d be interested to hear what any of you make of this. There is a lot more I have to say in the coming week or two, as I will be drafting a more formal assessment of ways of working in the team for the PMO.

My afterthoughts (21 Jan 2019)

Having mulled things over, 

• PO doesn’t have a voice in delivery of current release
• PO doesn’t write dev stories (or is involved in the refinement of these either)
• PO is effectively working at fixed release scoping
• DM allocates task on a daily basis, as required across multiple products, at the standup and/or as needed throughout the day, as and when developers become free
• Tech Lead separately maintains a (bullet point) list of technical tasks for developers
• Dev team are context switching on a daily basis (“headless chickens” – their words)
• DM tracks allocated tasks closely, often unable to understand why they take so long to complete, if at all
• Dev team usually work off verbal instructions, in the absence of written stories with estimates 
• SM can’t run a planning meeting between PO and Tech
• Everyone is very busy with little time or capacity for improvements beyond status quo