4 ms·

Curious why would one think agile is micromanaging?

by ismail 9y ago

ErrantX 9y ago
Because its the common mistake large companies make when implementing agile. As a C-level you want to know the roadmap for the next 12 months and waterfall gave you that. Agile can be a bit terrifying (ofc it shouldnt be), therefore certain people (SAFE, looking at you) have worked out how to make agile look like waterfall from above. Basically by building tiers of process and making the demon-scrummaster (rather than teams) all powerful. The BBC is, as i understand it, a notorious example.
- josh602 9y ago
  This isn't true in my experience. Each team I've come across has their own variant of Kanban that works for them that has evolved over time. We have no scrum masters. We have a plurality of leadership in teams, comprising of a tech lead, one or more product managers, a project manager and maybe a senior UX designer. This works quite well for us. I've only been at the Beeb for a year, of course, but I wouldn't say I've generally felt micromanaged. In particular, the tech lead of my current team very clearly makes a conscious effort to ensure he takes a step back and allows the team to self-organise.
ryanmarsh 9y ago
SAFe destroyed the great progress many of my clients were making towards more nimble, more human, software development. Dean Leffingwell is a charlatan and a snake oil salesman.
bitwize 9y ago
Because Agile is seen as a set of processes, not a set of values. The new hotness is time tracking -- making developers accountable at a micro-level for how much time they spend at each step of developing a feature, enhancement, or fix. All of which will have been specified in the beginning-of-sprint planning meeting of course. Management likes this because to them it's like profiling and optimizing a program. Developers hate it because the numbers are BS and the planning is basically waterfall in miniature, giving them little opportunity to explore the solution space. Plus the data collection itself is panopticon-ish. Agile was an attempt to sell basic (old school, think CSAIL not L0pht) hacking strategies to stiff-necked managers and executives under the rubric of making better software for cheaper. But managers and executives have their own set of values: measurability and predictability, the more the better. Agile requires you to let go of those a little, which Corporate America isn't willing to do. So if you join a Scrum shop, you will likely see cod-Agile that goes through the motions of Scrum while forgoing the principles of Agile -- under pressure from the top.
- quickthrower2 9y ago
  Well said. The panopticon is spot on. Worked at places like that where each JIRA ticket feels like a timed coding exercise with a negative immediate consequence if it takes too muvh time. Result: most tasks are completed on time, stats look brilliant, hacks upon hacks, burnout, no cohesive design.
- ismail 9y ago
  Is this the case for every company doing scrum? I find some benefits in scrum: 1. Having regular scheduled meetings reduces distractions. For example, someone coming along to chat about something while you are in the zone. 2. The important things get discussed with the right people in the room. Decreasing assumptions I think people tend to forget that the critical thing to get right with agile or whatever methodology you are following is: 1. It is #1 about conversations between people. 2. The conversations between people help you explore the complexity. 3. The conversations help you surface assumptions, get alignment on what needs to be done 4. It is not about 'tracking', but rather encouraging effective communication to converge on the best path forward. So question: If you had to design a better agile process, what would that look like?
  - dragonwriter 9y ago
    > If you had to design a better agile process, what would that look like? It would have a well-defined process and standards for proposing, testing, evaluating, and adopting process changes. In fact, that's all it would have; you'd start with that and apply it to the combination of itself and your pre-existing dev process, whether or not that process claims to be “agile”. If your process isn't centrally about continuously optimizing itself to business circumstances, tasks, and team personalities and skills, it's not agile.
  - bitwize 9y ago
    > Is this the case for every company doing scrum? I find some benefits in scrum: I find a lot of benefit in many agile methodologies on paper. But where the rubber meets the road, the principal decision makers have a vested interest in not holding up the principles of agile. > It is not about 'tracking', but rather encouraging effective communication to converge on the best path forward. For any path forward, managers need to answer these questions: * What needs to be done? * How long will it take? * Are we on track, behind or ahead of schedule? (This needs to be answered at least once a day.) * What, exactly, are the pain points? (Again, once a day at least.) These can be summarized in a Scrum standup, but what managers really want to see is a detailed analysis. Hence the need for: * Detailed task breakdown of each story/ticket * Detailed time estimates on each task * Detailed daily-at-least time logging on each task So yes, it absolutely is about tracking. Tracking is the central component of any corporate software process. Tracking is what enables your manager to get a picture of what currently needs to be done and how far along the team is in getting it done. Inasmuch as agile processes can exist in this environment, they must be reshaped to accommodate the tracking requirements. Which means they won't be agile anymore. Tracking also provides the benefit of an auditable paper trail, so that when government regulators come sniffing around they have a nice log of who did what when on the software. In short, Agile has by and large failed. It does not adequately meet the needs of upper and middle management of a corporate shop, for whom time is money and there are strict accountability requirements.
dasmoth 9y ago
Curious why would one think agile is micromanaging? (At least in the case of Scrum): because some of the most vocal advocates say so[1]! The premise seems to be that fine-grained oversight is less objectionable if it comes from “the team” rather than a manager, and that model does seem to work for some. It still kills the opportunity to work autonomously for any non-trivial interval of time. [1] https://www.mountaingoatsoftware.com/blog/ssssh....agile-is-all-about-micromanaging https://www.mountaingoatsoftware.com/blog/ssssh....agile-is-...

Curious why would one think agile is micromanaging?

by ismail 9y ago

Curious why would one think agile is micromanaging?

Because its the common mistake large companies make when implementing agile. As a C-level you want to know the roadmap for the next 12 months and waterfall gave you that. Agile can be a bit terrifying (ofc it shouldnt be), therefore certain people (SAFE, looking at you) have worked out how to make agile look like waterfall from above. Basically by building tiers of process and making the demon-scrummaster (rather than teams) all powerful. The BBC is, as i understand it, a notorious example.

josh602 9y ago
This isn't true in my experience. Each team I've come across has their own variant of Kanban that works for them that has evolved over time. We have no scrum masters. We have a plurality of leadership in teams, comprising of a tech lead, one or more product managers, a project manager and maybe a senior UX designer. This works quite well for us. I've only been at the Beeb for a year, of course, but I wouldn't say I've generally felt micromanaged. In particular, the tech lead of my current team very clearly makes a conscious effort to ensure he takes a step back and allows the team to self-organise.

ryanmarsh 9y ago

SAFe destroyed the great progress many of my clients were making towards more nimble, more human, software development. Dean Leffingwell is a charlatan and a snake oil salesman.

bitwize 9y ago

Because Agile is seen as a set of processes, not a set of values. The new hotness is time tracking -- making developers accountable at a micro-level for how much time they spend at each step of developing a feature, enhancement, or fix. All of which will have been specified in the beginning-of-sprint planning meeting of course. Management likes this because to them it's like profiling and optimizing a program. Developers hate it because the numbers are BS and the planning is basically waterfall in miniature, giving them little opportunity to explore the solution space. Plus the data collection itself is panopticon-ish. Agile was an attempt to sell basic (old school, think CSAIL not L0pht) hacking strategies to stiff-necked managers and executives under the rubric of making better software for cheaper. But managers and executives have their own set of values: measurability and predictability, the more the better. Agile requires you to let go of those a little, which Corporate America isn't willing to do. So if you join a Scrum shop, you will likely see cod-Agile that goes through the motions of Scrum while forgoing the principles of Agile -- under pressure from the top.

quickthrower2 9y ago
Well said. The panopticon is spot on. Worked at places like that where each JIRA ticket feels like a timed coding exercise with a negative immediate consequence if it takes too muvh time. Result: most tasks are completed on time, stats look brilliant, hacks upon hacks, burnout, no cohesive design.
ismail 9y ago
Is this the case for every company doing scrum? I find some benefits in scrum: 1. Having regular scheduled meetings reduces distractions. For example, someone coming along to chat about something while you are in the zone. 2. The important things get discussed with the right people in the room. Decreasing assumptions I think people tend to forget that the critical thing to get right with agile or whatever methodology you are following is: 1. It is #1 about conversations between people. 2. The conversations between people help you explore the complexity. 3. The conversations help you surface assumptions, get alignment on what needs to be done 4. It is not about 'tracking', but rather encouraging effective communication to converge on the best path forward. So question: If you had to design a better agile process, what would that look like?
- dragonwriter 9y ago
  > If you had to design a better agile process, what would that look like? It would have a well-defined process and standards for proposing, testing, evaluating, and adopting process changes. In fact, that's all it would have; you'd start with that and apply it to the combination of itself and your pre-existing dev process, whether or not that process claims to be “agile”. If your process isn't centrally about continuously optimizing itself to business circumstances, tasks, and team personalities and skills, it's not agile.
- bitwize 9y ago
  > Is this the case for every company doing scrum? I find some benefits in scrum: I find a lot of benefit in many agile methodologies on paper. But where the rubber meets the road, the principal decision makers have a vested interest in not holding up the principles of agile. > It is not about 'tracking', but rather encouraging effective communication to converge on the best path forward. For any path forward, managers need to answer these questions: * What needs to be done? * How long will it take? * Are we on track, behind or ahead of schedule? (This needs to be answered at least once a day.) * What, exactly, are the pain points? (Again, once a day at least.) These can be summarized in a Scrum standup, but what managers really want to see is a detailed analysis. Hence the need for: * Detailed task breakdown of each story/ticket * Detailed time estimates on each task * Detailed daily-at-least time logging on each task So yes, it absolutely is about tracking. Tracking is the central component of any corporate software process. Tracking is what enables your manager to get a picture of what currently needs to be done and how far along the team is in getting it done. Inasmuch as agile processes can exist in this environment, they must be reshaped to accommodate the tracking requirements. Which means they won't be agile anymore. Tracking also provides the benefit of an auditable paper trail, so that when government regulators come sniffing around they have a nice log of who did what when on the software. In short, Agile has by and large failed. It does not adequately meet the needs of upper and middle management of a corporate shop, for whom time is money and there are strict accountability requirements.

dasmoth 9y ago

Curious why would one think agile is micromanaging? (At least in the case of Scrum): because some of the most vocal advocates say so[1]! The premise seems to be that fine-grained oversight is less objectionable if it comes from “the team” rather than a manager, and that model does seem to work for some. It still kills the opportunity to work autonomously for any non-trivial interval of time. [1] https://www.mountaingoatsoftware.com/blog/ssssh....agile-is-all-about-micromanaging https://www.mountaingoatsoftware.com/blog/ssssh....agile-is-...