The number one question that I get from managers who are learning about Scrum and Agile is: What do I control on an Agile Project?
[featured-image single_newwindow=”false” alt=”Flight Controls – Bryan Burke – Flickr” title=”Flight Controls – Bryan Burke – Flickr”]Flight Controls – Bryan Burke – Flickr[/featured-image]
It seems like a simple question to answer, but if you go the purist route and deep dive in to your self-managing teams talk, you risk alienating the manager. After a few failed attempts at answering this question, I think I’ve found a better way to address this very real management concern.
This question usually comes up when I start talking about how agile teams are self-organizing and self-managing. Managers like the prioritized backlogs and the value tracking. Those things can be turned in to forecasts and metrics that map to their past experiences.
Self-organization feels odd to them, but they seem to get it. Self-managing teams on the other hand can lead to this kind of reaction:
“Wait, if teams self-manage, then…what do I control?”
Doubling down on self-management theory has not worked for me in the past. I’ve also tried answering this question by pointing out moments during a sprint where a manager can help the scrum team inspect and adapt their practices and the increment of software, with mixed results. And honestly, this answer is begging for more trouble than it’s worth.
During my most recent encounter with this question I gave a different answer.
A manager on an agile project controls empowerment, which drives how much and how fast value is delivered to an organization.
Every design review meeting, status report, security assessment, dashboard, metric, and inquiry take time (capacity) away from the team. This is time that could be used to get a valuable feature to a “done” state and ready to be shipped at the end of the sprint. In other words, attempting to control the project delays value from being delivered.
The impacts of trying to control an agile project can even be quantified if needed. I like to add the mechanisms that managers use – additional status reports, design reviews, and excessive documentation – to the team’s definition of done.
This creates transparency with the product owner and ensures that the scrum team takes these activities in to account when estimating their work. Future sprints can be run without the overhead of the control mechanisms to determine any differences in velocity.
Honestly, these managers have never had control of their software development projects – regardless of the methodology used. At best they had an illusion of control. Project are made up of people, not status reports. You can try to convince, coerce, inspire, or lead, but in the end people are going to do things that you cannot predict. And there isn’t a metric, meeting, or dashboard that can change that fact.
[reminder]How would you handle this question? I’d love to hear your take on it.[/reminder]