I always recommend to teams newly transitioning to agile that they keep every iteration the same length. This helps them learn to manage their time, and after a few iterations they'll start to get a rhythm. Hopefully, they'll learn to work incrementally, doing testing and coding concurrently as part of one development effort, so that user stories are finished throughout the iteration, and testing isn't pushed to the last day.
Our team transitioned to Scrum late in 2003, and eventually adopted most XP practices. In the years since then, we have borrowed from Lean and Kanban approaches. We do sprint planning, but we often plan enough stories for the first few days, and bring in more stories as time frees up. Over the years, we've built large suites of regression tests at all levels which run continuously and provide quick feed back. Every day we have a stable build which we could release to production if desired. We do two-week iterations, but on rare occasions, we adjust as appropriate.
Photo: Top left is the theme we needed to finish; right side is the new theme
Last sprint planning, we planned to finish up a theme we'd been working on for several sprints, and start on a new theme which we expected would take at least a whole sprint on its own. When it takes more than one sprint to develop a new feature, we usually use run-time properties to "hide" them from end users until they're ready to release. We only work in our main trunk, we don't branch, and this usually works fine.
Two days into this new sprint, we realized that the model needed by the new theme needed significant database and code changes that would be costly to "hide" if we released before it was finished. We proposed to the business stakeholders that we take one week to finish the theme that was almost done, release it, and then take three weeks to do the new theme. At the end of four weeks, we'd be back on our normal schedule.
The business folks were happy to get a feature they'd been waiting for a week early, and were fine with us doing a three week sprint to finish the user stories in the new theme. It's been much easier to work on the new theme, knowing that we have three weeks to finish and we don't have to keep the new functionality "hidden". We have time to clean up old, unused code and database objects, and to update all the automated tests as needed for the new theme.
Note that there's a big difference in what we're doing, and saying "Oh, we thought we'd have all the user stories in the theme done this sprint, but we're running behind, give us one more week". We had enough information to plan an out-of-the-ordinary approach to this one particular theme. We'll go back to our normal two-week sprints, but our solid foundation of development and testing practices allows us to be flexible and "think out of the box" when needed.
How does your team handle unusual situations that come up? Is it too disruptive for you to change your schedule temporarily?
User Comments
Thank you Lisa for sharing the story.
I suspect that your team is in the 'ri' state of the 'shu' - 'ha' - 'ri'. So they know what they are doing!
Do you agree that when a new team is learning to be Agile, they should try hard to stay within the the "box"? More often than not, a new team trying to extend the box, because they are not use to that way of working. do you agree?
Manoj
http://manoj.vadakkan.org/
Hi Manoj,
Sorry to comment so late - somehow I didn't see this comment!
You made a good point. I think it may be true that newbie teams should work "by the book", so that they can learn all the practices and processes. Once they have experience, they'll be capable of judging what works well for them and what experiments they may want to try to better accommodate their situation. A team can't decide not to do practices that they don't even understand yet.
Actually my name is lisa too and i love your post
Lisa Parley
We changed from a 3 week die hard SCRUM approach to a way less process heavy 3 month cycle. SCRUM just had way too much overhead was putting too much emphasis on process over getting work done. Especially th retrospectives where the SCRUM master would ask us "how we felt" about the last sprint where quite awkward. Mainly because things never worked out as intended and the whole process was nothing else than a mini-waterfall, just without a plan or requirements.
Even with going to a 3 month cycle QA is still at the short end of the stick. Developers yell "done" a week before hardening leaving QA no time to properly test. The product owner already promised that the feature will be delivered and so it goes out the door without testing and most often just doesn't work.
Previously, QA had veto rights. When we thought that a feature did not have the quality that our customers expect it either was pulled or the release date was pushed out a week or two until quality was there. Now with a dictator at the helm (aka product owner) and the mad dash to release more in ever shorter cycles quality is taking a nose dive. I can only repeat it again: Agile is the death to Quality.
I found this old post via today's newsletter. Our team is one of many on the same program, and our sprint start and end dates are locked together. No flexibility. We just try to organize our work so we can complete all stories in a single sprint.