Scrum is a project management technique. It has been around since 1995, on a broader base since 2002, represented by persons like Ken Schwaber and Jeff Sutherland.
Scrum recommends to partition project work into sprints, which are delimited by a planning and a review, plus retrospective. A popular sprint duration is two weeks. During the sprint, stand-up meetings are held every day.
In this Blog I want to focus on stand-up meetings, and why it is so difficult to make them efficient for software development teams. My experiences come from three different Scrum teams I've been in, and include people from all over the world.
Rules
Here is a (hopefully) common sense of the stand-up meeting.
Why Stand Up
We sit in front of our computers the whole day, concentrating on things we must solve on our own, so standing up means that we now concentrate on things that concern us all as a team. Thus standing up transfers us to common sense, which is at the very core of Scrum. When you are disabled, turn your chair towards the meeting point.
What to Say
- What have you done since the last meeting?
- Is there something that blocks your work?
- What will you do until the next meeting?
The "What" here are issues done in sprint planning, accessible for all by some issue tracker. In case you were working on several issues, preparing a "cheat-sheet" for the meeting may be recommendable.
Blockers are usually issues that do not contain enough information to solve them. You should tell what informations exactly you are missing, so that the Scrum Master or the Product Owner can take actions.
Your statement should not be longer than two minutes, maximum three. Use an egg-timer to control that. Because in a Scrum team there are seven members on average, a meeting should last just a quarter of an hour.
What to NOT Say
The stand-up is not for technical surveys and discussions. Do this afterwards, individually. Knowledge about how to solve the planned issues should be well distributed and available, to be done in the sprint-planning.
Of course things not connected to the sprint are not to be mentioned in the meeting, as there is the new coffee machine, or whether copy & paste is a useful programming technique (it is not).
Who Talks
In a stand-up meeting only team members that have been sprint-planned are talking. It doesn't make sense that the product owner tells what the customer expects the next half year, or stake-holders explain what they would like to achieve with the project. Such should be done in separate meetings.
There can be more participants than just the team members, but these others get no speaking time, they just have the right to listen and put up questions. The team doesn't know their interests and goals, thus such information is useless for it.
Roundabout
After a team member has finished telling its state, it passes on to some other member. Lots of teams use a physical token for that. If you have an egg-timer, pass it to the next person after having set three minutes onto it.
No more to say about stand-up meetings. Scrum claims to be simple.
Problems
Reality mostly differs a lot from theory. Following are my experiences of what people really do in stand-up meetings.
Gives No Context
The team member anticipates that everybody knows what it is working on (which is a big mistake). It doesn't feel responsible for creating a common sense. It doesn't even mention the title of the issue it talks about, doesn't tell the module or application it is maintaining. It doesn't verify whether the team understood what it just said, it seamlessly skips to next issue.
Not Related to Issues
The team member describes how to work with the IDE efficiently, or how to tune the computer. It gives an introduction into design patterns, or explains application architectures.
McDiver
The team member immediately dives down to type- and method-names where no one can follow. Consuming all time with loops, conditions and acronyms, it sounds like a compiler participates in the stand-up.
The Unprepped
The team member did not prepare for the meeting, and is not able to do it unprepared. Losing itself in source code mediations, forgetting to formulate potential blockers, the "What To Do Next" is mostly dropped.
The Big Mac
The team member always says the same at the stand-up, for days, sometimes the whole sprint. Reason is that he did not break his big feature down into smaller tasks (which he then could report to be done).
The Acro Guru
Using lots of acronyms and abbreviations will earn you the Guru title. But it will also cause that it is hard to follow you, and thus makes your statements meaningless for a stand-up. Avoid abbreviations and acronyms wherever you can. You are talking to humans, not machines. Besides, times of small memory are also over!
The Time Chaser
The team member explains its issues well, but in a speed that no one can follow. Typically it is never looking at other members while talking, and uses lots of acronyms.
Solutions
Precondition for mitigating these problems is that the sprint has been planned well. That means no issue in the sprint is estimated to last more than one day. Make sure that long lasting features get broken down to smaller tasks. Only then you can avoid that people tell at the stand-up that they are still working on XXX, and there's nothing more to say.
How to Talk
Try to explain your issues in a way so that others can follow and understand you. You can verify this by looking at them from time to time. It is a bad sign if they're all watching the floor, and a good sign if they nod to you.
Go from General to Special
Start with giving the audience a context of what your issue is, and then carefully go deeper, but do not leave the conceptual level. Talking in source code will not be understood, except when your classes and methods have been named really well (which unfortunately rarely is the case).
Briefing
New team members should be told in their first stand-up what are the rules (see above). Regularly also teach Scrum when the team deviates.
Teaching
Make it clear to the team that the stand-up is communication, and find some example from the project's history that shows how important communication is. Mention that there could be conflicting works or duplicate implementations.
Immediately Intervene
The Scrum master must intervene immediately when rules are violated in a stand-up. Don't shift this to later, when you don't do it now, you'll most likely never do it. And it must be done in a common sense, before the team.
Summary
Scrum is a well-accepted project management technique, mixed together from a collection of best practices by experienced engineers. I particularly appreciate its dedication to simplicity.
Stand-up meetings are a way to keep the team members in touch with each other on a daily basis. More common sense will be the revenue, and that's what we're all missing. Don't expect that your stand-up will improve immediately when you explain things once. It will be a long process to become better.
Keine Kommentare:
Kommentar veröffentlichen