I once posted that in an agile sense it seems like We Can Never Go Fast Enough. Going fast means we need to have quick reflexes; the ability to adjust. This in turn relies upon feedback. Some information that quickly lets us know how we are doing and allows us to steer back on course. If someone is YELLING, then it’s our ears. Very often, however, it is our eyes that tell us. It is why we lean so heavily on information radiators and large visual displays.
There has been a growing trend for a while now in pursuing ever faster feedback mechanisms; often named Extreme Feedback.
The Extreme isn’t so bad. Not as in some reality show which uses shock collars when something gets broken, but rather in the ability to very quickly ascertain information.
1) Where the code is
2) What State the code is in
3) If Something undesired actually happens – Signal for help!
Whether it’s a bunny from Nabaztag or an Arduino (Uno or Mega) with some LED’s like this starter kit – these indicators can be tied into a build process and let the entire team know what is happening. Collocated or distributed, these devices are fun ways to immediately inform the team about what is going on.
I might choose the bunny because Easter is almost here! I might choose an Arduino because I am tired of Hidden Easter Eggs!
From the Quality side of things, I always disliked very long processes that went on and didn’t have any verification until a dozen or more changes were involved. Let alone another dozen processes had already been gone through. It was even worse, if like in waterfall, the next stage was the verification of several months of work. Extreme feedback pushes into the small changes that the build is compiling and does a great job of simply making everyone aware. Quality in the moment. Devices like this can be tied into deployments, and even into Test results. What about some aggregated sprint or release results? Granted the feedback on a release is going in the BIGGER direction – but the automated indicator of a 😦 *sad* bunny is impetus enough to rouse ourselves to action and address the problem. In a fun way of course.
If the team has a budget (and I often think it should), this might be a great, fun, and motivating project to help the team to get ‘to good’ as soon as something goes wrong. In TDD (Test Driven Development) terms “getting back into the green”. A passing state, and out from the red, broken state, as soon as possible. The term leverages from the eXtreme Programming or XP Practices that Kent Beck championed.
Have fun if your team decides to use one. Let us know how creative you were.