Agile 2009: Day Three
Agile 2009: Day Three
Join the DZone community and get the full member experience.Join For Free
After a great first day, day three at Agile 2009 is a wrap. I have some general observations about the conference, but I’ll save those until next week to offer an overall recap. I missed out on most of Day 2 due to a pretty full meeting schedule. I was hoping Day 3 for me would begin with listening to Neal talk about Emergent Design and Evolutionary Architecture, but unfortunately I wasn’t able to make that session. I’ll have to track him down.
I started the day attending the third session of Programming with the Stars. Jeff and Joshua kickstarted today’s competition with a song that was written by Joshua titled, “50 Ways to Leave your Debugger”, which was a variation of Paul Simon’s song. Yes, they sang it. No, it wasn’t pretty. Sorry guys.
There were only three of the original six teams remaining, and each team was provided six minutes to complete their agile development task today (as compared to the three and a half minutes on day 1). It was pretty obvious that the pairs were starting to figure out the Stars competition, as they put on a much more polished performance today. For those who care about completely irrelevant statistics, there were 2 Macs and what appeared to be a Dell netbook left in the competition.
The programming topic today was story test driven development. For those not familiar with story TDD, it’s essentially starting off development with high level customer or acceptance tests instead of low level unit tests. Gerard and Ola put on a great performance and were the clear winners of the day, meaning they were granted immunity from getting cut. That brought it down to James and Kenrick versus J.B. and Llewellyn, and the initial crowd vote was close enough to require two separate recounts. Eventually James and Kenrick won out, pitting them against Gerard and Ola for the final day of competition. Some highlights of the competition include:
J.B.’s comment on their inability to finish the exercise in stating, “If we’d have done it in Ruby like we wanted, we would’ve gotten done.”
James great explanation of the home automation story he and Kenrick would be coding, along with very clear descriptions of exactly what they were doing at all times.
Gerard simulating a completely random experience when drawing their story from a stack of cards. Only later was it revealed that each card contained the same story.
The final day of competition promises to be an exciting event. Later this afternoon, I took in a session titled “Scrum and CMMI: From Good to Great - Are You Ready-Ready to be Done-Done.” I was expecting a bit more information on the relationship between Scrum and CMMI, but this session didn’t follow the title all that closely. The session thesis was pretty simple, though the numbers hard to believe, and the concept not crystal clear. By institutionalizing Scrum across all project teams, two teams within an organization were able to quadruple their productivity, and I discovered the intent of this session was to explain what they did to achieve such dramatic gains. That’s cooler than CMMI anyway, right?
Jeff Sutherland wasn’t listed as a speaker, but there were times when he hi-jacked the discussion and made some “salesy” claims about Scrum increasing productivity and decreasing time-to-market without offering a lot of insight as to how. From what I gathered though, they did this through two very simple concepts - by ensuring they were Ready to start a Sprint and were able to declare themselves Done after a Sprint. I never got a good sense of the attributes surrounding Ready, except that the team took great care in preparing the product backlog. Done was pretty easy to understand - basically all tests must pass. There were some very useful tidbits of information, which include the following:
- A key element of Done is that testing was included in the definition. Testing commenced immediately after the code was written. Any delay between coding and testing only increased the cost of the effort.
- It was imperative that the team keep the system functional, and minimize their technical debt. I’ve called this the prime directive of software development - always have a functional system. Because of this, the team had a fully integrated system at the end of every Sprint.
- The team captured the important data that was necessary to provide them the information they needed to assess their improvement. This helped ensure they were moving in the right direction.
Along with a few great hallway conversations, a good third day of the conference. Looking forward to tomorrow.
Opinions expressed by DZone contributors are their own.