One of the common examples of “Stop the line” principle is, the usage of continuous integration in the agile world. Continuous integration, halts a build if there are test failures. And the onus is on the team to fix it immediately. The problem we have, is addressing bugs that were reported by testers as soon as possible. We also want to build a culture of zero tolerance to bugs. How do we incorporate this into our daily work cycle?
Recently we started conducting our daily scrum by using the order of the user stories on the board. Instead, of going round the room; we run through the task board, top to down and anyone working on the story will provide their updates (answering the 3 questions pertaining only to that user story). Sounds interesting? – Here’s a blog post on the subject by Mike Cohn.
To highlight the fact that we do not want to tolerate bugs, the testers prioritized the bugs as the highest item in the iteration backlog. So during daily scrum, when the team runs through the board top to down, the bugs are first thing that the team needs to address. Although, we have not gotten to addressing bugs as soon as we find it, we now ensure that we deal with them every day.
Posted in Agile
Tagged with: agile
We recently created a Value Stream Mapping (VSM) for a category of high cost features on one of our teams. The interesting thing we discovered was, we uncovered issues that did not surface during the regular sprint retrospective. How did that happen?
Could it be, we do not have effective retrospectives? Unlikely, as this team has been pretty good at it. Of course, retrospectives do not catch all the things we want to get better at. But this was a pretty significant miss.
The thing that stands out is, the VSM was more focused on a particular category of work. Whereas during a retrospective, the team is looking at all kinds of work that was done in the sprint. Here are two key observations…
- The focus, let the developers to mull more about the particular kind of work
- The act of creating a VSM, helped the team to revisit the various stages of development and ponder more about what exactly occurred at each stage. (The developers who participated in the actual development work, constantly revised their previous statements recalling some new details.)
This does not mean, we will stop doing retrospectives. However, it was nice to see that we could glean valuable insight into the development process with this exercise.