3months Agile Consulting Blog

It’s gonna be cool, it’s gonna be informative and it’s gonna be fun - in short it’s gonna ROCK!!!

We have been working behind the scenes over the last few weeks to organize a new barcamp event here in Wellington. The topic of this event is agile in all its forms and shapes. Have a look at the official barcamp wiki to find out more about what and who to expect.

Overall I can say I’m very pleased with where we’re at. Deloitte has offered us the top floor in their premises at Brandon Street (overlooking the harbor), the logo is done and the flyers are on their way. Huge effort particularly by Brian and Thomas to get that sorted!

I guess one of the challenges being an organizer of a barcamp (which is by nature a self-organizing event) to find out what to do - and what not to do. We are concentrating our efforts on the venue (location, facilities like WiFi etc), raising money to buy t-shirts and food and spreading the word. What we don’t want to do is organizing the day itself. If you want to learn about agile, share stories and/or experiences with peers, network with practitioners or talk to people about the dark side of agile just come along. And if you feel like you have something to say just go up to the whiteboard and put your name and your topic down and be a speaker too! It’s that easy!

One of the more difficult things to do during a Scrum sprint (or an iteration in general) is to manage the scope throughout the sprint. With the team working closely with the business to ensure we actually meet the business expectations there is a fine line between incorporating feedback and taking on more work.

Granted, without a detailed specification there is room for interpretation and it’s in the nature of an agile development (and one of its many advantages) that great ideas pop up as we can see a first cut on a particular functionality. However it is also important to not make the mistake of confusing the new ideas with the original sprint scope. You may be able to implement some of the ideas right away - depending on how much work is involved to make it happen. But often these ideas enhance the functionality you set out to deliver - in this case you are mostly better off to add them as backlog items and defer them to a later sprint. You might even find out that if seen in the context with the remaining backlog items they become less important and eventually aren’t implemented at all. If they are truly great ideas then surely the business will prioritize them into one of the next sprints.

If you take a four developer team and a four week sprint in which the team works closely with business representatives as an example it is reasonably to assume that two of these ideas (assume on average maybe 6h/idea) per developer come into play. Then maybe there are a few little other things (~1h work) your team is asked to do that is not directly related to the sprint goal and suddenly there is a full week of work that you haven’t planned for. It’s easy to miss a sprint goal if you keep doing this.

One trick is to consider implementation details purely from a business value point of view. Take for example a screen in an application that is used in a data entry process but also in a work flow. If your sprint scope includes the data entry but not the work flow then the screen is completed once it implements the data entry functionality - even if the team has to go back and modify the screen to make it work also for the work flow. With little things coming up ask yourself the hard question if they are necessary to complete the sprint goal! If not they go into the backlog and will be prioritized in the next sprint planning session!