Agile Scrum - anti-patterns
M_Kevin_McHugh 270001CDK4 Visits (5065)
I've been noticing some Agile Scrum anti-patterns and thought I would start collecting them and posting them.
When I watch daily scrums, I expect to see the ScrumMaster with a very light touch. If we're not in the same room, I expect prompting for who is next. But, I expect the team to provide the three ques
- What I did yesterday
- What I will do today
- Here are my impediments
This is what I call a person or team oriented scrum.
I've seen cases where the ScrumMaster goes to a task orientation. In this mode, the ScrumMaster works down a list of tasks asking for status on the task. Keep in mind, that this isn't a team orientation of "what we did", walking the board. This is a command and control approach of assigning tasks and holding team members responsible for status on a daily basis. But, more, many of the tasks being queried are further down the priority list. This means a dramatic waste of time as status reporting is taken for tasks that just aren't high on the radar at the moment. This has two impacts. First, it keeps the Team ownership low. I've directly observed Team members not picking up tasks they could easily have done because they were not "assigned". Second, puts all the organization responsibility on the "ScrumMaster". In reality, this person is now the Project Manager.
## If the Team isn't the focus, this is just waterfall broken into 2 week chunks. No Whole Team productivity gains will be obtained. ##
VARIABLE SCRUM MEETING TIMES or NO ADVANCED SCHEDULING:
I've seen this lead to low attendance and therefore low Team ownership. I've seen this lead to poor Team coordination. This is a signal to the Team and to everyone else that the Agile ceremonies are low priority and should be ignored. This can contribute to a failure to adopt.
## If your meetings are not scheduled ahead, your not committed and your not planning. ##
STORY POINT ASSIGNMENT DURING SPRINT PLANNING:
I have a new policy, especially during Agile adoption. I require Story Points for a story to be considered groomed. For "grooming" to be complete, I tell the new teams to capture in their tool
- Solid, clear narrative (i.e. - As a ....)
- Solid, detailed description. For many tools, stories end up as records. Get detailed enough that the team can break out tasks from the description
- Solid, clear Acceptance Criteria. I expect the Product Owner to contribute. I expect Architects to contribute. I expect the team (especially test experts) to contribute.
- When all the heads are nodding up and down in agreement, ... drum roll....
STORY POINT it.
Why do I require this at this time? Well, I've discovered that when I force the Team to story point a story, if it is still vague, they won't commit to a point value. If the story is clear, they commit immediately, practically calling out the point value.
## If you can assign story points, you aren't clear on the story. It is NOT ready for a Sprint. ##
SPECIALIST HAND OFF WITHOUT THE SPRINT:
I have seen two ways for this to happen. This pattern usually looks like: Req
## If you see a cascade of backlogs that represent waterfall phases, it is worth a look to see if
bitly link: htt
M Kevin McHugh