I first noticed this practice in action when attempting to contribute to the Project Management SE site. Spend time there reading answers to questions around “agile” and “scrum” and you’ll quickly notice something: the main contributors have a fixed mindset on what the terms mean. Deviate from that and you are accused of being wrong. Do as I did, and remind people that a central tenet of the agile manifesto is “people before processes”, and you’ll be accused of “cherry picking” from the agile manifesto and will get downvoted!
I’m even guilty of this behaviour, myself. I started a new job some six months ago. I now lead a small team that predominantly writes small programs, that only take a few days to complete. We minimise the amount of paperwork around each request, we liaise closely with the customer (other parts of the business) and we readily change our priorities based on what’s most urgently needed. Further, because the company I work for is a financial business with many critical IT systems that effectively stop the business working if they fail, most of IT is regulated via very strict processes. Because of the way my team works though, we have our own processes that only touch on vital parts of the main IT processes. In other words we are free to adjust how we do things to meet the business needs. What I’ve done here is describe the four key points of the agile manifesto. Despite this, one of the first things I did upon starting was to look at how we could use scrum, so we could become agile! Our working methods have plenty of room for improvement and can and will change over time. However, me forcing scrum on the rest of the team would achieve nothing other than to restrict how they work: it would make them less agile.
All too often, because agile methods differ so strikingly from traditional “waterfall” development methods, the company needs management support to transition to agile working practices. Sadly, this all too often gets translated into “we must define a set of agile processes and strictly enforce them to make us agile”. This isn’t being agile, yet many seem to believe that’s exactly what’s meant by being a “strict agile company”.
If you stick rigidly to some “official” set of processes around scrum, or other agile methodology, and insist that anyone deviating from that “isn’t doing it right”, then you may be:
- valuing “working software over comprehensive documentation”;
- putting “customer collaboration over contract negotiation”;
- and you may be “responding to change over following a plan”.
However, you are not putting “individuals and interactions over processes and tools” and so you are not being agile. We seem to be slowly killing the agile movement by insisting there are fixed, right ways to “do agile” and that, anyone deviating from those proscribed processes isn’t “being agile”. It is a bitter irony that the process-lovers are destroying the ideals of agile by claiming it’s not agile enough!
So the next time someone claims you aren’t “doing agile properly”, remind them of “individuals and interactions over processes and tools” and help keep the agile movement, agile (but expect to be down-voted if you do this on a project management Q&A board!)
(The image used in this post is from www.pd4pic.com)