How to effectively kill your Agile Team
Agile methodology is the glorious present and future of software development, but the correct set of circumstances can seriously cripple a team’s morale and their effectiveness.
Introduce a hierarchy
Such an innocuous thing, right? Surely a hierarchy would clarify matters — make the chain of command easier to understand for everyone involved. Besides, the team needs a leader, someone to take control and guide the technical development, to tell the others what to do and when, and the team needs someone to turn to for instructions whenever they finish a task.
This is especially effective at reducing developer morale — they don’t have much independence as it is, so taking the perceived freedom offered by an Agile development team and channelling through a specific person is an excellent buzz kill.
Ignore the rituals
Agile development encourages a lot of ritualised meetings — standups, demos, retrospectives, etcetera. They have specific purposes and agendas, they tease out different information from the team, they course-correct the development process.
You can start by eroding the team’s perception of the importance of those rituals. Skip a meeting. Cancel one at the last minute. Go off-topic, and encourage others to do the same. Mash meetings together, dilute their purpose and soon enough people will be sitting around wondering why this Agile thing isn’t delivering on its promises.
Throttle the team resource
The team can’t give 100% if you split the members across too many projects, or if their availability is erratic or unpredictable by other means.
The maximum rate of development is as fast as the developers can work, but when the rest of the project team — be they product owner, designer, scrum master, infrastructure, DevOps or QA — are unavailable it impacts on the speed with which they finish user stories and the efficiency of their work.
Subtract enough of the team’s resource on other things and you’re littering their path with potential blockers. Enough of those blockers can bring development to a standstill, or at least burn through all of the budget by way of inefficiency.
Don’t listen to their complaints
If that’s not enough on its own, try disconnecting from the team as much as possible. Assume they’ll work those issues out on their own.
They won’t, of course — if you’ve followed the steps outlined here then you’ve already robbed them of their power, and it’s merely a race against time to see whether the team is stubborn enough to hold it together long enough to get the project over the finish line, or implodes before that point.
/s
Originally published at www.psyked.co.uk on April 26, 2017.
