I am of the belief that more prescriptive your are about doing something, the less faith you tend to have that someone (other than yourself, natch) will do the task correctly. Prescriptiveness is a precursor to micromanagement, and is often an indicator of low levels of trust. If you join a team where someone is telling you how to do something, and then speaking on your behalf as you move through the work, what’s the value of you? It turns out that micromanagement’s toxicity can expand far beyond the annoyance of being told how to do something.
In my entire career, I don’t think I’ve ever worked with a full team of new-to-the-job developers, Product Managers, or UX designers. The teams with new comers to the field have often been structured appropriately such that mentorship and knowledge sharing can occur between junior talent and experienced talent. It’s not always a perfect balance, but there’s never been a team I’ve met that doesn’t have collective decades of experience under their belt. The majority of folks I’ve had the pleasure of working with are often very good at their jobs, and are excited to support others just beginning their careers.
This is a long way of saying: I’ve never worked on a team that needs to be micromanaged. And yet, I’ve certainly met a number of stakeholders, middle managers, and “Leaders” that feel the need to tell teams what to do, and how to do it. Strange, and a bit counter-productive, given how toxic micromanagement can become.
It’s easy, of course, to blame poor leadership and middle management for this behavior. They’re always the villains, right? But lately I’ve noticed that many Agile tools and frameworks exhibit the same prescriptiveness, replete with a “Do this, not that” rulebook. The irony is, well, have you read the Agile Manifesto lately?
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
https://agilemanifesto.org
(When’s the last time you read that, eh?)
So if the Manifesto helps define the core of Agile values, what’s up with all the frameworks, tools, and trainers dictating exactly how to execute an org-wide Agile rollout, or run an Agile ceremony event? Obviously the biggest offender here is Scaled Agile, which has flooded the market with certifications, templates, and how-to documents that mostly have gone nowhere (find me an org adhering to SAFe 100%. I’ll wait.) But there are others.
Tools like Jira also make it difficult to talk about Agile values, because the tool demands data and numbers and content to be useful, instead of enabling conversations that empower teams to make good decisions for their users. Admittedly, the tools capabilities don’t condemn it entirely – the users of the tool (in this case Jira) can customize and leverage it as needed, but how have those folks been coached on the what and why?
Which brings me to the people aspect of all of this: Trainers, hiring managers, HR teams, team members. In my opinion, trainers get too prescriptive, because the tests for certifications are too prescriptive. There’s an entire industry that mints money creating certifications out of whole cloth, but the value of Agile is lost in most of these, and it’s damaging the wider Agile community.
For example, if you’re looking for a Scrum Master role, take a gander through the jobs listings on LinkedIn. The JD is the same for many – copy and pasted from Scrum.org, or worse, SAFe. There is not deep thought about what a Scrum Master should do for a specific team, or what particular skills a Scrum Master in this company may employ. With a JD like that, you’ll get all sorts of candidates, many of which are unqualified because the hiring manager “isn’t quite finding what we’re looking for.” Garbage in, garbage out. HR Teams feel the brunt of this the most, and though there’s a wider push for HR teams to be more agile themselves, the fundamentals and values of Agile are lost on many doing the actual hiring.
So how does this manifest itself at the team level? It invites risk, which ultimately slows down value delivery. Scrum Master in over their heads or underprepared for the true role? Things will slow down. Team members expecting one way of working only to find they’re forced to do something else? More slowing down. Above all, these sorts of mismatches give Agile – and organization agility – a bad name. How often have your heard “oh we tried that before, it didn’t work.”? It’s just more to unwind and rebuild, which, you guessed it, leads to a slow down.
It doesn’t have to be this way. I encourage any one in the Agile space to consider the ramifications of prescriptive frameworks, or changing processes to align with tools. We can allow more self-organization, greater ownership, all while enabling accountability and transparency. We can use tools for specific purposes, and chose other tools for other purposes. We have agency here, and we should use it to deliver value, not outcomes.
Goscin.ski 