This is a condition we like to call Toolitis.
Once again it involves someone in a leadership position not knowing what “Agile” means. The very first value in the Agile Manifesto is “Individuals and Interactions over Processes and Tools”. If you think paying money for a piece of software makes you agile, guess again. It doesn’t make the company agile, nimble or able to pivot at all. It also does not show any trust or empowerment of the people doing the work. In fact, other software the company already uses can do the same things . Most Agile approaches such as Scrum, eXtreme Programming and others are about empowering the people *doing* the work to come up with the best possible process to deliver that work.
When Toolitis sets in, the people doing the work are not empowered. Quite the opposite. The “Agile” software tools dictate processes to people. They start using phrases such as “This is the way [insert tool name here] makes us do things. That's the opposite of individuals and interactions, the opposite of empowering and the opposite of a team of people owning their own process.
Because they use someone else’s idea of an agile process, it’s no wonder people in organizations don’t buy in or even say “I hate Agile” or “I hate Scrum”. The reality is that what the organization is imposing on them is anything but Agile and isn’t Scrum.
Tools try to be all things to all people.
They often misuse vocabulary terms from frameworks considered Agile. Besides confusing people, they lead to various anti-patterns that don't enable the organization to deliver to customers any faster or cheaper than Waterfall or Project Management did.
One example of this is the term Backlog. The Backlog is a generic term in the Scrum framework. A Product Backlog owned by the Product Owner represents items that deliver business value. There is a Sprint Backlog owned by the Development Team. Both have very different functions. What’s intended at Sprint Planning is for the Development Team to pull items agreed to with the Product Owner off of the Product Backlog and to break those items down into “how” to do the technical solution in units of 1 day or less. Why units of 1 day or less? Scrum is about Daily transparency with an opportunity Daily to adapt. The Development Team is intended to work together in a “rugby-like” approach on the highest valued Product Backlog Item and get it to done. Then move to the next one and so on. The company has an opportunity to realize more value and an opportunity to course correct sooner when Scrum is used as intended.
When there’s one generic “backlog” things start to go off the rails . People think there is only 1 list that’s all technical from the Development Team perspective. Because the tool requires one “assigned” person, people believe it’s only 1 person 1 item. There’s no breakdown into the one day or less units. As a result, there’s no Daily transparency. The Daily Scrum is now useless because each person lists “ticket numbers” from the tool and says “no blockers”. Who knows if there are impediments because there’s no way to see that in the tool. People are being conditioned by the software to not articulate what got to done on a daily basis.
The end of the Sprint arrives with no business value delivered and no Product Backlog Items done. Because the tool allows people to split the work retroactively and take “credit” for what they started, it gives a false appearance of productivity when Scrum is all about done or not done. There’s no credit for work not done. And for the big finale, work gets carried over in the next Sprint. When people talk about carry over work and how Scrum isn’t delivering working increments in their Sprint we can always pinpoint exactly which tool is used at the company. It's not Scrum's fault.
Understand why your credibility as an “Agile Leader” is pretty low and wondering how to fix it? Let the people closest to the work own their own process for managing that work.
Allowing your team to own their own process results in more accountability and buy-in. If you believe that “Agile” is the best way to do this, it’s a good idea as their leader to read the Agile Manifesto. It’s a good idea to find out what problem you think a new piece of software will solve. Unless you have unlimited amounts of money that you need to spend, chances are there are already things you have for the people doing work to use.
And hey, if you want to be the most credible of all Agile Leaders, you’d ask the people doing the work for how they want to manage the work that they are doing. Not only are they more likely to support a process they had a hand in defining, there’s a far better chance that some work will get to Done instead of Not Done.
If you are looking for ways to recover from Toolitis, contact us HERE.