Pages

Wednesday, July 8, 2009

truly agile projects that aren't named agile

I watched Apollo 13 this weekend with my family. It was amazing to watch how the normally staid, by-the-book operations at Flight Control moved into a smoothly humming agile team, with the flight director (was it Kraft at the time? I forget) coordinating all the efforts. He wasn't quite a scrum master - he owned more than just the process - but he managed the process very smoothly. The movie didn't show distinct agile events either (retro, stand-up, demo). These were all included in the ad hoc meetings. Great, the carbon dioxide's been reduced (retro moment), now in order to adjust the re-entry angle, what can we do (story gathering)? Who can do that (task assignment)?

Studying the stories of potential failures turned into great successes can give us a lot of insight into how we can manage projects on a regular basis, when death isn't on the line (hmm... that's a Princess Bride quote. I think that might require another post).

Sunday, June 21, 2009

Developers are like children...

I've often thought about the care and feeding of developers. It's not much different than the care and feeding of children:
  • Provide structure.
  • Encourage independence.
  • Encourage growth.
  • The list goes on...
While I know that children and developers both need love, and while I care dearly for the developers in my care, I do have to draw the line somewhere... And while I said "feeding" above, it's just a metaphor, okay? I'm not going to feed the whole development team every day! I already feed my kids... (Rhetorical question - who eats more pizza, a developer at a release or a 15-year-old boy?).

Agile development environments go a long way to help with the well-being of a team.

There is a basic structure that provides routine to the developers' time. Plan, develop / work, evaluate, repeat. This routine provides a structure for everything else. As a developer, I appreciate when I know that a release will occur every 15 business days, or that a planning session is scheduled for next Monday, so I should make my dentist appointment for Tuesday. I know (generally) what to expect when I come into work.

This structure, this sameness, provides a framework for the "scary" stuff - like trying to figure out what the customer really wants. Or how to save a binary stream into an image file. Or how to set up a data structure that the DBA will like, but that won't require 20 joins in every query.

The self-organizing part of agile encourages independence. As a ScrumMaster, I can be there to get obstacles out of the way, but the developers have the responsibility for determining what needs to be done, and for doing it (follow-through - big issue with teens as well).

Likewise, self-organizing encourages each developer to take the lead when they are able to. This allows them to play with leadership without leaving the security of their current job. It allows for some stretching in learning other areas of development too. If an agile team is well-cultivated, there will always be more than one expert. And if one expert leaves, another will have to jump into that role.