B (3:37)

Yeah, absolutely. So if you remember the book that I talked about on Tuesday's episode, Project to Product. So we did a transformation in one of my previous companies to adopt Flow framework. So it was basically transitioning all the teams from pure Scrum to flow based methodology. And we also did a minor rearg based on Spotify's model, kind of regrouping teams into squads, tribes building chapters, guilds. So this was all part of that transformation. And as part of this, we moved away from cadence based ceremonies like how we do planning and refinement in Scrum every week or every two weeks based on a cadence. We kind of moved away from that into a more just in time concept. So we would do just in time refinements, just in time planning. We refine stories only when there is a need. So that's just one example of the change that we did. But the main core change was to move from Scrum to a flow based methodology. So this was a pretty huge change. And this was being led by our engineering vp which kind of helped. So half of the problem kind of was solved right there because the executive sponsor was kind of taking the lead. So the VP did a great job of providing psychological safety. So even though the Scrum masters were involved in implementing the change, he took the lead for communicating this to the teams. Teams felt more comfortable and it was coming from the vp. There was psychological safety which is needed for any kind of change. And VP also insisted to look at this as an experiment. Those were his words in our Hardlines meeting. So he mentioned that this would be an experiment. So from next iteration we're going to move to Flow from Scrum and if it does not work, we can pivot. So those were really powerful words to hear from a vp. So that kind of helped set some, you know, set the stage properly. The teams felt more comfortable, they were not anxious and that helped setting the right foot at the beginning. And as far as tools go, we use tools like Lean Transformation canvas which would help us understand what are the success measures of this change. How are we going to measure success and why, why we are doing it, most importantly, and how we are going to do it. And also implementing feedback loops, sending out like anonymous surveys in a periodic fashion to get feedback on the various changes that we did. And most importantly, training. So when it came to training, we focused heavily on hands on training with lunch and learns with workshops with Agile games so the teams can understand all the different concepts that we were introducing, introducing all of the all at the same time. And we also did a good job of measuring the future state. One thing that which we could have done a better job was measuring the current state. We had some measures, but having a plan of we are going to compare the current state to future state once the change is implemented. That's something that to keep in mind as part of any changes that you might roll out. And also one thing that I took away as one of the key learnings is how agile can be truly agile. In the sense there is no one size fits all and we have all these different frameworks that's available to us. Why not use the best from all the available practices? The underlying principles are pretty much the same, but xbe Kanban, flow, they all have pretty good practices and it's always good to implement those and try to get the best out of it. I was lucky enough to witness that firsthand.

A (7:48)

Yeah, and that's a very important point that you mentioned. Agile isn't the one size fits all. In fact, it is a collection of principles and values that are then instantiated by multiple methods frameworks that people apply, like Scrum for example, or Extreme programming. So the core is really to adapt what is a whatever might be the process itself, but also the ideas of Agile to our local context. And the techniques that you mentioned, like having feedback loops implemented in the change process itself, I think is a great example of how we can give ourselves the opportunity to customize what Agile means in our specific context. Can you give an example of the type of changes or kind of adaptations that you had to do based on the feedback that you collected through those feedback loops?

B (8:52)

Yeah, sure. So we definitely did get a lot of feedback. One thing that the teams asked about first in the first two iterations is how can we say that we have improved? Is there anything that's there to prove our hypothesis? How are we going to measure that we have improved? So that was a great point. Some team members were really curious to look at the data points itself. They wanted to see did my velocity improve, did my time to market improve? Things like that. So having good definition of success measures. Right. So how are we going to measure. So the main, the main, one of the main reasons for doing this change is trying to be more flexible. So we didn't like. The leadership didn't like the idea of getting locked into two week commitment. So they didn't want to have that fixed backlog where it's hard to introduce change in Scrum. So that was their personal opinion. They wanted to be more flexible when it comes to prioritization. Let's think about what's the high priority today when the teams are running out of work. If the developer is running out of work. Instead of looking at the backlog which was set like two weeks ago as part of split planning, let's look at what's the most important thing to work on today and make it even more easier for prioritization. The flexibility is the one that we wanted to leverage in Kanban compared to Scrum. So those are things that we try to focus more on. So how we are able to prioritize on the fly and how we don't spend a lot of time in refining tickets which you might not be working at all in the coming weeks. So that was another thing that we tried to focus on the teams.

A (10:36)

So you measured those things specifically, right?

B (10:39)

Yep. Yes. How much time is saved? I mean how much time is not spent in non value adding activities? You don't have to refine something if you're not going to work on it in the next three or four days. Don't spend an hour refining 10 tickets. Instead refine the ticket that you need as and when you run out of work.

A (11:00)

Absolutely. And that ability to translate a goal like be more flexible into concrete metrics is extremely important because that is part of creating those feedback cycles you were talking about.

B (11:15)

Yep, exactly. Yeah. It might not be easier. We might theoretically explain this to the teams. But yeah, having some data points around how we are going to track the time spent in refinement in Scrum versus time spent ingestion time refinements.

A (11:32)

Absolutely. Well, that was a great story. Thank you for sharing that, Kartiga.

B (11:36)

Absolutely.

A (11:40)

We really hope you liked our show. And if you did, why not rate this podcast on Stitcher or itunes, share this podcast and let other Scrum masters know about this valuable resource for their work. Remember that sharing is caring.