Over a million developers have joined DZone.

Agile 2009: Day Three

· Agile Zone

Learn more about how DevOps teams must adopt a more agile development process, working in parallel instead of waiting on other teams to finish their components or for resources to become available, brought to you in partnership with CA Technologies.

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.

From http://techdistrict.kirkk.com

Discover the warning signs of DevOps Dysfunction and learn how to get back on the right track, brought to you in partnership with CA Technologies.

Topics:

The best of DZone straight to your inbox.

SEE AN EXAMPLE
Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.
Subscribe

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}