agile, scrum, coaching, lean
Basic Scrum
Ready For Sprint?
521 days
http://www.flickr.com/photos/robert_voors/767796301/
Have you ever been sitting in a sprint planning and heard the following sentences:
- “Can we split this user story and at least start with the GUI?”
- “I’m not sure if the hardware will be available on time to integrate this story but we could use an emulator instead.”
- “There are no wire frames yet, but we could start with the back-end.”
- “The acceptance criteria are still quite vague, but I think I know what the customer needs.”
- etc.
Does some of these sentences sound familiar? I observed these conversations several times in the past. All of these quotes are based on the same problem: The user story is simply not ready for the next sprint. Still, some teams pull these user stories into there next sprint to implement at least a part of it, to make the PO happy. Stop it! It doesn’t make sense at all. None of these user stories will be done at the end of the sprint, because important parts are missing. These teams have to be reminded that every user story has to be implemented, tested, integrated, documented and shall deliver value to the end user. If you already know at the start of a new sprint, that you won’t be able to finalize a user story: ditch it!
But what can you do to avoid these discussions? There is a simple solution: Introduce the “Definition of Ready” (DoR)! The DoR defines, when a user story is ready for a sprint. If it doesn’t comply with this definition it will be ignored in the next sprint planning. As the “Definition of Done”, the DoR is defined by the team itself and therefore varies from team to team. If you’re e.g. developing a web application, hardware may be not that important for your team, but if you’re developing software for e.g. a medical device it is could be important. Sit together with your team and your PO and define what the DoR has to contain in your current situation. Agree, only to pull those stories into your sprint, that are ready for sprint.
Most agile teams I know implement a DoD, but the DoR is still only rarely used. I hope this will change in the future. Don’t waste your time implementing half-baked user stories. You can use your time better than that.
What are your experiences? Leave a comment!
11 Hints to Improve Your Scrum Meetings
6150 days
I saw a lot of Scrum meetings out there, that are not more than a skeleton. Everybody is attending but nobody is participating. To improve such situations I collected 11 hints to improve your Scrum Meetings.
Daily Scrum
1 – Walk the Board
Instead of answering the “three questions”, which leads in most teams to answering only the first two questions, walk the board. This means, use your Sprint Backlog to talk about what is currently in progress and what is planned for today. That way you’re concentrating on the really important things, instead of talking about the past.
2 – Show what you’re working on
Pictures are often better than words. Show your colleagues what your currently working on. And yes, it is possible to still do this within the 15 minutes time box.
3 – Appreciate the Daily Scrum as a Mini Sprint Planning
The main reason for the Daily Scrum isn’t the reporting. The main reason for the Daily Scrum is to plan your work for the day. The meeting should be used to plan your next steps in towards your overall Sprint goal. Try to change the context of the Daily Scrum and use it as a Mini Sprint Planning meeting.
Sprint Planning
4 – Demand commitment
I know that in the last update of the Scrum Guide the commitment was alleviated, but I think I’m not the only one who thinks this is the wrong direction. At least in Europe I still think that the commitment is an important part of Scrum. That’s why I demand the commitment of every team member e.g. at the end of a Sprint Planning. Write your Sprint goals on a flip chart and let everybody sign it. Put it on the wall of your team room.
5 – Avoid big tasks
I believe every ScrumMaster heard this sentence more than once “This task is not splittable”. Bullshit! I’m convinced that 95% of all tasks can be splitted in smaller ones. Don’t accept big tasks, just because you want to finish the meeting and head to lunch. And this leads us to…
6 – Bring food
The Sprint Planning meeting is the longest meeting in Scrum. Avoid that the blood glucose level is going down and everybody wants to leave as soon as possible. Bring food!
Sprint Review
7 – Rehearse the Sprint Review
Nothing sucks more than an unprepared Sprint Review. Take your time and prepare the Sprint Review properly. If it’s the last day of your Sprint and a feature is still not running, skip it. Concentrate on what is working and prepare a great show. Your stakeholders will love you.
8 – Use the daily Scrum to plan the last steps
The last Daily Scrum should be used to talk about the last steps that have to be taken to reach the Sprint Goal. Nothing is more important that day.
Sprint Retrospective
9 – Define a responsible
At the end of a Sprint Retrospective you normally have a list of (a few) improvements for the next Sprint. But as long as nobody was assigned to the improvements, nothing will happen. I know there are exceptions, but having a responsible team member per improvement helps to keep the team commitment.
10 – Define a DUE Date
The same is true for a due date. You may decide, that all improvements have to be done till the end of the next Sprint, but there are tasks that will take longer. Set a due date for every improvement to help to track it.
11 – Make the results visible
I saw a lot of teams that put the results of their retrospective into a Wiki or an agile tool. The problem with this approach is, that nobody will see them anymore. Out of sight, out of mind. Put the results on a flipchart and hang it in your team room, so that everybody can see them. If a item on this list is done, put a check behind it. Another approach is, to add the tasks of your retrospective to your Sprint Backlog.
I hope this list is helpful. If you have other ideas to improve your Scrum meetings, I’d appreciate a comment. Stay curious!
Watermelon Reporting
4360 days
This is what Wikipedia writes about the watermelon:
The Watermelon (Citrullus lanatus (Thunb.), family Cucurbitaceae) can be both the fruit and the plant of a vine-like (scrambler and trailer) plant originally from southern Africa, and is one of the most common types of melon. [...] The watermelon fruit, loosely considered a type of melon (although not in the genus Cucumis), has a smooth exterior rind (green, yellow and sometimes white) and a juicy, sweet interior flesh (usually pink, but sometimes orange, yellow, red and sometimes green if not ripe).
Watermelon (Citrullus lanatus (Thunb.), family Cucurbitaceae) can be both the fruit and the plant of a vine-like (scrambler and trailer) plant originally from southern Africa, and is one of the most common types of melon. This flowering plant produces a special type of fruit known by botanists as a pepo, a berry which has a thick rind (exocarp) and fleshy center (mesocarp and endocarp); pepos are derived from an inferior ovary, and are characteristic of the Cucurbitaceae. The watermelon fruit, loosely considered a type of melon (although not in the genus Cucumis), has a smooth exterior rind (green, yellow and sometimes white) and a juicy, sweet interior flesh (usually pink, but sometimes orange, yellow, red and sometimes green if not ripe).
For my metaphor, I’ll use the one with red flesh but orange and yellow would work too. I think most of us experienced the phenomenon when the project status is red but is getting greener and greener when climbing the management ladder. The project’s core is red but for the management it has a nice green paring, so it looks like a watermelon. This is why I call this phenomenon Watermelon Reporting. But why are we creating such reports and how can we avoid it?
Why?
The bearer of bad news already had a bad time in the ancient world. If he was lucky, they gave him the chop but in other cases they simply chopped his head of. This hasn’t changed until now but fortunately only in a figurative sense. Some bosses aren’t interested that there are problems with a project in their responsibility because if they know about it, they are in charge. So what do they do to avoid incurring the wrath of their boss ? They tweak the project status just a bit and the melon starts growing.
Another reason could be that nobody wants to be in the focus of management, thus they embellish the project status in the hope that everything turns for the better. And as we all know hope is the last to die.
In the end the result is the same.. Eventually the overripe melon bursts and there is no rescue for the project anymore.
How to avoid it?
The answer is easy: Transparency, transparency and transparency. If there is no way to hide the current status the watermelon can’t grow. Fortunately Scrum and other agile frameworks provide tools like burndown charts and backlogs to help the team with their transparency. But there are also tools like dashboards or kanban boards to do this job, but this will be the subject of one of my next blog posts.
Conclusion
The nuts and bolts of any project are transparency. If the project status is transparent, the watermelons can’t arise. If anybody is able to get the information, it will be difficult to hide something.
Don’t be a Scrum Zombie
3508 days
Inspired by the slide “Don’t be Scrum Zombie” from Henrik Kniberg’s Keynote at Scrum Gathering in Cape Town I want to talk a bit about the Daily Scrum. Because IMHO the Daily Scrum is the most underestimated Scrum meeting.
Every Scrum team knows the most famous 3 questions asked at the Daily Scrum:
- What did you do yesterday?
- What will you do today?
- Is anything in your way?
For some teams this meeting is just an annoying duty and because of that the questions are answered passionless. One thing that I observed in the last weeks and month is how the questions are weighted. The first question about the last working day is answered in every detail while the second question is answered quite short and if the third question is answered at all this is only done by stating that there are currently no problems. So the biggest part of the meeting is about talking of the past. The future and the impediments are just ignored. IMHO this is a big problem and should be avoided.
What did you do yesterday?
The answer to this question doesn’t has to be a detailed list of all tasks you’ve done yesterday. Also it isn’t meant to find out who finished the most tasks and was apparently the most hard-working team member. In short the point isn’t to create a report for the ScrumMaster, Product Owner or a stakeholder. Instead the answer should only contain information that is beneficial for all team members and important for the rest of the sprint. In this way the information is interesting and valuable for all team members, everybody listens and benefits from it.
What will you do today?
Often this question is answered with a simple “I’ll continue working on…”. This has nothing to do with a tactical approach. Every team member should mindfully observe the meeting and contemplate what’s the next reasonable step to support the team in reaching the sprint goal. Especially team members of new Scrum teams tend to think about their own tasks instead of thinking and working as a team. It isn’t important to start working on all tasks of the Sprint Backlog but to work on the tasks one by one together. At best two team members are working on one task simultaneously by using techniques like pair programming. This is why the Daily Scrum is also the perfect place to decide who will pair with whom. The Daily Scrum is a small planning meeting this is why you should use it like this.
Is anything in your way?
Interestingly this is the most unanswered question of the three. In the end all of the hidden problems pop up in the Sprint Retrospective even though they could be solved during the sprint. But to be able to solve them somebody has to name them. The reasons for this behavior are manifold. Some team members believe that their ScrumMaster isn’t capable to solve their problem. The other team members are just used to solve their problems on their own. But especially these hidden problems and impediments are often the ones that are the cause for a missed sprint goal. Only if everybody knows about what is in their way the team is able to kick it out of their way towards the sprint goal.
So don’t behave like a Scrum zombie. The Daily Scrum isn’t an annoying duty but a chance to do the next step in direction sprint goal.
The managing ScrumMaster
2614 days
A common problem in Scrum implementations occur when the former project manager becomes the ScrumMaster in your Scrum project. I call this the phenomenon “The managing ScrumMaster”. But why is it such a problem?
From push to pull
One of the biggest changes when introducing agile methods like Scrum is the procedure of how the different tasks are assigned. In most non agile projects it is the project manager or even worse other stakeholders who assigns the tasks to the team members. This is the so called “push” principle. In agile projects this is completely different. Here the team members decide on which task of the sprint backlog to work next. This is called the “pull” principle. And that’s were the problem with former project managers start. The team is used to ask his project manager what to do next so they will ask their new ScrumMaster and he will eagerly answer and assign a new task to them. This makes it extremely difficult to switch from push to pull. But if the team is not able to switch to pull they won’t benefit from the main advantage of agile methods: the self organization of the team itself.
One possibility to solve this problem is silence. Yes, silence! If a team member asks the ScrumMaster what to do next just hush or tell them to have a look at the sprint backlog by themselves.
Reports instead of planning in the daily scrum
Similar problems also occur in the daily scrum. If the ScrumMaster is the former project manager the team tends to report what they’ve done. In worst case the ScrumMaster has a clip board in his hands and is asking each team member the three questions while noting everything. Of course this is not the way a daily scrum should be. Instead of reporting to the ScrumMaster the team has the mission to clarify what to do today to accomplish the sprint goal at the end of the current sprint.
A possible solution for this dilemma could be that the ScrumMaster doesn’t attend the daily scrum in the beginning. Of course he has to make sure it happens. Another possibility would be to use tokens during the daily scrum. This token works a circuit (or randomly) and the team member who has the token speaks next.
ScrumMaster “only” accountable for the Scrum process
A former project manager is used to lead his team, define project plans, milestones and the content of each release. But as ScrumMaster the “only” thing he is accountable for is the Scrum process. Sure, this is a complex challenge but something completely different. It is clear that it is hard for a former project manager to keep his hands off such things. Problems are preprogrammed.
From my point of view a role that betters fits to a former project manager is the role of a Project Owner. Most duties and responsibilities are the same. It is clear that if you want to be the Product Owner you need to know the domain of your product and you’re able to define valuable features. But that’s the content of a different blog post.
Former project managers may be a problem in the role of a ScrumMaster but if you know them you can prepare yourself.
Anybody faced similar problems with former project managers? Just add a comment.
Recent comments