It's a sad day when the ideas behind the agile movement have fully become the Agile System (tm) in engineer consciousness. The word used to denote a style of working, not characterised by micromanagement or by a Scrum Master (tm, again) telling people what to do, but ironically by leaving behind dogma for a loose collection of principles that worked effectively for the team and the problem at hand. The word has been lost, though. Using the word 'agile' now evokes more derision than enthusiasm or excitement.
There are people who suck at managing software development and people who suck less. Whether they call it agile or use some system or other has zero correlation with how toxic or effective they are.
This is heresy amongst my peers but I love to gaslight them by saying: there were plenty of high performing waterfall teams before anyone ever uttered agile.
agile only pisses me off when I see 'experience working in an agile environment' as a desired skill in a job posting. More of a buzzword than a principle.
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.
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.
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.
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.
> 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.
> 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.
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.
Mmm, this line of thinking makes it impossible to critique though. Anything you don't like is just the official, bad system. Real agile is just the good parts!! You see what I mean.
It's a sad day when the ideas behind the agile movement have fully become the Agile System (tm) in engineer consciousness. The word used to denote a style of working, not characterised by micromanagement or by a Scrum Master (tm, again) telling people what to do, but ironically by leaving behind dogma for a loose collection of principles that worked effectively for the team and the problem at hand. The word has been lost, though. Using the word 'agile' now evokes more derision than enthusiasm or excitement.