1:00 PM Sunday Room: 1401Agile development teams need to be able to provide estimates for User Stories in reasonable amounts of time. Estimation sessions sometimes become lengthy because team members want to delve into the details of each story before they are comfortable enough to "commit" to a numeric estimate.<br/><br/>
The Team Estimation Game offers a collaborative way for teams to quickly estimate user stories using relative story complexity. This isn't Planning Poker, but an alternative which can help teams get past a common stumbling block in estimation, namely attaching too much significance to the numbers.<br/><br/>
In this highly interactive workshop, attendees self-organize into teams of from 3 to 6 members each. After a brief description of the rules of the Game, each team is given a stack of pre-written story cards that represent the features of a fictitious software product. Their job is to collaboratively estimate all stories in the stack.<br/><br/>
After attending this session, participants will be able to use the techniques learned to estimate their own, actual user stories with their own teams.
11:00 AM Saturday Room: 4301If everyone on an Agile development team works at his or her top capacity, does that guarantee maximum throughput? Let's find out.<br/><br/>
In this interactive, hands-on workshop we'll discover how to optimize the effectiveness of the team as a whole. We'll work together to simulate a manufacturing assembly line under various conditions and measure our results to see what works best.<br/><br/>
We'll also discover and discuss how the assembly-line analogy applies to software development, and how slowing down certain portions of the development process can have a direct, positive impact on the bottom line.<br/><br/>
2:30 PM Saturday Room: 4218In software development there are many ways to transfer the knowledge about how to build a product to the people who do the actual building. Production can be severely hampered, however, if that knowledge is being produced more rapidly than it can be consumed. This is the <b>knowledge transfer bottleneck</b>.<br/><br/>
In this hands-on workshop, participants experience three different ways of transferring knowledge in a production environment. The product, in this case, is a paper airplane of unusual design. The idea is to try different ways of transferring the knowledge about how to build the airplane from the “chief designer” to the production workers, and to compare the relative productivity of the different methods.<br/><br/>
This session is designed to help you discover and avoid the knowledge transfer bottlenecks in your own development process.
9:15 AM Sunday Room: 3106Pair Programming is often talked about, but probably not put into practice as much as it could be. Why? It's a difficult skill to master, and often tedious because both members of the pair want to have the keyboard more than half of the time.<br/><br/>
Test Driven Development (TDD) is also a difficult skill to acquire, perhaps because it seems easier to "just go ahead and write the code."<br/><br/>
This session illustrates the basics of both Pair Programming and TDD by demonstrating the development of a sample application from the ground up, following the rules of the Pair Programming TDD Game, originally developed by Brad Wilson and Peter Provost of Microsoft Corporation.<br/><br/>
The game goes beyond the more well-known "ping-pong", and is a fun way to keep both members of a pair engaged. After this session, you'll want to play the game with your own team.