Dysfunction #4: Lack of Independence
In this series, I am going to reflect on what I have learned about Scrum and its large-scale adoption in a non-IT environment through my own revelations and indeed, failures, while working at a large UK-based company, rolling out its own flavour of Agile Transformation. Capital “A” and capital “T” intended.
Originally published at https://www.linkedin.com in January 2021.
Let me start with some self-reflection: this article has been quite a challenge to write. As I was thinking about the experience I was to capture, I was thinking my topic would be about commitment (or the lack thereof) but then found that this was just a symptom, not the diagnose.
This article is somewhat related to the previous one written about autonomy and empowerment, but in my view independence as such is much broader and covers more depth than simply empowerment and autonomy. Independent teams are not only autonomous and empowered but are much better positioned to live and breathe Scrum values as well.
Commitment
Independence enables teams to be committed. Team members are not being pulled out of their teams so the team can gel and explore a true identity. Independent teams can release at will and do not have to seek management consent to do so. The feeling of commitment might be lost when teams lack independence, and I have experienced that first hand.
During an upbeat sprint planning, team members plan to organise creative workshops with external agencies. Others plan to have some other obscure department, say compliance, sign something off for them so that they can move forward with a new initiative. Yet others will want to present something to senior management to get approval for our plans for the next three months. Oh, by the way, we also have to put in these finishing touches on the campaign we work on because it rolls out on the 15th. Great plans, wonderful energy from the team, so are geared to take off and start the work.
By the time sprint review happens, it turns out most of the stuff is still in flight: two of the five external contributors of the workshop we have set up couldn’t make it on the day, so we had to postpone the workshop to the next sprint. Compliance doesn’t give a damn about our sprint goals and will sit on our request for weeks on end, and their preliminary sign-off might be granted in the next sprint. Senior management had to cancel in the very last second before our presentation, because there was an emergency (there always is), and team members might be able to present next sprint. Oh, and by the way, the campaign go-live was also postponed to sometime in the next sprint.
During the review, we have 60% of the sprint backlog in progress and as we go through the list, team members will explain to one another why something couldn’t move to done and how it will happen in the next sprint. (And of course then it might not.) The team might feel demotivated due to a missed sprint goal. They will fume and vent on the retrospective and we try to do something about it.
But if this pattern is repeated sprint over sprint (as it often did), it is not the fault of the team — they have the best intention to work towards their commitment, they are just not independent: they have external contributors and stakeholders that can block them and impede their progress. In such an environment, commitment will vanish, and vanish quickly.
Focus
When team members see that the commitment they made is slipping, they will scramble to bring in something to work on. And in their haste, they might bring in work that won’t fit in their remaining time box or not ready to be worked on just yet. We will start starting and stop finishing, and the sprint might turn into shambles, a lot of unfinished product backlog items and a demotivated team.
An other thing that might happen is that one of those senior managers who had to attend an emergency just days ago is now throwing a curveball to the team in the form of a dreaded JFDI. (Whatever your favourite acronym finder says, it doesn’t mean Just Focus and Do It. It’s close but not quite.) The Product Owner and Scrum Master both try to talk them out of this, highlighting how disruptive it will be for the team to chuck the sprint work out of the window, but the senior manager is relentless: the work needs to be done, and needs to be done now.
Conclusion
So how is the team going to commit when they have experienced immovable dependencies peppered with a couple of disruptive JFDIs. They won’t. Planning sessions will become half-assed and half-hearted efforts with a “hopefully nothing will explode in our face” type of sprint plan. At times, when nothing explodes, teams will sail through the sprint beautifully, and at the retrospective, they will highlight the fact that “we could do everything we wanted to because we had no dependencies and we could work on our own”, but in environments like this, such sprints are the exception, not the rule.
Also, when a good chunk of the sprint plan becomes undelivered by the end of the sprint and it happens frequently, iteration over iteration, the team will feel demotivated. Some people might even try to comfort others saying that it is acceptable to not finish everything, and then it is us, scrum masters, who need to reply that, actually no, it is not OK. Scrum provides a framework to come up with a short-burst plan, execute it then review what has been achieved. Carrying over stuff from one sprint to the next should be an exception, not the rule. After a few sprints, it might feel that we are bringing the same tickets to planning which have not been resolved for months on end and it might look like the process doesn’t really work.
And who gets to blame? Scrum gets to blame…
Originally published at https://www.linkedin.com.
