Disaster Retro

#1

I’ve been trying to following the topic at: Your Favorite Agile Retrospectives. POST THEM HERE AND LETS BUILD THE ULTIMATE LIST but with 58 posts, it’s a prairie harvest of ideas but I’m looking for specific situational feedback.

We had something go to shit for a specific team. A major release push before the end of year holidays where they were told that “this was the right time to do overtime” and that we’d sleep well and recover over the holidays and come back refreshed and run a proper flow/process in the new year. They pulled it off and did it. They came back refreshed and had a full week of breather and recovery… (smelling the “and then” coming?)

2nd week of the new year and we learned that the first (and only fully live) customer on the product had been promised some stuff with a deadline in 3 weeks and the implementation group on site realized they couldn’t deliver with custom extension tools (something they spent 2 months to figure out without us knowing this problem existed). So, the team was asked to bypass all process, all quality measures, and work two weekends in a row to shoot the moon.

Impressive part… they did. (though we now need them to loop back and do proper cleanup of the mess, dragging out morale / burnout and letting exec’s forget the work wasn’t done with the deploy).

We want to have a post-mortem with the team next week as we come back in for a soft landing and try to recover.

My main question is this… anyone have ideas for the best format for this kind of retro? Our standard approach with the leaders and soft skills available will suffice, but if someone here has a specific format for this specific case… I’m open to ideas!

Thanks!

#2

As someone said, I think it was @Colleen “The retro format doesn’t matter, all that matters is that you retro…”

That said… what do you think you want to make visible that currently isn’t?

I’m loving Dominica DeGrandis’ concept of the Five Thieves of Time…

  1. Too much work in progress (WIP)
  2. External dependencies (unknown, cross-team, bus factor…)
  3. Unplanned work
  4. Conflicting priorities
  5. Neglected work

Is one of those ^ a prime suspect?
Or do you need clarity on which bandit is the worse?
Perhaps you look there…

#3

Oh, we know it was #2 (unknown) and #3…

I know we need to let the team vent (you have to empty the vessel before you can fill it)… and help create an environment where we can rebuild trust in us (leadership) again to not have it happen again.

#4

Where was the “failure point”?

Was it that the team was unable or unwilling to say “No.”

Is the problem with the Decision/Delegation Matrix?

I’d look for ways to make the problem really visible. The solution(s) will then present themselves…

  • What elements of this thief’s modus operandi does the team have control over?
  • What don’t they have control over, yet? (Stress “yet”… it’s an important nuance)
  • What are the motivations for putting up with this crook?
#5

I’d have to second Andy. As in many things, it sounds like communication is both the cause and cure here. Making visible that which is invisible. Showing the effects(costs) of the “thief” to the leadership may also help. My guess on the aftermath is visible through:

  • Additional unplanned work
  • A slower velocity over the next few weeks or less steady flow
  • An inflated backlog
  • Increased lead times for work

The remedy lies in communication of the same. It sounds as if a number of retrospectives need to happen inside and outside the team. Is it possible to run retros or workshops with the team(s) further up the chain that affected the flow information?

#6

The team was not informed that the customer had a need, and that another part of the organization was trying to solve it. They were not aware that if it fell through, it would hit them, and have a specific date.

The team asked for pushback, but it went up the chain and management came back with, “do it, or we lose it”. (and the impression is millions of dollars of impact) Thus, we were unable to say no.

This is an interesting idea. The big part of the problem is that the part of the organization this issue seeded from is “outside the reach” of the current agile adoption. That being said, we don’t have to call it a retro to get people in the room and discuss.

#7

I’d call it a workshop and make it a PD activity. I like these. It is also an opportunity for starting to bring ideas to other parts of the organization. It isn’t the transformation, but it might prepare the ground a little. There may be opportunity here.

Something like “When the beaver dam breaks: exploring flow versus flood” would be fun. The communication issue you faced is one of the lean wastes, so exercises around the idea of flow and communication might be useful.

I think I have a Kanban type activity that might work. I’m working my way through the idea. I’ll post here when I’ve thought it through properly.