Well explained, but parrots the standard misguided formulae and brainwashing that the Scrum community so desperately wants everyone to accept.
The author wrote, “If we look at self-organising teams, they don’t need someone directing them and telling them what to do.”
Yes, well, perhaps read this LinkedIn article, “Why Self-Organizing Teams Don’t Work”, which received 45,000 reads. Yes, the Agile Manifesto mentions self-organizing teams, but it does not say that all teams should be self-organizing. IME, only a team of experienced programmers is likely to be capable of self organizing. Some of the perils of self organization are that loud and aggressive people take over, becoming de-facto autocrats.
And the daily standup? — which Scrum wants you to call the “Scrum” so that they can embed the term in your mind, because after all, the Scrum community is out to sell certifications, and they want you to think that Scrum = Agile.
Well, IME, the daily standup as defined by Scrum is an idiotic waste of time. Most people on a team do not care what tasks everyone else is working on. Instead, what they need to know is how everything will fit together. But for that, a daily status meeting is worthless.
Yes, I called the standup a status meeting: because that is exactly what it is. What you did, what you are going to do, and what are your blockers: I could not more succinctly define a status meeting.
I have seen standups that were effective, but they were not as Scrum prescribes. Instead, they were thoughtful discussions in which the team’s tech lead went around, asked each person about their work, and then there was brief discussion of the technical issues involved. That way, everyone got to learn about how things work end-to-end.
Short of having actual substantive discussions, what is a-lot better is to just leave the programmers alone: let them start their day their way, instead of dragging them into a first-thing-in-the-morning meeting, before they have had a chance to check their email and even know what they plan to work on. And the whole standing thing is awful: it is like an interrogation. Perhaps bright lights should be shined on each team member as they timidly mumble what they are working on.
It all comes from Jeff Sutherland’s idea the programming is like sports, or like being on a fighter squadron. Hey Jeff, guess what? It’s not. Programming is nothing like being on a sports team, or being on a fighter squadron. Programming is not kicked off by a rally, after which everyone rushes to their desk, like running onto the field. Programming requires calm, so that one can think deeply.
Here’s what works better than having standaup, and it is Agile:
- Have a true team lead, and expect that person to be knowledgeable about the work. Also expect that person to lead using a servant leadership style. (And beware: if you read books about servant leadership, they do not describe it the way that the Scrum community does. Real servant leadership is leadership and carries authority and accountability.)
- Have the team lead conduct a recurring discussion about the product’s design, what features are being worked on, how they will work, and any concerns about the design. Expect the team lead to encourage everyone to share their thoughts, and pull ideas out of the team in a Socratic fashion — particularly those who do not naturally voice their opinion unless asked. (It worked for Socrates!)
- Expect the team lead to be always aware of what everyone is working on, and thinking end-to-end, and making sure that nothing is being overlooked. If an issue comes up, expect the team lead to get the right people together to discuss it and drive toward a resolution. Expect the team lead to make sure that any decisions made during ad-hoc discussions are shared with the rest of the team.
Scrum fans will complain about many aspects of the above. They will say that it is a return to the old single person boss. Not true. A servant leader is not a traditional boss.
Scrum fans will complain that the above makes one person a bottleneck. Not true: anyone can voice any issue at any time; in fact, an effective servant leader is sensitive to people’s personalities and encourages those who are silent to voice their thoughts.
Scrum fans will assert that everyone should be thinking end-to-end — not just the team lead. But the problem with that is that IME they don’t: people are too busy trying to get their story done. Someone needs to be thinking end-to-end as their main job.
Scrum is a prescriptive process, which goes against Agile. Dave Thomas and Ron Jeffries — authors of the Agile Manifesto — have voiced deep concerns about this. Check it out: here and here.
People should reject Scrum. It defines non-sensical practices, distracting people from what really matters in a programming team — things like the automation pipelines and how test coverage is managed. There is so much more to a programming team than whether they are having a daily status meeting. My gosh.
