> 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.
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?