Is your process dead?

Two of the conventional criteria for exhibiting life are:

  • Adaptation
  • Response to stimuli

Together these combine into the ability to respond to outside forces.  So how do we know if your process is dead?  If your team or organization:

  • Does not elicit feedback on a regular basis
  • Cannot respond to feedback

Then your process is dead.

Eliciting feedback

In process control systems, stability is achieved by measuring output and incorporating that data back into the system.  Consider driving down a straight road.  No matter how straight you point the wheel initially, your car will eventually veer off course.

To keep straight, you make regular observations on how straight you are and make small changes.  Wait too long to make changes and you’ll likely meet the rumble strips, the shoulder, or another vehicle.

By eliciting feedback early and often, we have the information required to make small changes to correct our course.  One of the XP values is feedback, which manifests itself through the practices of testing, retrospectives, continuous integration and others.

Responding to feedback

Now that you’re making frequent observations, your engineering processes have to be tuned to be able to respond to that feedback.  If you drive an old beater car where you can only turn the wheel once a minute, making directional observations every second won’t ensure a comfortable ride.  I’ll be able to see myself driving off the cliff, but I have only two options: jump out of the car or ride it out Thelma and Louise style.

Although Scrum elicits feedback, your team will not be able to respond to that feedback unless it’s a well oiled machine.  That’s where the engineering values, principles and practices of XP come into play.  By following XP, your team can respond to the mountain of feedback Scrum introduces to the system.

If your organization is looking to adopt Scrum, keep in mind the engineering practices of XP.  Without them, you’re on a straight line to a dead process.

About Jimmy Bogard

I'm a technical architect with Headspring in Austin, TX. I focus on DDD, distributed systems, and any other acronym-centric design/architecture/methodology. I created AutoMapper and am a co-author of the ASP.NET MVC in Action books.
This entry was posted in Agile. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Jeremy Gray

    A good point on the whole, but loses its edge a bit by picking on Scrum.

    A “well oiled machine” (using XP, Scrum, or something else entirely) is a “well oiled machine”, and will solicit feedback and improve its process. This will happen regardless of which specific process it has chosen.

    A poor team (using XP, Scrum, or something else entirely) is still a poor team, and will fail to improve its process. This will happen regardless of which specific process it has chosen.

  • @Jeremy

    I wasn’t really trying to pick on Scrum, but I’ve seen some teams blow a piston as it were because they couldn’t deal with the feedback. Scrum intentionally leaves out engineering practices to leave it up to the team to decide. Some folks interpret the lack of guidance as guidance to do nothing.

    Scrum is essential in both getting buy-in and providing relevant visibility to people outside of the team. Scrum+XP as a combo is pretty tough to beat. It combines both PM and engineering agile practices.

    A good team is good because it solicits feedback, definitely agree. A team can only become good when it elicits and responds to both internal and external feedback.