Thursday, April 2, 2009

Agile Feedback Loops

One of the most important aspects of Agile is the feedback loop contained in virtually every aspect of the methodology and the built-in efficiencies related to it. I know I'm being Master of the Obvious, but knowing about a problem immediately and thus fixing it immediately is so much easier and manageable than untangling many problems that were unknowingly compiled over the course of months and with a short amount of time to straighten everything out. Aggghh .. it's stressful just thinking about it. Below are the places in the Agile methodology (or at least the way I have implemented it) where we see feedback loops.

Continuous Integration (CI)
When code is checked in, the application will successfully build or it will not. On my team, we get automated emails after the CI process runs regardless of success or failure so feedback is received in both positive and negative outcomes. The rule is - don't leave for the day until your checked-in code successfully builds and the unit tests succeed. When the CI process fails, it is the top priority of the team to fix it.

Nightly Build and Deploy
Every night the projects that make up the application are built and deployed to a distributed environment. During this process the compilation, automated unit tests and automated QA tests should succeed. If anyone of those processes has a failure, then, just like with the CI process, it is the top priority of the team to fix the failure.

Daily Stand-up
Every day the project team meets for 15 minutes where each member tells the their team members what they worked on yesterday, what they are working on today, and what obstacles they have. As a result, missteps in priorities is only a day away from being corrected and information about what someone else is working on that is pertinent to a developer is communicated every morning.

Sprint Retrospective
At the end of every two week sprint, the team discusses what they think went well and what went not so well. This feedback provides the necessary information to tweak our processes accordingly. Little by little our processes gets stronger.

End of Sprint Demo
This is where the rubber meets the road. At the end of every two week sprint we have an immovable demo to the client. What does our customer think about our work? Did we get it right or wrong or a combination? What insight is gained about the application as a whole as a result of this sprint's development and what is the effect on the priorities for future development?

I was in a client demo yesterday for Sprint 12 - thus it was my 12th demo for this particular project with 4 more to go - when I had a somewhat out-of-body experience. As we were nearing the end of the demo where I was peppered with questions by a room of 10+ client stakeholders asking "will it do this? will it do that" of which my response was "well let's see" (and in virtually all cases the app performed well), I mentally became detached from the demo process and saw the entire project life cycle in my minds eye and was stunned.

That's when I said to the group "Can you believe how well this is working? This is amazing." And, that's when they started making fun of me by asking me if I wanted to be carried around the room. By the way, having a demo every two weeks with your customer promotes a positive bonding experience (assuming the demos are successful).

The reason for my impulsive utterance was that after developing software for the better part of the last 15 years (a lot of which was not using Agile), I'm still stunned how well Agile works. Of course you need high quality developers too but the constant feedback loops and addressing issues immediately instead of during UAT is directly related to successfully demo-ing an application 12 times with minimal glitches.

2 comments:

  1. Re: Daily stand-up. Let's assume you have 8 people in your team. The daily 15 minute standup is equal to 2 full person hours (that is assuming members of your team can magically switch from coding to standup and back with no time wasted on switching). So in every 4 days your team spends an entire person day on standups. Are you sure your standups help you find a full day worth of "missteps in priorities" every 4 days?

    ReplyDelete
  2. Just as continuous integration allows you to unravel immediate incompatibilities as soon as they occur, daily stand-ups allows each one of us to make sure that missteps are found immediately. Unfortunately there is no automated way of performing the equivalent of continuous integration on humans thus we need to do it manually.

    To answer your question directly, the answer is yes. As you know as a developer yourself, 8 hrs is nothing when it comes to lost time because of a misunderstanding, misplaced initiative, or any of the other many reasons where days of working without interaction with the team can cause in lost time.

    Take this situation for example. Someone is assigned a set of related tasks on Monday. Friday afternoon at the project status meeting when it is described what each developer is working on it isn't unreasonable that one of them says "that's not what I thought you meant by that." There goes 40 hours plus whatever time it takes to undo the mistake and the dependencies that other developers have coded to accommodate for the 40 hour mistake. And, that's when there's a weekly status meeting that all developers attend.

    ReplyDelete

Web Analytics