Scrum-ban aka common sense in Agile
Dec. 1, 2010
Not long ago I saw a presentation about Scrum and kanban and the differences between them. At the end of the presentation the presenters were suggesting that we should take from both these methodologies. This new mixed methodology could be called Scrum-ban.
Recently I was working with a design agency on a customer's new education site. We had two two-week iterations with an estimation meeting at the start of each iteration. Nothing new there, but what was different was that some stories changed during the iteration. I know that's not what should happen in proper Scrum (we do allow small change at Unboxed, as long as its not affecting the points for the story). But it's a real world and these things just happen sometimes. We didn't stop the iteration we just re-estimated the changed stories if necessary or split the stories into smaller ones. So the number of points for the iteration changed slightly. Sometimes we discovered that we needed some features from the backlog instead of the stories in the current iteration, so we just swapped them out.
After iteration 1, we ran the retrospective where we grouped the suggestions to improve the next iteration. The biggest group was about the repeatedly changing stories. The issue was not the change itself but the fact that devs didn't know that something changed. So in iteration 2 we made sure everyone who should know did know that something changed. And I have to say everything went really well because of that. We had proper stand-ups everyday, we wrote a lot of tests (we had 100% test coverage after iteration 1 and 98% after iteration 2) and we had quick discussions about the problems or new aspects in the story.
The result: customer is happy, design agency is happy and I'm happy too. We're not doing Scrum or even kanban. So it was something in the middle and it worked. So if you are in the position where Scrum, kanban or something else is not the best choice use your common sense. For me good test coverage, retrospectives, daily standups and good communication are all mandatory for doing agile well. What are your basic things that you do to achieve success with your projects ?