Use Constant Feedback to Improve Your Process

What's the best way to use tools like continuous integration or 6th Sensor Analytics? Should we see a problem and hit developers over the head? Scream and run around? Or force developers to follow a rigid set of steps to "guarantee" success? (Herd those cats!)

Much of Agile is about being flexible. It's about getting feedback and adjusting your daily practices to match. This is why so many people have rejected the idea of universal best practices completely.

Why does 6th Sense collect information about what a developer does all day long? Why do we watch code commits and feature flux? I heard a great quote from our CTO Todd Olsen.

"I believe that constant feedback is better to guide teams than trying to fit them to a prescribed set of steps."

How often do you gather and incorporate feedback? Or, to put it another way, how long do you steer a car without turning the wheel? Are you constantly adjusting? Or are you trying (in vain) to steer the team in a straight line while the road turns out from under you? Do you watch the road and turn before the curve? Or do you wait for your team to hit the ditch, then turn the wheel? Here's a quick hint: the best time to get your car out of the ditch is before it's in the ditch.

Gather everything you can. Especially when the team is remote, but even when they're local. As long as the data can be collected easily, without interfering with your team, grab it all. Then use it. Understand where are you are and where you're going. Make it available to the individual as well as the team lead. (Be transparent.)

Then you'll be able to adjust your aim, your process, and your odds for success.

Related Tags: , , ,

One Comment

davetron5000 ( 2008.24.04 12:52 pm )

I agree with this sentiment. A simple way to initiate this culture into any project is to have senior developers read and comment on the commits made to the source code repository (my blog entry on how I’ve done it).

With very slight procedural adjustment to the team organization (that are largely still within the black box developers typically work in) can be done by creating a hierarchy of people who accept or reject changes to the source (i.e. the way Linux Kernel development is done). My description here

Comments

You must be logged in to post a comment.

Blog Members

Previous Post:
New Reports Available

Next Post:
JIRA and 6th Sense Integration: A Webcast with Michael Cote