4 ms·
Well, unfortunately, this all comes down to communication. Agile meetings serve a few basic purposes: 1. They provide a venue to communication requirements fr
by zzalpha 9y ago
Well, unfortunately, this all comes down to communication.
Agile meetings serve a few basic purposes:
1. They provide a venue to communication requirements from Product to Development.
2. They provide a venue for Development to communication questions, concerns, or technical details back to Product.
3. They provide a venue for external stakeholders to observe progress and provide further input on requirements.
4. They facilitate communication inside the team, both on basic status, but also in refining and improving internal processes through introspection.
You could avoid a lot of this by, instead, writing lots and lots of documentation covering requirements, processes and procedures, etc.
Or, you can hold regular meetings and talk stuff out.
You pick.
No process is perfect, but every process has to provide these communication channels in one form or another.
Of course, to a single dev, communication always feels like overhead. It's not.
That said, just a couple points in response to your rant:
Estimating story points for tasks when we know there is only one who has the skills to do it
Then your team should do more cross-training or be more creative about sharing work. Just because one person can code, doesn't mean other people can't test, perform code reviews, assist in writing documentation, participate in pair programming, etc.
Alternatively, the team is just too damn big. Including Scrum Master and Product Owner, you should be at no more than 9 people, and preferably 7. At that size, it's pretty hard to have only one person work on anything.
It's an absolute sign of dysfunction if, in your team, people think "only one person can work on that"... you're being myopic.
direct conversions between time and story points.
You're not supposed to do that. Your process is broken.
Countless hours spent in splitting and combining "stories" to make them agile sized bites.
That's a good thing, not a bad one. Small pieces of work are achievable and predictable.
Estimation meetings that take half a day,
Your process is broken. There are many ways to streamline these activities. Introduce timeboxed backlog refinement meetings. Ensure the PO is adhering to a strict Definition of Ready. Have a discipline Scrum Master who shuts down irrelevant ratholing.
And why aren't these issues raised and addressed in your retrospectives?
where for every story only 20% of all the people who sit there can contribute.
See above.