Calling 'Timeout!'
timeout - when play is temporarily suspended at the request of a team to discuss strategyOne of our team
norms is
anyone can call a timeout. When people are busy, either
pair-programming or otherwise engaged, and someone needs to discuss or share something with the rest of the team, they can call a timeout. In response, we huddle in the
bullpen or congregate around a whiteboard. A timeout is not called lightly because everyone knows it interrupts
flow. And it takes each person 15 to 20 minutes to get back into their
flow following the interruption. However, our team is
self-organising and we make all our decisions by
consensus. Calling a timeout causes everyone to down-tools and brings everyone together to focus on the reason for the timeout. It creates an opportunity for everyone to express their opinions and for the team to arrive at a sustainable agreement about the steps forward.
Tags:
agile,
communication
Links to this post
Bullpen
In a recent post about our
iteration zero I said that we were waiting for permission to construct a team bullpen. Well, here it is. It's conducive to
osmotic communication and
pair-programming, and it has enough room for team huddles and the
daily stand-up around the planning board.
bullpen2
Originally uploaded by sjb140470.
bullpen
Originally uploaded by sjb140470.Tags:
bullpen,
war room
Links to this post
Counting down to the iteration review
In a previous iteration we experienced a bit of a crunch leading up to the iteration review with our
product owner, which resulted in a 1-hour slip to the iteration review. Not catastrophic admittedly, but this broke our rhythm and it's disappointing that we let it happen. How did this happen? On the penultimate day of the iteration we completed the
user stories that we committed to deliver in the iteration planning game, so we agreed with the
product owner to bring forward the next 2
user stories, each estimated at 1 ideal pair day. The team was so focused on getting the 2 additional
user stories done that it basically lost track of time.
In the iteration's heartbeat retrospective the team asked if some structure could be put in place to help them have everything ready in time for the iteration review. Now our iteration review is conducted at 16:30 on a Tuesday and involves a demo of the iteration's
user stories on the UAT box. And we use a
cruisecontrol project to build and deploy to the UAT box. So I decided to implement a '3 cuts and you're out' strategy. I reconfigured the
cruisecontrol project for UAT to perform 3 timed cuts (a cut is a full build and deployment). The first cut is taken at 15:00 and
cruisecontrol fires a single 'beep'. The second cut is taken at 15:30 and
cruisecontrol fires 2 'beeps'. The third and final cut is taken at 16:00 with
cruisecontrol firing 3 'beeps'. Like a plane is guided in to land by runway lights, the audible beeps count the team down to the iteration review by deploying cuts of software from
subversion. If
user stories are not
done by the third cut they are not included in the iteration review and they are not counted towards the team's velocity.
Tags:
extreme programming,
iteration review
Links to this post
Start iterations on Wednesdays
A working week runs Monday to Friday, so it feels natural to start an iteration on the Monday and finish it on the Friday. On the
Amplifying Your Effectiveness site,
Johanna Rothman asked
'Whats wrong with Wednesday?'Our iterations are 1 week in duration and they start on Wednesday and finish on Tuesday. Friday night is the start of the weekend so it's great to always get away on time. And coming in on the Monday with energy levels boosted by the weekend's rest, you're ready for the push towards the iteration review on Tuesday.
Compare this to approaching the iteration review on Friday with depleted energy levels because you've worked a contiguous week on the iteration without a break. And then having to work late on Friday to get the iteration done. There's a good chance you'll be too exhausted to enjoy your Saturday.
I know which I prefer. I like starting iterations on Wednesdays.
Tags:
extreme programming,
iteration
Links to this post
Chartering
As part of a recent
Iteration zero I facilitated a chartering session.
A chartering session helps a team understand the parameters of its work and its context within the project, preparing them to make well-informed decisions going forward. To begin understanding the project, the team identifies any assumptions and constraints and maps out the project community, highlighting the key stakeholders. By identifying the value the project will deliver to the business, the team can develop trust and confidence that the project is needed. Creating a charter provides an opportunity for the team to begin demonstrating self-organisation by articulating a shared project vision, defining their criteria for success (try using
Remember the Future, an innovation game from
Enthiosys, to include the customer's definitions of success relating to the business value to be delivered by the project), and agreeing the working practices to be used.
I can't share most of the charter information because of client-confidentiality, but I can outline the agreed working practices adopted by the team.
WORKING PRACTICES
The working practices the team were to use in the project were agreed by
consensus.
workingpractices
Originally uploaded by sjb140470.Planning and Estimation1. The development team will estimate stories in Ideal Pair Days (the uninterrupted elapsed time that excludes meetings/sickness/days-off and does not include buffering). It is understood by the whole team that Ideal Pair Days are not equivalent to Man-Days. Estimates for stories include time for functional testing to be completed within the iteration.
2. The whole team will collaborate to evolve stories as they approach being planned into the next iteration. Over time, stories will be progressively split into smaller stories with a narrower functional focus. The stories planned into the next iteration will take between 1 and 2 Ideal Pair Days to complete.
3. The development team will use just-in-time tasking to manage the work to complete a story.
4. For a story to be considered done (complete, ready for deployment to production and therefore counted in the team's velocity), the code should compile, have a simple design with the fewest classes, be well factored, have no duplication, be clean, structured to the
Sun Java coding conventions, be self-documenting, communicate the programmer's intentions, be checked into the version control repository, be integrated and build successfully. All the unit tests should pass with a code coverage >85%. All the acceptance tests should pass. The story's implementation should be checked by a UI designer, the test team and the customer. It is understood by the whole team that this should be accomplished within an iteration.
Tracking Progress1. The development team's progress in terms of expended effort and remaining effort will be tracked on a big visible
burndown chart.
2. The number of
running tested stories will be tracked on a
big visible chart.
Test-Driven Development1. The development team will write automated acceptance tests before writing implementation code.
FIT will be used to directly test the business logic.
Selenium will be used to test the UI (and the business logic indirectly).
2. The development team will write
JUnit tests before writing Java implementation code.
3. The development team will write
JSUnit tests before writing Javascript implementation code.
4. When a defect is located, the development team will write
JUnit (and
JSUnit) tests to reproduce the defect before fixing it.
Continuous Integration1. The development team will integrate working code often, no longer than every 2 hours.
2. The development team will not tolerate broken builds. If the build is broken the team should refocus to fix the build immediately.
3. The development team will not check-in new code if the automated build is broken.
Coding1. Developers will write all production code using pair programming.
2. Developers will write all production code to the
Sun Java coding conventions.
3. The whole team owns all of the code.
4. The development team will use the code and tests as the primary source of any documentation to be produced.
Iterative and Incremental Development
1. The development team will deploy a new release of production-quality software to the DEMO/UAT environment every 4 weeks.
2. The development team will work to a weekly iteration cycle starting on a Wednesday and concluding on the following Tuesday. The completed stories will be deployed to the DEV environment at the end of the iteration.
Tags:
chartering
Links to this post
I'm burning up
Some time back I talked about
keeping progress visible using
burn-down and burn-up charts. At the time I said:
I can't decide whether I prefer the burn-up or the burn-down chart ... I think the burn-down chart is more emotionally powerful because reaching zero has special significance for me, motivating me to push ahead and complete my work.
Almost a year on, I've decided to switch to the burn-up chart. I still feel that, psychologically, the burn-down chart and working your way down to zero is more powerful than working your way up to 100% done. But I got fed up of redrawing the chart to shift the x-axis down every time the number of story points in the iteration changed. It's easy to do this in a spreadsheet, but I don't like creating
big visible charts electronically.
In the current project, we're drawing our two charts - burn-up chart and
running tested stories chart - on a whiteboard with a grid background.
burnupandrtf
Originally uploaded by sjb140470.These charts are big, visibile and easy to update. The blue and green magnets identify 100% done in pair days and
running tested stories, respectively.
Tags:
burn-up chart,
extreme programming
Links to this post
