Topic: Feedback Loop

Agile Fundamentals: The Feedback Loop

Dietrich Kappe, Tuesday, June 23, 2009 @ 2:28 pm

When you improve a little each day, eventually big things occur. -- John Wooden

photo credit: mister b 1138

A few weeks ago I had a discussion with some colleagues on the adoption of Agile within large corporations. The consensus was that Agile was almost always adapted rather than adopted -- that is, companies exclude those practices that conflict with corporate culture, modify those that seem too impractical or wasteful, and sometimes substitute those internal practices that seem a decent and familiar substitute.

Various schools of Agile thought have different reactions to this adaptation, all negative. The XP folks particularly don't like it.

These [thirteen] practices support one another...and thus care should be taken when modifying any of them, or deciding not to include one or more of these practices in a project.

I agree that it definitely helps to follow a particular Agile approach closely in the beginning. Once you have the basics down, you can start to improvise. But it helps knowing the fundamental principle which, in my opinion, underlies all of the agile practices, no matter what the flavor. So, the first three commandments of Agile software development are:

1. Feedback loop
2. Feedback loop
3. Feedback loop

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (2)

Software Development

Agile Software Development and the Lazy Client Trap

Dietrich Kappe, Wednesday, December 24, 2008 @ 2:03 pm

Agile Software development is all about the feedback loop. Do a little bit of something, get a little bit of feedback, change what you are doing if the feedback tells you so. There's all sorts of feedback loops in a typical agile development process, from the automated, like TDD and continuous integration, to the biological, like user testing. If one of these loops breaks down, you are in for trouble.

Which is the biggest problem? No question: the lazy stakeholder or client. By lazy, I mean those unwilling to participate in evaluating the software after every iteration. The ideal client with install the software in their environment (web or desktop), kick the tires, try to do their jobs with it, do some informal user testing with colleagues or friends. Bug reports and tweaks will flood in (you do have a defect tracking system, don't you?) and be scheduled for future iterations. More serious problems, such as a wrong or missing business requirement, will also be caught early this way. Early means cheaper. Early means better.

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (3)

Software Development