OpenSource Connections
Category: Conference
A couple weeks ago I went to the Agile2010 conference in Orlando, and it was a really great experience. I really enjoyed giving my talk on range estimation in Scrum, and I greatly appreciated the large turnout for the session and the great participation and questions. But the real value I got was in the other sessions I attended. I learned an awful lot during that week, and I have been slowly absorbing those lessons since returning. Im going to try and summarize a few of those lessons here. They will necessarily be brief and disjointed tidbits, but if youre interested I hope youll go find the person who gave that talk to learn more, or perhaps Ill blog in more depth about some of them later.
“Making Change Happen” with Mary Poppendieck
The key scarcity for information workers is time and energy, not as much money. Therefore if you manage your teams like volunteers and give them a challenge and a vision, they will desire leadership and not fear it. They will desire the kind of leadership that continues to provide vision and coordination, not command and control. When evaluating a team or broken process, avoid saying “Whats not working and how do we fix it?” Instead start with “What is working (perhaps against all odds), and how do we clone it?” Look for areas where the team should be failing, and yet they are succeeding despite the obstacles. They have figured something out.
Agile Planning with Mike Cohn
There was a lot of value in this session, but one concept I liked was “Commitment Driven Sprint Planning.” When you have no historical velocity for a team or a project, you should break up stories into tasks using only one story at a time. After estimating those tasks and adding them to the sprint plan, ask the developers “Can you commit to delivering this in this sprint?” If they can, then you pick another story, break it into tasks and estimate, and add it to the sprint. Again, ask the team if they can commit. Repeat this process until the team feels that they cant commit to getting any more work done reliably and with high quality in that sprint. The number of story points they took on is a predicted velocity and something you can use to plan the rest of the backlog with. This seems particularly useful when estimating development efforts for a proposal. Mike also talked about how to use ranges of low and high velocity from historical data to predict a range of sprints or scope that can be accomplished in the future. This validated some of the practices we have started using at OpenSource Connections and seem to be going well. One funny point that Mike made, and which is accurate, is that the best way to give an estimate is to stall. Stall until you know more.
Tuesday keynote by Dave Thomas
One funny (and true) point that Dave made which really stuck with me was “dont put the ass of your laptop in somebodys face during a meeting. Its about interactions between people, not computers!” His point was to make sure that you are focusing on communication with customers, and that communication is usually improved if you shut the lid of your laptop during meetings. Another takeaway I had from this talk was that the definition of a tangible user story should be a user story that is testable. He also emphasized the importance of using the back of the user story to record acceptance criteria. This is a best practice that I expect to do more of in the future.
The Agile Manager, Johanna Rothman
Strategic management sessions should be done in iterations just like sprint planning. You dont need company retreats, just plan for a half day every few weeks. Johanna also talked about the importance of decoupling individual feedback from just during annual reviews, so that you can give feedback to employees more often. She also gave a good overview of giving peer to peer feedback by following these steps: 1) Create an opening, 2) Describe the behaviors or results, 3) State the impact of those behaviors on the team, 4) Make a qrequest.
Distributed Scrum, Guido Schoonheim Distributed and offshore teams are motivated by the same things that our inhouse teams are motivated by (ie, not just money, but also autonomy, subject matter mastery, etc). Its very important when building a great distributed team to create the purpose and shared vision across the whole team, not just the inhouse part of your team. Team members on both continents need to feel equal, dont make the offshore team feel like the junior partner. For stand ups, use video cameras, make sure everyone actually stands up, and pass a microphone around so everyone can hear well. Every 6-8 weeks, have a team member rotate for a couple weeks over to the other team (in both directions), so that teams can share context and build relationships.
Testerfield, Dave Haeffner
Dave talked about a project developed internally at the Motley Fool called Testerfield, to improve automated web testing. Hes considering open sourcing the tool, and so you should go sign up at testerfield.com to encourage him to do exactly that.
Using Story Maps to Visualize your Backlog
Paul Hodgetts led a very good interactive session to help practice different ways to layout stories on a backlog. Take the roadmap a user follows through your system, draw that across the top, and then place user stories under the relevant step in that process. You can use stickers on those story cards to indicate things like “needs architect review”, “has an external dependency”, “requires a meeting”, etc. You can also lay them out in horizontal swim lanes underneath the roadmap to show what will be done in different phases of the project. Exactly how you map your backlog will vary with each company or project environment, but this session provided me with a lot of ideas for doing that with co-located teams. It can also be done in Google spreadsheets for distributed teams, though I suspect you lose some of the value in the process.
The Curious Coach
This session was really interesting, and I have been wiggling my toes ever since. Wiggling your toes in your shoes was a simple tip David Spann and Gil Broza shared about how to remind yourself to be calm and present in difficult situations or conversations. Thats just one small example, and the session highlighted many other ways to make sure that when you are coaching someone through a process change, that you maintain the values of being “Curious, Present, and Empathetic.” Coaching someone how to make the most of Agile processes is a different and more long term change effort, and a distinctly different skill set than standard training or teaching skills. It was very enlightening to think through those differences and practice them. The basic goal is to help someone figure out a solution to their challenges themselves, and not just immediately blurt out what you think the solution is. Thats a lot easier said than done, but the results are much different and longer lasting.
Theres so much more to tell you! This is not a comprehensive list of every session I went to at Agile2010, or even a list of just the best sessions I went to. But it will have to do for now. The journey to true software craftsmanship always continues, and really has no end point. Agile2010 definitely helped me further along my journey and provided many eye opening experiences. Now its time to go apply a few more lessons!
[Note: All of the photos in this blog post except for the first one came from the conference photo CD sold by Tom Poppendieck, and available at http://poppendieck.com/] 
*Arin Sime is a Senior Consultant with OpenSource Connections, specializing in Agile process consulting, Solr search, and development consulting. You can follow Arins tweets at ArinSime *