We're Agile

[article]
Summary:

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.

Fig 1

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

3 comments
manojvp's picture

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/

July 3, 2011 - 12:24pm
Lisa Crispin's picture

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.

July 28, 2011 - 12:54pm
Anonymous's picture
Anonymous

Actually my name is lisa too and i love your post

Lisa Parley

November 4, 2011 - 1:28pm

About the author

Lisa Crispin's picture Lisa Crispin

Lisa Crispin is the co-author, with Janet Gregory, of Agile Testing: A Practical Guide for Testers and Agile Teams (Addison-Wesley, 2009), co-author with Tip House of Extreme Testing (Addison-Wesley, 2002) and a contributor to Beautiful Testing (O’Reilly, 2009) and Experiences of Test Automation by Dorothy Graham and Mark Fewster (Addison-Wesley, 2011). She has worked as a tester on agile teamssince 2000, and enjoys sharing her experiences via writing, presenting, teaching and participating in agile testing communities around the world. Lisa was named one of the 13 Women of Influence in testing by Software Test & Performance magazine in 2009. For more about Lisa’s work, visit www.lisacrispin.com.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

May 04
May 04
May 04
Jun 01