Agile2007 Day 2

The Absolute Worst Keynote at a Technical Conference. Ever.

Today’s keynote was the the longest 90 minutes in my recent memory.  That’s 1.5 hours of my life I will never get back. The keynote address for the Agile 2007 conference was given by Susan Ershler who spent my precious 90 minutes saying things like, “Rah, rah” and “You can do it” and sounding like a weak imitation of the already sad Tony Robbins. I am surprised she wasn’t wearing a head mike, although she did have the podium removed for her shtick.

In a community this diverse and full of rock star geeks they couldn’t find someone who wasn’t trying to hawk their book about climbing Mount Everest? (That was serious, BTW) There are enough opportunities to get cheese from the snack bars during the breaks without serving that much of it for breakfast. I am sorely disappointed in whoever thought she was a good idea.

‘Nuff said. But, yuck.

Session: Agile Developer Practices for Dynamic Languages

In this excellent session, Paul King did an amazing job of touring us through some fundamental differences between static and dynamic languages. He clearly groks his subject matter and was able to represent reasonable arguments for static typing goodness. What was that? Ruby doesn’t save the world? Well, it may have when it was Perl back in 1990, but that’s another story :D.

Long story short, some really cool basic patterns we implement in static languages are rolled into dynamic languages. Things like mocking may be accomplished with additional frameworks wince we have code injection baked right in. Weird. Conversely, how can you test for all conditions when you are not testing to an interface or concrete implementation? If I know that my object may change at runtime, how can I be assured I have tested it’s functionality? Again, I cannot. Again, weird.

Although I have done HelloWorld in Ruby, I don’t know much about dynamic languages yet. I intend to focus on learning one soon to truly grok the idea as I am told I must or die.

Session: Lean and Agile In the Large – Principles, Practices and Experiences for Large Scale Software Development

Gosh, that was a mouthful. Dave Thomas is a dynamic speaker and this session was thoroughly enjoyable. Speaking to the already converted, this was an intermediate course focusing on pearls of wisdom Dave learns in his work with Object Mentor in scaling Agile practices to very large implementations.

Here are some of Dave’s nuggets:

• 10% of your project time should be spent figuring out what you really want. This can be termed an “Envisioning Phase”. This is the result of prototyping in a set of iterations.
• Only metrics provide transparency across the organization. Publish your metrics loudly and publicly.
• The whole point of Agile is to make project management everyone’s responsibility.
• Things only go bad one day at a time. You can stop a bad smell at any time.
• All work items, including training, go in the backlog.
• If you aren’t prototyping, you aren’t iterating. You must be willing to throw code away in order to foster learning. This is the heart of fail often to succeed.
• Product Management is useless without perfect backlogs. User personas are great, clarity of desirements is better.
• Concrete architectures are code, not instructional documents. A reasonable way to derive the code is with models, which should be versioned as code.
• Customers don’t buy components, they buy features. This matters because a feature often must expand beyond the bounds of a prescribed component boundary and work across an entire framework.
• Use planning poker, make management learn what it means.
• Non-code artifacts belong in a Wiki or something like it. Along with code, your build process should tie code to a non-code artifact version as well. Ensure you can version your WIki as part of your build.
• If you don’t have good executive leadership it doesn’t matter what you are doing, you are screwed.

Session: Agile adoption at Google

Mark Striebeck uses his 20% time to foster Agile adoption at Google. In his session he discussed how this has worked.

• At Google, employees are encouraged to attend at least one Tech. Talk a day, getting up and away from their workstation.
• Grouplets at Google are the same as Communities of Interest and are made of volunteers. These groups are described as “Engineers making other engineer’s lives better.” Grouplets have a budget plus administrative support as needed.  Once per year, there is a Grouplet open house in which Grouplets try to recruit new members. This may be what people do in their 20% time.
• Fix-It! is a one day event involving the entire company around one goal, usually fostered by a Grouplet. This is a rare, maybe once per quarter event, the motto for which is “Imagine what 5000 engineers can do in one day!”
• The one rule at Google for development is that everything checked in to source control repository must be reviewed by at least one person.
• “Google is the left side of the Agile Manifesto”
• 2-3 engineers make a development team.
• Very different practices for different projects.
• People love tools, let them use their favorites. Wiki for the backlog? Fine.
  • What is the mechanism for communicating across the entire enterprise?
• Teams get an audience with a VP and say “look what we made”. That’s how things get attention for market consideration.
• Pairing not particularly favored
• How do you keep people from duplicating work? We don’t. It happens. People of similar concerns usually know of each other through Grouplets.
• Google does not worry about sustainable pace. They hire people who voluntarily work crushing hours anyway.
• I work at Google and we rock harder than you. Seriously.

Technorati tags: Agile, Agile2007, Agile Architecture, Google, Ruby, Groovy