Agile Exhaustion

August 28, 2008

OK, I admit it, I’ve had enough Agile proselytizing for a while. Agile 2008 was fun, but I’m bushed. And no, I really don’t want to talk about Agile anything right now. I’m going to go play with my kids…

Agile 2008 – Day 5

August 8, 2008

It’s all over now. Thank goodness, because I’m exhausted. This was my first Agile 200X conference and it was well worth going to. I had a good time doing my presentations, and I even managed to sit in on other folks presentations from time to time. It gave me a few ideas to take back home. A quick sampling of those ideas includes:

  1. Never flip the bozo bit
  2. Try to use goals more aggressively to help find impediments
  3. Try more techniques for introducing “practice” and “play” into projects
  4. Try out a few more disciplined techniques for retrospectives
  5. Try measuring the scrum master metric – how many impediments are removed per day?
  6. Refocus on testing to improve story quality?

    Nothing new. Nothing revolutionary. Just a few ideas to play with in the comming months. All in all a great conference. Toronto is a fun city – with great food. The one negative note – I don’t want to stay in a Sheraton again any time soon – I feel like they scalped me every chance they got with fees and overpriced services. It was embarrassing.

    Oh well, on to next year.


    Agile 2008 – Day 4

    August 7, 2008

    Day four brought with it a few surprises. It started with a session with Gabrielle Benefield and Jeff Sutherland (and a few others less notable). As always, Jeff left me with a few insights. One was that you can’t have impediments if you don’t have a goal. No more goals for me! Or perhaps the reverse. Impediments are one of those slippery concepts that is easy to talk about, but sometimes relatively hard to identify in nature.

    In the afternoon, there was my own session with Dhaval “Swarming: The Birds and the Bees and Agile”. We totally rocked the house. People were pretty pumped up. Both Dhaval and I were really in form and we did a great job with the delivery. People told us afterward that they were super excited by the presentation.

    Now it’s Miller time. Or perhaps Labattes time since this is Toronto. I’m done with stressing out for this conference!

    Agile 2008 – Day 3

    August 6, 2008

    Got the day off to a start with a bang today – I gave my first presentation on “The Intermediate Customer Anti-Pattern” at a very early 8:30 this morning. The presentation seemed to go very well, and I was able to carry it all off with a great deal of energy and enthusiasm (which always helps). Then I caught a session with Linda Rising. Wow! It was the best session I have seen so far. She talked about the impact of stereotypes on people’s behavior. It brought me flashbacks to my undergraduate days in Psychology.

    The presentation was truly wonderful, and it caused me to question (again) the wisdom of labeling a team as “in trouble” or a “problem” team. It reinforces some terrible stereotypes from which it is very hard to escape. After that, I had lunch and then it was off to give another presentation – this time it was “The transition to Invisibility”. Again, it was a brief, but very energetic session. I was able to give it a great deal of punch and that is always a satisfying feeling. The crowds in both sessions were good to me (Thank God!).

    Tomorrow is going to be the big event for me – the swarming presentation. Dhaval and I had a beer and went over it again just one more time last night. I think it is going to be an awesome presentation.

    Agile 2008 – Day 2

    August 5, 2008

    The morning got off to a bit of a weak start. Not that there weren’t good sessions – quite the contrary, there were plenty of good ones. However I was in an adventurous mood and I ended up going to a few smaller sessions that didn’t really have much to offer. The moral of the story is: If you can’t persuade me to stay in the first 10 minutes, then I’m gone. Whoosh!

    However, the afternoon was much better. I sat in a seminar on doing team retrospectives with Esther Derby and Diana Larsen. As always, they were great. Their seminar reminded me of the fundamentals of doing a good retrospective – and retrospectives are often given too little attention by teams. In my opinion they are of equal or greater importance to the sprint planning meetings. Retrospectives are where much of the learning can take place.

    After that session, I went to sit in on a short session with Tobias Meyer. I always leave his sessions with a big smile. He is so energetic and passionate, that I always enjoy being a part of what he is doing. His 30 minute session was so full of energy that I felt like I was hyper-ventilating at the end of it. It was like sprinting around the building on a rainy day – exhausting and cleansing. Oh yeah, the topic was on creating a manifesto or declaration for keeping Agile projects focused on small things. The topic resonated very strongly with me. And Tobias did a great job showing us a few techniques for prioritizing ideas that I had never seen before.

    I was particularly pleased because the group voted my suggestion for a declaration of “smallness” as the most popular! I couldn’t believe it! It was serendipity at its finest. Here is what we finally ended up with:

    “We keep agile small because we are passionate, collaborative individuals who strive to produce simple solutions.”

    Not bad. The more projects I do, the more I crave simplicity in all its forms. I fantasize about simple projects, I dream about breaking complex issues down into simple ones. It’s probably a sign of mental illness.

    The session after Tobias’ was about questioning the role of QA in Agile projects. The presenter, a very engaging Brit, tended to wander a bit. However, he did a better job of helping explain for me how testing is not exactly oriented to agile methods. There is a lot of unresolved tension on Agile teams surrounding how testing should be done. There is a corresponding amount of emotion too. I have found integrating testers into my teams to be a daunting task at best. So this session gave me a better appreciation for why it is so challenging to work on an Agile team from a testing perspective. I’ve pushed the issue aside for too many years – it’s time I took it more seriously. Or check into a mental institution – one or the other.

    So, all in all, a very fine day 2 at Agile 2008.

    Agile 2008 – Day 1

    August 4, 2008

    Got into Toronto last night. We went out for dinner and ended up hopping between little ethnic enclaves. First it was “little China” then it was “little Portugal” and onward to “little Italy”. A little food, a little wine, a nice way to unwind after spending all day on the plane.

    Not much happened today. There were research papers that were discussed, but there really weren’t any I was all that interested in. I spent time preparing for my own presentations later in the week, slept off some of the jet lag, and generally took it easy. It’s not a bad way to start off a long conference like this with sort of a layover day. I’m getting pretty jazzed up for the conference to really get kicked off! It’s also exciting to meet folks as they drift in during the day.

    Using the Agile Cookie Cutter

    August 2, 2008

    How would you set up your next project? What would you require? I know what I’ve tried in the past – here’s a brief inventory of my standard Scrum Toolkit:

    New Artifacts:

    • Team Working Agreement
    • Team Definition of Done
    • Task Board
    • Burn down chart
    • Impediments list
    • Release Plan
    • Backlog

    New Meetings:

    • Sprint Planning
    • Daily Standup
    • Sprint Review
    • Sprint Retrospective
    • Backlog grooming

    New Concepts:

    • Stories
    • Story points
    • Sprints
    • Releases
    • TDD
    • Continuous Integration
    • Cross Functional Teams

    New Roles:

    • Team Members
    • Scrum Master
    • Product Owner

    Boy, that’s a pretty long list of stuff. Looking at it, it sort of gives a guy cause to pause and wonder just how any team could absorb all of that. I guess that explains the deer-in-the-headlights look I get sometimes when I introduce teams to Agile processes. Do you need all of that to write good software?

    This list is what I might call my “Agile Cookie Cutter”. It is the common set of ideas and practices that I try to role out with every team that I work with. But lately I’ve been thinking that slapping all this on a team all at once isn’t so smart. What I often see is teams going through the motions, adopting these practices whether or not they really need them. People get frustrated when they adopt processes wholesale and then run into problems with subsets of practices. What ever happened to gradually introducing practices and empirically testing their effectiveness?