In Rachel Davies' Agile Mashup talk at QCON 2008, she noted that many teams have a "polishing" iteration, where no new functionality is released.
My team have recently added this: we find we need a bit of space to step back and look at the application from a "big picture" point-of-view. Sometimes it's useful to look at consistency across the application: particularly from a GUI point-of-view. It's also good to make time for exploratory testing. Finally, we like to make some space to incorporate the feedback we've got from the business during the iteration.
Perhaps we should be doing some of this stuff as we go; but at the moment we're finding a polishing iteration just before release is working very well for us.
Showing posts with label scrum. Show all posts
Showing posts with label scrum. Show all posts
Monday, 17 March 2008
Agile Mashups
I attended Rachel Davies' talk at QCON 2008 about Agile Mashups. She made the point that in the real world people take a variety of practices from different Agile methods; as a simple example there are Scrum teams using TDD and XP teams using burndown charts. She pointed out a few practices that seem more optional, such as pair programming and sitting together.
I find there's a very interesting tension. On the one hand I think it's important to know what "good agile" looks like. There is a danger that some teams throw away their documentation, hack and claim to be Agile. So to sort this "cowboy agile" from the real thing, you could use the Nokia Test, which is a checklist: tick the boxes and you are doing Scrum :-)
Particularly, when you start Agile and don't understand all the subtle interrelationships of practices and sometimes unexpected effects of doing certain things, it's useful to try to stick closely to a process and really try it, to find out what works for you and what doesn't.
On the other hand, a central piece of Agile is self-organising teams that inspect and adapt. A good Agile team will have assessed these practices for themselves, tried tweaking them, thrown away the ones that don't work, tried new things. So trying to assess Agility through a checklist runs the risk of constraining a team and stopping them adapting.
I think really good teams find how to get this balance right: you should feel free to try new practices, even quite radical ones, and think of ways to properly assess and modify them; at the same time, you should be serious about really trying the practices from your method of choice
and getting a deep understanding of why those practices are there.
I find there's a very interesting tension. On the one hand I think it's important to know what "good agile" looks like. There is a danger that some teams throw away their documentation, hack and claim to be Agile. So to sort this "cowboy agile" from the real thing, you could use the Nokia Test, which is a checklist: tick the boxes and you are doing Scrum :-)
Particularly, when you start Agile and don't understand all the subtle interrelationships of practices and sometimes unexpected effects of doing certain things, it's useful to try to stick closely to a process and really try it, to find out what works for you and what doesn't.
On the other hand, a central piece of Agile is self-organising teams that inspect and adapt. A good Agile team will have assessed these practices for themselves, tried tweaking them, thrown away the ones that don't work, tried new things. So trying to assess Agility through a checklist runs the risk of constraining a team and stopping them adapting.
I think really good teams find how to get this balance right: you should feel free to try new practices, even quite radical ones, and think of ways to properly assess and modify them; at the same time, you should be serious about really trying the practices from your method of choice
and getting a deep understanding of why those practices are there.
Subscribe to:
Posts (Atom)