Scrum master for 25 people – What happened next

This is part of a 3 post series chronicling my real world Scrum Master experiences on the HMCTS Reform programme at the Ministry of Justice (MOJ) in the United Kingdom.
1. Scrum master for 25 people
2. Scrum master for 25 people – What happened next
(this)
3.
The DM who couldn’t let go

Monday 7th Jan 2019

I arrived back to work knowing the delivery manager didn’t want Scrum and ready to discuss my role. I was also now armed with a number of comments solicited from my previous post (submitted to the Agnostic Agile LinkedIn group) which I intended to spend some time going through and using in my discussion somehow.

First thing back, I learnt that two of the developers had been promoted into “Development Leads” (Front End Lead, Back End Lead) and that these individuals would now oversee two separate development teams, also that an announcement would be made at the standup about this [nb. my view is the promotions would create an anti-pattern, given a user story requiring both FE and BE work cannot now be taken through to Done by a single team]. The Development Leads wanted a meeting to understand what their priorities were, and how the team will work with their newly created roles. Aside from allocating out some urgent work to them first, the Development Manager, Scrum Master (myself), Technical Lead, Front End Lead, Back End Lead spent 2 hours in a room trying to determine a “light-weight agile way of working that wasn’t Scrum”. The meeting concluded when everyone was too tired to continue, without resolution, but with a decision to continue the conversation tomorrow. 

I largely listened, and countered the conversation when it became too Scrum oriented in theory given the stated desire to not use Scrum, but also the general acknowledgement that there are no single accountable Product Owners currently for any of the development work. 

Agile assessment of the team

I went home and drafted up a “agile assessment of the team” on the train so that I had a tangible, even if only an initial assessment and some recommendations to put on the table tomorrow before the conversation started. I used some of the comments from the Agnostic Agile community to form a possible agile future state for the whole team, but also drafted my assessment of the critical problems and structural limitations currently in place preventing moving to such a future state (ie. requiring management intervention at a level above the team). Included in this, I documented the following observations:

Current team setup

  • Large team circa 15 – 20 people managed through one daily stand-up
  • Arranged by function (UX, front-end development, back-end development) means that stories cannot be atomic (ie. taken through to done by one single team)POs operating at a roadmap, PI level (ie. not presenting dev stories at planning)
  • No single BA acting as proxy PO making sprint by sprint planning decisions for the team regarding what needs to be done
  • ** Dynamic task allocation to team members from multiple sources **

eg. the Delivery Manager, BAs, and Technical Leads all can allocate tasks at stand-up and/or as needed throughout the day (in lieu of hands-on PO or single empowered BA), which results in:

  • Context switching – loss of productivity, accountability to finished work items
  • Reduces the benefit or desire to hold detailed, team wide planning sessions
  • Story A/C needs to be written and reviewed before developers can start

Tuesday 8th Jan 2019

I presented the “agile assessment of the team” to the Delivery Manager, Technical Lead, Front End Lead, Back End Lead for discussion. They (surprisingly) agreed and also seemed relieved the conversation now had a focus. I also, when the time was right, put to them what I saw as the most pragmatic (and only) way forward that I could see to enable their desire for a “light-weight agile way of working that wasn’t scrum” given where they were at, which was to: 

Simply create a Kanban board for each of the 4 products being developed, along with simplifying the JIRA process for creating each ticket and getting it onto the appropriate board, so each team member can self-serve ticket creation (irrespective of source) so that boards at least represented “here and now” reality and could be useful at the daily standup.

[In essence, they were given permission to “break sprints” (which were not properly planned anyway, or planned at all, and became out of date within a day of new ad-hoc stories reactively coming in)]

This was accepted as the only possible way forward, and in the same regard we effectively agreed my role as a Scrum master would stop and become to create the Kanban boards and enable individuals from the various teams to conduct the standups themselves. At this point, I deleted all Scrum ceremony calendar invites I had rolled out across all products and relinquished my (assumed) responsibilities back to the teams and individuals within them. nb. This was the start of sleeping properly again, but it took a few days for me to unpack.

Wednesday 9th Jan 2019

I came to work motivated to knock off the Kanban boards and start transitioning into a handover of my role (largely seen as the guy running the daily standups). 

However, irrespective of the last 8 weeks of JIRA “cleanup” I had already completed, the current co-mingling of 4 products worth of tickets within a single JIRA project along with inconsistent use of Fix Versions, Components, labels; and the general non-occurrence of backlog refinement sessions combined with my lack of JIRA admin rights meant I couldn’t create new JIRA projects nor bulk manage existing tickets; ended up simply being too much for me to single-handedly fix. My despair at not even being able to create some functioning Kanban boards on top of the current JIRA project was palpable but also not easily understood by the current team who knew very little about JIRA. This was a low point. 

Luckily by chance, I ran across the on-site Atlassian admins who I fully brief and explained that in 12 weeks, we hadn’t yet managed to get JIRA to be able to facilitate a simple daily standup. I kept my frustration under control and pleaded for help…

Thursday 10th Jan 2019

Thanks to the help of the Atlassian admins, we now have 4 separate JIRA projects, one for each of the 4 separate products being developed, with all legacy tickets migrated over as best as possible, with a small subset of those being worked on currently marked as In Progress and visible on the board. We have been able to start running daily standups off each product board, which we step through in sequence board by board at the standup. 

nb. The new JIRA projects and Kanban boards: I decided to actually create these boards as Scrum boards, but with them acting like a Kanban board by having a single, open ended sprint. This meant the mass of migrated tickets could be “dumped” into the backlog and kept hidden at the standup, allowing the BAs to clean up these dumped tickets over time. In the meantime, new tickets are simply created and brought into the sprint when worked on, or if a ticket already exists then we simply assign it to the current open sprint to move it out of the backlog onto the board. Behind the scenes, I will clear down the open ended sprint every two weeks by effectively closing and reopening the sprint so that I can at least start to track the number of tickets done each 2 week period.

Going Forward

By finally managing to break the team into 4 separate product teams last week in line with the actual way of working happening on the ground (implemented through the JIRA split and mass ticket migration), it’s become clear that the expectations and responsibilities outlined to myself as a Scrum Master for a “single team” was an unreasonable responsibility and workload for a single person.

There is an opportunity to further embed agile here in the 4 teams going forward, however given the desire to not formally restructure to a more agile way and also the limitation of just myself in a servant leader role, my thoughts as to what to do next are as follows:

  • Formally have my role changed to Agile Coach
  • That I will be working across the 4 product teams but without delivery responsibilities for items within each team that would normally fall to a Scrum Master (ie. all team responsibilities will remain within the team but with me on hand to support eg. I will not be “unblocking obstacles” for them as usually done by a Scrum Master)
  • Agree that agile embedding will be incremental, through coaching existing product teams and individuals in these teams, that existing “ceremonies” will continue on but with my attendance (ie. I will not be personally running planning meetings for them as usually done by a Scrum Master)
  • Work with the Delivery Manager to develop a prioritised list of agile topics, which can be addressed and embedded one by one within the team.
  • Solicit a consensus “health check” / maturity score before starting an agile topic, and also periodically reassess as the embedding proceeds

At this point and in terms of priority, the Agile topics seem to be:

  1. Improving the process of how stories end up being worked on by developers, including things currently happening that cover refinement and planning (either formally or informally)
  2. The writing of good stories, including
    1. Three amigos to cover off any “blank”, unrefined tickets current being thrown over the fence to the developers
    2. Introducing a more formal definition of ready to play
  3. Facilitating good team retros to encourage regular and incremental improvement
  4. Seeking ways to move towards single responsible individuals for each product backlog (whether actual Product Owners or proxies)
  5. Translation of roadmaps into built features (nb. this is a huge topic)

I’d be interested to hear thoughts about any of this.


Frank Ray

Ask any project manager about the key to their success, and they will say that delivering a project is often more like a "dark art" or by chance, than a predictable science.

They may also say that a project going 'off the rails' was one of the most stressful things they have professionally experienced. And unfortunately, it’s all too common.

Risk assessent tool for IT and software development projects. Try it now for free

Leave a Reply