Scrum & Agile

Having sat through Mike Cohn's Certified ScrumMaster course earlier this week, the connection between Scrum and agile has finally become very clear. But what I observed in the class has surprised me, even though, it really shouldn't have.

I saw a lot of people still looking for the silver bullet (and if Scrum ain't it, they are more than ready - eager - to write it off as a piece of hyped up crap). What they expect coming out of training is a set of rigid rules to take back to their companies, rules to follow unquestionably to magically transform their dysfunctional environments into well oiled and efficient software producing machines. No, I'm sorry, can't do, doesn't work that way. Scrum cannot be boiled down to rules. If it could, it wouldn't work for the very simple reason that every environment is different. Every company has a unique culture, unique business model with unique requirements, unique bunch of people working together, communicating in unique and unpredictable ways.

You can't round all of that into a square hole and still expect things to work. Instead Scrum is a set of guidelines evolved within a small circle of developers when they tried to follow the principles outlined in the Agile Manifesto. They looked at those principles and experimented. What worked for them, got distilled into a set of guidelines they called Scrum.

These guidelines are nothing more than starting points for a team wishing to become agile. A pseudo-authoritative reference to take to one's boss or the team and say, here are the things that worked well for others, let's try adapting them here (compare this with saying, let's go agile, here are the general principle of agile development; the natural question is "sounds great, so what exactly do we go from principles to implementing them?"). Once you have the buy-in from the management and the team (not an easy feat in itself), next comes the hard part: making your process agile in a way that works for your team in your company.

Scrum is not going to dictate you how to do this. Remember, it's just a bunch of starting point guidelines. You need to run with them experimenting, adjusting and tweaking in a way that fits your organization. How do you know how to change them? You need to be constantly looking back at the agile principles and asking yourself a question: what do I need to do in order to maximize on every principle without breaking others?

In the end, it's a thinking's man game... as always.