I have been running a few Agile courses lately and a common issue seems to be coming up.
In our training we generally assume that students want to use agile principles for good
- Better quality outcomes,
- Listening to the customer more
- Less team stress etc.
But most of the techniques are also very effective for propagating evil with only a little tweaking. So you would think there would be a lot of training and reading material available for the evil agilist.
Sadly, when asked for advice from students about where to find useful tips for the spreading of evil, I am at a loss. And I am therefore going to publish a series of articles to redress this imbalance.
The starting point for any aspiring doer of evil should be the assumptions in the Agile principles and manifesto themselves. With only a little work, it is easy to apply all the myriad technical approaches and processes in a good way, while very quickly spreading suffering and mayhem around the team with only a few minor tweaks of the values.
Lets take, for our first article, the idea of “sustainable pace”. We all know that we are more effective when awake, so leaving the team working too many hours can be seen to quickly spread some level of damage. But many young evil-doers vastly underestimate the opportunity here.
In a waterfall project, there is a familiar peak and trough, so that while we can burn people out for a while, a large “release” generally occurs and then leaves them with a break in pressure before the panic can begin again. Projects often call delivery dates releases or drop dates to subconsciously remind themselves that it represents a feeling of release or a drop in the crushing pressure coming up to the release date.
But in agile projects we do away with the peak and trough. So we will have a consistent level of pressure and speed. This means that you can easily fool your enthusiastic young developers into starting at a pace that would be sustainable on a waterfall project – and then keeping on running at that pace until they collapse.
And the best part is that the team will blame themselves. In the old days, teams could blame the PM for being a dictator. But in Agile we train our PMs to use social pressure and empowerment to rule their domains instead of dictatorship.
While this takes a little more effort to get working, it means that the team themselves will often enforce their social contract on each other – typically by making jokes or staring at people who dare to leave before 7pm on the “critical phase of the project”.
While this practice is common among experienced evil-doers, it seems to be relatively unknown among the less experienced “evil grommets” – so give it a try on your next Agile project. You will find it easier to do than you would have thought possible.
Simply get people passionate, ask too much from them and then completely fail to step in as they do too much. They will burn out and start rolling out dud products even more quickly than on a waterfall project – even while you demand every other aspect and process of Agile techniques is adhered to.