Micro-managed? Start managing yourself

The story of a struggling Scrum team

An agile coach works with all kinds of teams with the goal of helping each of them become truly self-organizing and self-managing. Sometimes that means helping a team see a truth they may not be aware of or want to admit to — this is the tale of such a team.

Recently, I was working with a client to progress their agile transformation in their organization. We started byre-launching three Scrum teams. I say re-launch because they had been “agile” for some time, according to their perception. Needless to say, what they were doing was not agile, but something else.

A lack of trust

I checked back in with the teams about three months after the relaunch and there were some problems. One of the teams was complaining about being micromanaged. They were complaining about how leadership, managers, supervisors and now these new things: Scrum Masters and Product Owners (see, I told you they were “agile”) were asking them about progress and their plans. Every day somebody was asking them something. This complaint about being micromanaged definitely seemed non-agile’ish so it was time to take a closer look.

I talked to the “micromanagers” and their main concern was that one of the teams was not successfully delivering to their plan. I then looked at their ALM tool (not CA Agile Central) and it became very clear very quickly the team was not delivering to their plans — not to their sprint plans, not to their longer term plans.

I offered to meet with them. I listened to their concerns for a bit, then pulled up their ALM tool to show them the data I had reviewed. They had plans, both short (Sprint) and long term and the data clearly showed they were not delivering to either. I want teams to build a realistic, achievable plan and then deliver to that. I’m not expecting perfection, but if I’m going to trust a team I need to trust their plans.

Then, when a team runs into some challenges and realizes their original plan won’t be met they should let people know that as soon as possible, and provide a recommendation for moving forward. I told them I would micromanage them too because I couldn’t trust their plans. Since they weren’t delivering to their plans I would have no choice but to ask them frequently about their progress.

The room got rather quiet. So I gave them a way out. I said “if you don’t like being micromanaged then manage yourself.” I told them how to do this:

  1. Plan for your Plan: Take into account all of the historical data the team has access to, in order to help understand velocity and capacity.
  2. Build a reasonable plan: The team starts by using the historical data as a starting point but should also consider if there is anything different (new team members, perhaps several people are in training or taking time off during the upcoming sprint, etc.) that would change the team’s expectations. Taking in account historical data and anything unique about the upcoming sprint, build a realistic and reasonable plan.
  3. Deliver to that plan, even if it hurts: Learn from the pain, then adapt.


That – delivering to the plan – is the real secret, the real way out of their mess. Deliver to your plan to build trust. Once people see that you build a plan and deliver to it, they will trust it and trust you. They will leave you alone.

This team isn’t perfect, but they are much better. They now understand their velocity, their capacity, how to build an achievable, realistic plan that provides value to their customer. They are no longer micromanaged.

Tony Akins
I've found the best way to get a point across is to tell a story.…


Modern Software Factory Hub

Your source for the tips, tools and insights to power your digital transformation.
Read more >
Low-Code Development: The Latest Killer Tool in the Agile Toolkit?What Are “Irresistible” APIs and Why Does Akamai's Kirsten Hunter Love Them?Persado's Assaf Baciu Is Engineering AI to Understand How You Feel