I used to attend the Agile Coach Camp Germany and the Play4Agile Unconference in Germany for the last three years now and I really liked people from other countries to attend these conferences. For this year I decided that I wanted to be one of those from beyond the border and registered for attending the Agile Coach Camp Denmark. Kristian Haugaard (@haugaards), one of the organizers, made me aware of ACCDK during the Play4Agile conference in February and I liked the idea that it took place from Thursday to Saturday, so that there was still the Sunday to spend with the family.
Introducing Scrum in a company usually consists of the following steps:
- Having a Scrum Basics workshop with as many people from the company as possible to make sure everybody understands the new way of working and is familiar with the basic terms and artefacts.
- Working with at least one team operatively as a Scrum Master, to not just tell them about Scrum but to actively live Scrum with them. Usually this comes with the role of an Agile Coach for the whole company.
As a Scrum Master as well as an Agile Coach I tell Product Owners from my particular perspective how to fill their role appropriately. But now something changed: Recently I became a Product Owner myself. This experience changed my perspective on the work of a Product Owner significantly.
While working with Scrum Teams I often notice User Stories considered done by the team, usually the acceptance by the Product Owner being the last step. But in fact in many cases none of the team members did a final check of the done criteria. Each team member expects that someone else has taken care of it and since the Product Owner accepted the story nothing is to be done anymore. During the Review suddenly something pops up which should have been covered by the Definition of Done. Continue reading
Recently I worked with some Scrumteams consisting partly of students, meaning they weren’t available every day of the Sprint, depending on their class schedule. So far during Sprint Planning I asked each team member for their availability during the Sprint (including vacations etc.) and the team based their commitment on this information. But when the Sprint started I noticed some uncertainty about missing team members within the team, e.g. when it came to the Daily Scrum. “Is Eric coming in today?” “Hmm, I’m not sure, isn’t he in class today?” “No, on Wednesday he’s usually in the office, but he might have mumbled something about exam preparation yesterday. Anyway, at least Mel should be around, right?” “No, Mel, took a day off spontaneously” “Damn, I didn’t know, I need her for a code review”. Continue reading
When in my trainings I reach the part about Product Backlogs and Backlog Items, I try to explain to the participants the reasons why Backlog Items just need a fuzzy description of a required functionality by showing them, that written requirements are usually far from perfect. The details will show up in the conversations between team and Product Owner. I use examples like “The appetizer will be served with soup or salad and bread” and ask the participants to choose their garnish to show the imperfection of the written word. As you probably can imagine there’s usually some confusion, because it’s not clear, if it’s “(soup or salad) and bread” or “soup or (salad and bread)“. Another example is a simple name input field with arising questions like “Is it mandatory?“, “What’s the maximum length?“, “Are special characters allowed?” and so on. But sometimes I get the feeling that there are some hardcore product managers among the participants who are still convinced they would be able to write the perfect requirements document (Let’s not discuss the time needed for that, please). So I thought about another example and found one in my own context which is a lot easier to remember (especially for men). Continue reading
A few weeks ago I was supposed to give a Scrum Basics workshop in France for a bunch of people who partly already knew the ballpojnt game and asked for another exercise instead. Fortunately I knew another way of demonstrating Scrum which I could use as a replacement: The Lean Workflow Design Game by Nancy Van Schooenderwoert. Nancy introduced and facilitated this interesting exercise at the Play4Agile 2011 Conference in Rückersbach, Germany. The goal of this exercise is to create and improve a workflow using some of the well known agile techniques like Sprint Planning, Timeboxing, Retrospectives. I got the ‘official’ rules from Nancy and will link to them here as soon as they’re available online. Due to some time restrictions I needed to slightly modify the original version from Nancy and will describe the modified version in this blogpost. During the workshop the participants had a lot of fun and were able to actively use the stuff I told the in the hours before. Continue reading
In most companies you find Product Backlogs prioritized by business value, as Scrum told us to do for several years. Since July 2011 the Scrum Guide softened this requirement, speaking of backlogs “often ordered by value, risk, priority, and necessity”. Either way you face the problem to have to split complex funtionalities into smaller ones and put them in a one-dimensional list. User Stories belonging to a certain Epic are usually not organized as a block but are interrupted by other Stories belonging to other Epics. Did you ever try to give your stakeholders the big picture just with your product backlog at hand? Or even just gave them the Product Backlog to read? No way. Some time ago Jeff Patton took care of this problem and came up with the idea of Story Maps. They offer the chance to show the whole product in a comprehensive way and make it much more easily explainable and discussable. With this article I would like to introduce the concept of Story Maps to you.
At the AgileEE 2011 Conference in Kiev I had the pleasure to host a workshop about estimation methods. The participants were quite excited, because the better part of them just knew Planning Poker and used it with and despite all of its limitations. We compared Planning Poker with the Team Estimation Game, which I discussed here on the blog some time ago (further links see below) and with Magic Estimation. While the Team Estimation Game has become more and more common over time and variations like Silent Grouping have evolved, Magic Estimation is not that common yet.
Let me explain Magic Estimation so you have another means for estimation in your portfolio.
The german version of this post can be found here.
If you start a new project with a customer you often need to organize the project environment by yourself. At least you have to make sure it fits your needs. Especially in Scrum projects you don’t want to waste time dealing with organizational stuff but start implementing nice features starting with the first sprint. Nevertheless I’m often surprised how badly prepared some teams get sent on the road and into their first sprint. It’s so easy to give your team a good start – just have a Sprint Zero before your first sprint and get all the organizational stuff from your plate. You avoid the usual problems like having no access to development servers, a developer who wants another screen, chairs that hurt your back and so on. Of course there’s no general Sprint Zero for all companies and projects, but perhaps the following example from my daily work provides an insight into what can be achieved. Continue reading
The german version of this post can be found here.
Last friday I found myself in a situation which triggered some interesting inspirations and thoughts, which I would like to share with you. When I leave home in the morning to go to work I need to get to the train station by bike, bus or car before I take the train to Hamburg. This weekend I wanted to participate at the Agile Coach Camp Germany 2011. Since I was supposed to work for half a day and then head to the Central Station to catch a train I opted for the bus in the morning. The bus stop is about 400m from my house and I can nearly see it as soon as I leave. I was quite surprised when I left the house and saw a bus pass, since it was still 2 minutes to go. I hurried to the bus station, hoping it had been the schoolbus being a few minutes late, but when I arrived there I realized that it had indeed been the bus I was supposed to reach. I got quite angry, planning to complain about the driver, and started to search my pockets for my cell phone to check the time again. Grooming through my pockets I found a binky from my two and a half year old daughter and suddenly my anger calmed down.