Management micromanaging sprints

Question

I work at a smallish company as a software lead. So far I have lead one team for the full duration of the project, and have been managing my current team for about 6 months. While the previous project had quite a few problems, which were all out of my hands, everyone in management has told me that I did a really good job of managing what was in my control. For the current project, we have yet to have trouble meeting our milestones, even though we have less resources than originally planned.

The problem is that for the past 3 or 4 months, upper management has started to micromanage me, specifically when it comes to sprints. In addition to the daily team stand-ups, management has scheduled daily meetings with the team leads to discuss the sprints progress. Management also decided exactly how a sprint should look, how tasks should be allocated, and how sprints should be planned. Specifically, I'm told that the team must be overallocated by 10% (i.e. everyone should be 10% over capacity for a sprint) as one of the managers believes this helps motivate the team to work harder. Also, every sprint has to have a "bug bucket" to account for the hours that might have to go to bugs. Then, as the sprint progresses, the team members are expected to stay somewhere between full capacity and 110%, and the teams overall burndown should be below the "ideal trend".

But the thing is, I completely disagree with all of these methodologies, especially since managing these expectations leads me to have almost no time to develop and instead my time is spent doing analytics. I personally think that constantly overallocating people just makes it look like they aren't doing anything, and makes them feel like they can't ever succeed. I also disagree with bug buckets as they make it hard to plan on the remaining capacity in a sprint for fixing bugs. On top of this disagreement, spending all my time doing analytics has left the software engineers on my team to feel neglected - they aren't getting the feedback they want so that they can improve themselves as I don't have the time to do design, architecture, and code reviews.

I'm at the point where it's getting very frustrating for me to have to deal with it, but I don't know the best way to express my frustration. Any attempts I've made to try a different sprint methodology have been immediately shut down. I've also suggested reducing the number of meetings between leadership and management, but that was also ignored.

TLDR: Does anyone have any advice on how to deal with management micromanaging their software lead? Dealing with this daily has made me miserably to the point that it's starting to affect my health, so even short term it's not sustainable.

Answer 1

What you are dealing with is a systemic conflict and its scope far exceeds what you can do at your position. I am saying this as someone who went through pretty much the same ordeal and had to give up and leave at the end after some incredible counter-pressure beyond my wildest imagination when I tried to push for change.

Your upper management subscribes to corporate feudalism. There are good workers and bad workers. Stress is an indicator of productivity, and line workers must be pressured and kept under control. Aggressive peer competition must be encouraged since it allows good workers to rise and bad workers to leave their place for good workers. Value of a worker is determined by how much they sacrifice and how much they listen to their managers. And if a line worker proves their commitment, they can obtain higher ranks which is the epitome of success as they join the ranks of managerial nobility. This not just my cynicism, this is a cultural remnant from earlier centuries of aristocracy and military doctrines feeding the business management doctrines, and despite its shortcomings it has demonstrably produced value since the Victorian Era.

Agile is the popular alternative to this with the core idea that there are stakeholders who want certain things done, and what they want done can be defined in a standard way, split up to pieces where subject experts can pick and work on, delivered and improved with the same process again based on stakeholder feedback. This is very new and required two and a half centuries of accumulated knowledge since the beginning of the industrial revolution and all the means of sharing it that came with the information era. This was impossible just 50 years ago, you needed someone telling someone telling someone telling someone to nail a beam at a specific spot.

My point is your options are either to adapt or to leave. You cannot convince the upper management about their ways. They barely even see you as a human being the way they are, given how they see no issues with the wear-out from constant overallocation. The kind of change you might be hoping for needs to come from the top and even then it usually devolves into crypto-fiefdoms of pockets of managerial despots and their lackeys. Your best bet is to find a new organization that is not the same way if you want that kind of change. If you do not I would recommend reading up on some Machiavelli and Sun Tzu to get in the mindset.

Answer 2

I think you should job hunt

I don't see any indication that management would listen to you. Your phrasing demonstrates that they reject even small changes that you request and yet you want large ones.

we have yet to have trouble meeting our milestones

This sentence makes it especially difficult. 3-4 months of this in, management is likely crediting this on their strategy. You are seeking to change a system that from their perspective is working splendidly.

I have a couple of options for you, but all of them on contingent on you being able to walk away securely. In addition, if your health and well being are suffering, it is better to job hunt now than be struggling to do this after being fired or needing to quit.

So step 1 of any of these is to polish your resume and apply for some jobs. My bet is that you will need to leave to keep your sanity.

Step 2 has a few choices for you.

Option 1: Just quit.

I have known more managers who would fly a plane into the ground out of arrogance than have been willing to pivot completely based on feedback. Math be damned, laws be damned, they will stay their course.

The first few attempts at change have not been successful. Unless you have compelling reasons to stay at this company (and you should check how compelling those reasons are on the job market), save yourself the misery and just call it quits. I can tell by the tone of your writing that you aren't as comfortable with conflict as the typical business person as you hedge your opinions.

Find a new job, give your two weeks of notice, offer those under you a solid reference in case they too wish to escape, and leave the mess behind. In plenty of places, it is a golden time to be a developer, especially a senior one.

Option 2: The Forceful Business Case

Most of the reasons you gave to management have nothing to do with the success of the project, but rather the well-being of your team. Plenty of managers are happy to burn out developers to make a project succeed. Historically, killing and maiming workers wholesale has been perfectly acceptable to business people.

You basically need to make a case for why it is better for a project that they change. The problem is, such reasons often do not exist as long as developers are willing to put up with whatever is being thrown at them. You spending all your time on analytics instead of producing code is basically the only business case you have at the moment.

If you lost a developer to another company because of the treatment, you would also have some evidence, but that likely has not happened yet. You need some kind of dollars and cents metric of why some of your changes are worth implementing.

Some of the problem must also be your tone, as your tone does not project confidence or authority.

Change

I personally think that constantly overallocating people just makes it look like they aren't doing anything

to

Constantly overallocating people just makes it look like they aren't doing anything

and

especially since managing these expectations leads me to have almost no time to develop and instead my time is spent doing analytics.

to

especially since managing these expectations forces me to avoid development and instead waste my time doing analytics.

You probably are not as confident in person, so put it in writing and send it. That is where I have the advantage and I suspect that it may work to yours as well.

I always liked this letter from a senior Blackberry manager to his bosses. He was proven right. Problem was, nobody listened at the time and Mike and Jim flew the plane into the ground. Don't know what Blackberry is? It was the big thing before the iPhone.

Have another job lined up just in case they fire you for this. I have never seen this work.

Option 3: The Ultimatum

Whether option 2 comes before 3 (or 3 as a component of two) or whether you jump directly to three by itself depends on how much you want to change things, how much conflict you are willing to put up with, and how much the company/project means to you.

You believe that you are respected within the organization, but I am not sure. Micromanagement is an insidious form of workplace disrepspect, as they either view you as untrustworthy or incompetent or both. I personally measure respect based on influence and treatment as praise is free to give and business schools encourage that it flow freely as a way to keep employees satisfied for free.

The kind of people who believe this

I'm told that the team must be overallocated by 10% (i.e. everyone should be 10% over capacity for a sprint) as one of the managers believes this helps motivate the team to work harder

Are almost certainly willing to praise people insincerely to "keep you motivated"

everyone in management has told me that I did a really good job of managing what was in my control.

Just to be clear, there is no reason to believe that you are a bad team lead, so don't take a confidence hit just because some of the praise may be self serving.

The ultimatum is essentially just getting another offer for work elsewhere and telling management that either the micromanagement goes or you go.

Good luck!

Answer 3

Dev + PSM here,

I question why your organization wants to do AGILE at all if they're going to ignore significant portions of it. If your goal isn't for you teams to become self-organizing and autonomous then there is no point in pursuing AGILE methodologies. You cant just pick and choose parts of a methodology and discard the parts you don't like and still expect it to do what it was designed to do. That being said, convincing obtuse management that their ways are counter-intuitive is never a straightforward process.

The only thing your management will understand is numbers. Fortunately, in this case, you're spending most of your time dealing with analytics. You'll have to start really digging into that data, but it may take time for the data you need to materialize. The quickest method to demonstrate the error of their ways is to turn in your two-weeks notice with a detailed explanation as to why. I imagine this isn't a feasible option, however, but its something I would start putting some attention to. If your management is performing in this manner, even if you fix this specific problem your next problem with them is always going to be right around the corner. Managements most important role, in my opinion, is delegation. If they can't trust their reports, then they can't delegate. If they can't delegate, then they have to micromanage. And if they have to micromanage, they can't fully dedicate themselves to what they themselves are supposed to be delivering. Managements role is to remove impediments, not create them. You'll have to get creative with your data to demonstrate this. Start looking at things like burndown, turnover, story closure rates, monte carlo trials, PTO clustering, agile scorecards, etc. Start looking for signs that your team is backsliding. They are there, but you may need more time to allow the data to rise above the threshold where it can be ignored as statistical noise. Just your own inability to contribute to development should make a dent in your team's effectiveness.

Long story short, you need hard data. You need to prove with numbers that your team is backsliding. If you're miserable, and your team is miserable, it will show in the analytics sooner or later. But if it is as you say, and this is truly not sustainable for the short term, I would start looking into your options. Solving this headache wont solve the future headaches. Management like this kills teams. Hell, it kills entire organizations. They almost never see it coming, because their solution to dropping effectiveness is to crack the whip even harder. Unfortunately it can take years and dozens of resignations before they see the writing on the wall.

Answer 4

As a certified Scrum Master and a Developer, I'll try to provide a balanced response:

• I would recommend you reconsider your "I completely disagree with all of these methodologies" view and take a step back to understand how to make Scrum/Agile ceremonies and processes work for you. I'll provide examples shortly.
• It is the role of the Dev Team to estimate effort for each product backlog item. Perhaps it's useful to get some Scrum planning poker cards and work with your peers to get used to estimation techniques.
• Sprints should be sized based on the available manhours of the Dev Team to perform the allocated work. So if you have 400 hours of work to do within a Sprint and 300 hours of resource available within the Sprint then overallocating PBIs will generally have the effect that the low priority PBIs are missed and fall into the next sprint. This is to be expected sometimes but to do it on a regular basis is kind of futile.
• Ensure you and your peers get into the habit of writing up brief bulletpointed "Dev Approach" for each PBI, in other words a high level summary of how you intend to go about solving the problem (e.g. refer to views, models, controllers, elements where necessary etc). So a bit higher level than pseudo code. That helps provide more accurate estimates.
• Build a strong working relationship with the Product Owner. It's their role to provide as much clarity as required for each PBI, prioritise them effectively and provide clear overarching vision and goals. Of course Devs can influence this but in the end it's the role of the PO.
• Also work closely with the Scrum Master. It's a part of their role to be a servant leader so if there are blockers getting in the way of you and the team being effective then raise that with them.
• Lastly and I can't emphasize this enough, contribute actively during Sprint Retrospectives. That's the opportunity to discuss how effective they are working together as a team and if you have ideas to help improve things then that's a great forum to raise them and reach some consensus as a team as to which recommendations you're going to take onboard as a team and commit to moving forward.

Scrum and Agile can definitely take some time to get used to, especially those used to traditional leadership and project management methodologies and behaviours. It's not perfect but I'd recommend that you take a moment to reflect and I really hope that the advice above helps you. Good luck!