0

I've been brought into an organization to improve their Release Management. A couple years ago they went through a transition to Agile development. I have two work streams: Run & Improve.

Boots on the ground (Run) my release management team is ensuring sprints run on time, that user stories are in Azure DevOps, sprint & increment planning is generally done, etc. We're keeping things moving the same way it was when we arrived.

Higher level (Improve), my manager would appreciate a roadmap for improving things. I'm collecting data on each team and how they run their sprints (writing features/user stories, grooming (or lack thereof), sprint planning (or lack thereof), etc.)

So, I need to assess the health of the engineering process as it currently is and make recommendations for how to get it to a better state moving forward.

For context, one team does grooming weekly. Their stories are well written, with all criteria included. They are prioritized but do not include work effort needed, so I've observed many stories carry over to future sprints.

Another team (who adds upwards of 10 stories a day) does zero grooming, has poor story development (often with missing criteria) and does all of their sprint planning in one large meeting. They also include detailed work effort at the task level, so their estimates for workload have been generally accurate.

Other teams are similar to the above.

My question is, what assessment/analysis methodology would be best for this need? I.E. It's not a "5 Whys", but perhaps "SWOT"? Something else?

3

If I understand your situation correct you are looking for a way to help teams to talk about/analyze/assess what areas to improve and give the people that supports these teams (mangers, coachers, etc.) a high level summary of what’s working and what’s not. Based on this I would recommend you to look at the Squad Health Check model by Henrik Kniberg.

What this model basically does is that you run workshops where members of a team discuss and assess their current situation based on a number of different perspectives (engineering process, easy to release, suitable process, fun, speed, etc) and create a graphical summary of the result. You then use the data to help the teams improve and the people outside of the team gets a clear visualization of what’s working and what’s not.

With the data on what areas the teams needs to improve on you could create a roadmap on what improvements the teams wants to do and when. The output of the health check is a roadmap in itself in a way but you can of course create a more detailed roadmap to your liking if that's a desired outcome.

  • Brilliant! This is exactly what I was after -- a Maturity Model, but one that really suits what I'm trying to get down to. This type/version isn't something I've seen before. – richardlpalmer Aug 28 at 14:57
  • @richardlpalmer glad to hear I could help! Henrik Kniberg and his colleagues at blog.crisp.se has a lot of good ideas for almost anything regarding improvement at companies and in teams! Best of luck to you! – Oskar Collin Aug 29 at 7:34
  • Thanks for the link -- I've added it to my Bookmarks. :) – richardlpalmer Aug 29 at 14:52
2

So, I need to assess the health of the engineering process as it currently is and make recommendations for how to get it to a better state moving forward.

As this is an agile environment the questions I would be asking include:

  • Are the teams themselves failing to self-improve?
  • Are the teams empowered to fix their own problems?
  • Is the working environment collaborative?
  • What do the teams themselves thinks are the problems?

It would also be worth defining what improvement means to the people in your organisation. Is it simply more lines of code written? Is it an increase in satisfaction of the business users? Is it the speed with which the teams respond to change?

What I would avoid doing is coming up with ideas, submitting them to my manager and then dropping them on the teams. This will disempower the teams and make them less likely to resolve their own problems in the future. Agile is about building teams that know how to inspect and adapt and self-improve.

  • This is definitely in keeping with what I have in mind -- also assessing where they're at with regards Agile best practices. I'm leaning toward doing SWOT on each team and then rolling them up into a more generalized analysis, which is the type of analysis I'm trying to figure out. Maybe PEST (Political, Economic, Social and Technology) as it works well with SWOT. I don't think an RCA (Root Cause Analysis) is appropriate, nor Porter’s Five Forces. I'm still feeling a bit uncertain of which framework to use for presenting... – richardlpalmer Aug 28 at 14:51
  • I'm afraid that I am not familiar with those frameworks. My approach tends to be the typical format of a Scrum retrospective, which is to facilitate the team to identify their own problems, prioritise them and then focus in on one or two to resolve. – Barnaby Golden Aug 28 at 18:08
  • 1
    Oskar's response ended up being perfect for me. Thanks again, though! – richardlpalmer Aug 28 at 22:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.