Scrumphony - Everything that matters in the lean/agile world
agile, scrum, coaching, lean
Agile Eastern Europe 2010
Aug 13th
A lot of people read about the 10 things that drive ScrumMaster crazy. Now it is time to explain how to defend against these things. The first time I’ll talk about this will be at the Agile Eastern Europe conference which is held on 8-9 October 2010 in Kyiv, Ukraine. Even if you’re not interested and don’t even like Scrum there are plenty of other reasons to go there.
Great program: 2 days, 4 stages, 40 talks & workshops!
Master Classes (CSM, CSPO, Lean, Design) running by the key speakers!
More than 35 Speakers from 18 Countries
The keynote of Agileee 2010 are the stars of worldwide Agile stages:
- Mary Poppendieck is a pioneer in using Lean – lean approach to the software development process. The author of several books and teaching programs, key speaker at international conferences.
- Henrik Kniberg is an Agile/Lean coach with more than 15 years of experience in IT. The author of books – Scrum and XP from the Trenches and Kanban and Scrum, making the most of both.
Agileee’s geography goes far beyond the boundaries of Eastern Europe! Speakers are from all over the world: Jurgen Appelo (Netherlands), Robin Dymond (USA), Yves Hanoulle (Belguim), J.B. Rainsberger (Canada), Danko Kovatch (Israel), Robert Dempsey (USA), Vasco Duarte (Finland), Mack Adams (USA), and others.
Unforgettable atmosphere - sharing experience, professional contacts, a lot of fun and communication in the spirit of Agileee!
So even if you don’t want to hear me speak there are enough good reasons to go there. Visit agileee.org for more info and register.
What`s your favorite Agile Game?
Jul 15th
I recently attended the Agile Coach Gathering UK in Bletchley Park near London. I met a lot of interesting people, had some great talks and discussion and learned a ton. As the gathering was an open space conference I also proposed a session with the topic “What’s your favorite Agile Game?”. The goal was to collect some great games I could play in my next Scrum or Kanban trainings. A fun fact of this session was that everybody found out that we knew more games than we expected before. We came up with the following list of games.
P&Q
P&Q is not really a game but a collaborative process. The P&Q is a simple process which makes just two things; “P’s” and “Q’s.” The objective of the exercise is to make a decision as to how to best maximize the profit of this process. A more precise description can be found here.
The XP Game
The XP Game if one of the oldest and most known games in the agile community.
The XP Game is a playful way to familiarize the players with some of the more difficult concepts of the XP Planning Game, like velocity, story estimation, yesterday’s weather and the cycle of life.
A detailed description of the game can be found here. There are several variations of the game but my personal favorite is the LEGO(c) XP Game. I’m a big LEGO(c) fan and use any excuse to play with those bricks. Here are some photos of a team playing this game. I highly recommend this game to any team new to agile.
Scrum from hell
Scrum from hell is more a role play than a game and simulates a dysfunctional daily scrum meeting. It is always fun observing the participants playing the roles. The duration of this game is only 15 minutes and a must for any Scrum training. A description of this game can be found here.
The communication game
As I don’t have the real name of this game I just named it this way. This game is all about communication. The following roles are part of this game:
- Client
- Business Analyst
- Architect
- Developer
In the first round nobody is allowed to speak. The client describes his requirements as written document to the business analyst and the BA passes on what he did understand to his architect and finally to the developer. As the info arrives at the developer he starts to build what he understood. When he is ready the review starts. In most cases the client don’t get what he has expected. In the second round everybody is allowed to speak and ask questions. In most cases this leads to a product the client asked for. If you have some more info about this game or even some artifacts, leave a comment.
The ballpoint game
This game is also one of my favorites. It’s about passing as many balls as possible between the players during a given time. With this game the concept of iterations/sprints and retrospective are explained. I already posted a more detailed description of this game in my blog which can be found here.
Making paper hats
In this game the concepts of velocity and iteration/sprint are explained. The main goal is to map the planned amount of paper hats with the actual amount. This game can also be played by blowing balloons or any other simple task. The customer in this game tries to push the development team to build as many paper hats as possible during an iteration. The result is that most of the build paper hats are useless as the quality is quite low. The customer keeps pushing until the team realizes that they are only able to build x paper hats during one iteration in the requested quality. Now the team knows his own velocity and is able to negotiate with the customer on the maximum number of paper hat. Another outcome of this game is that the player realize that quality is not negotiable. If someone has a link to a more precise description, please leave a comment.
Other games
There are a lot of agile games online. During the session I suggested the following places to search for additional games:
- http://www.tastycupcakes.com – This is a great resource for agile games. I highly recommend to have look here
- http://www.kanbangames.net – On this page you’ll find some games explaining the concepts of kanban and lean software development.
- AgileGames on Google Groups – If you’re interested in the newest games or want to discuss about games, this is the place to go. Come and join our group.
If you have any other resources or any other addition to this blog post, feel free to leave a comment.
10 things to drive your ScrumMaster crazy
Jun 14th
In my life as ScrumMaster I faced many things which drove me nuts. So here is my top 10 of things that at least drives me crazy:
- Keep doing tasks that are not part of the sprint backlog.
- Hide your impediments. They will for sure vanish on their own.
- Don’t talk to the PO during the sprint. Never.
- Ignore the definition of DONE when finishing your tasks and backlog items.
- Stand in front of the sprint backlog and say “I’ve nothing to do” or “None of the tasks are for me” (even better if 90% of the tasks are still open).
- Prepare for the Sprint Review 5 minutes before it starts.
- Don’t split your tasks into smaller ones even if you know they will take the whole sprint.
- Be late, always.
- Ask the ScrumMaster continuously which task you should do next.
- Disturb any scrum meeting by starting multiple additional discussions on different topics.
Here are the slides if you like to present it to your team 
Finally here is the video of my first lightning talk ever at the Agile Central Europe in Krakow, Poland, where I talked about these things. Have fun 
Lighting Talks 1 from Krakow Tech Conferences on Vimeo.
I know this list is incomplete and so I’m waiting eagerly for your comments what drives you crazy.
The managing ScrumMaster
Jun 2nd
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.
How to mess up your user stories
May 27th
User Stories are more or less the standard format for managing your product backlog in agile projects. So this is my trigger to let you know how to completely mess them up I collected a short list of my favorites, let’s start.
Missing Roles
Don’t define any roles! It is much more fun to write a user story from the view of a generic user. Don’t waste your time to define all these useless roles. If I write a story about the possibility to delete any user from the database it should be clear for anyone that I was talking about some kind of admin.
Loooong and detailed descriptions
Try to write your user story description as long and as detailed as possible. Put all your details and acceptance criteria into the description. A perfect user story description should look like this:
As user I want to edit the profiles of the user by switching to the admin dashboard and viewing the list of users. With the right-mouse click on one of the user entries a context menu opens were I'm able to select "Edit User Profile" by clicking the left mouse button. A dialog opens [.... blah blah ....] because it may happen that the data of a user changes.
With these kind of user story description there is no need to write any acceptance criteria or start long discussions. You only have to read the description and everything is right there.
Write detailed right from the start
Forget about epics or “big” user stories. Forget about well formed product backlogs were everything on the top is detailed but the backlog items in the middle or at the bottom are more or less unspecified. Write your user stories as detailed as possible right from the beginning. Hey, you’re the product owner you know how your product will look like in the end you don’t have to wait.
Promises are there to be broken
“A promise for conversation”? You need to discuss your great ideas with the dumb developer folks? Then you have to work harder! Take your time to write every single story so that there is no need to discuss anything. Ignore the fancy ideas from you customer, ignore the disturbing ideas from your development team. Again: You’re the product owner, you know you to built great products. If you write a user story it is carved in stone!
Ignore the INVEST model
You know the the INVEST model? Whos idea was it to define such useless features for user stories?
- Independent: It is not possible to write independent user stories, believe me. Don’t waste your time trying to split or combine user stories to get independent ones.
- Negotiable: Ehm no. Your user stories are not negotiable at all. You’re the master!
- Valuable: If the user story produces some work for your development team it should be valuable enough!
- Estimable: Estimable? Why? You already estimated the whole product backlog. There is no need for anyone else to estimate YOUR user stories.
- Small; A user story is small enough if it can be printed on 10 DIN-A4 pages!
- Testable: Documentation over running software. Do I need to say more?
That’s it for now. If you follow the above rules you’re on the right way to mess up the whole user story fuss. Did I forget something? Don’t hesitate to write a comment
Open Session: Tai Chi/Zen & Team
May 1st
The first OpenSpace session for me today was about Thai Chi and the influence on the team. Christine Neidhardt did some interesting and simple Tai Chi exercises with us and a discussion afterwards what we felt. We started to stand in a circle and focus on ourselves. When we were ready to start we went into the circle and bow to let everybody know that we appreciate that they are also participating. After this introduction we did the first exercise. We took each others hands and started a “La Ola” wave. The challenge was to get a real smooth “La Ola” wave through going round the whole circle. The next and for me more interesting exercise was the following: Clap your hands one after another around the circle and find the rhythm of the team. We got a smooth rhythm with some disturbances in between but after some practice we were able to overcome these and continue with our rhythm. In the last exercise we stood in a line without seeing each other. Christine was starting a movement with her arms which went through the line and back. The first movements were quite easy even if I were the blocker in the first round but it should have been easy because you were able to see the arms of the people in the corner of your eyes but the last movement was really difficult to recognize. You had to try to feel when it’s time to continue the movement without seeing it. Really interesting experience. After the exercises we sat together discussing what we felt during out Tai Chi exercises. You can see the results on the flip chart.
7 things to sabotage an AgileCoachCamp
May 1st
I’m currently participating at the Agile Coach Camp Germany 2010 in Rückersbach near Frankfurt. As some of you already know I’m a lightning talk addict and so I couldn’t resist to do a one this eve
ning. After a bunch of great talks I did my talk on the topic “7 things to sabotage an AgileCoachCamp”. Here is my list:
- Don‘t propose any topics for the open space sessions.
- Ignore the facilitator
- Disturb any sessions by continuously asking questions that are not related to the session topic.
- Don‘t participate on any games. You‘re not a child anymore.
- Talk on your mobile as loud and often as possible.
- Leave, now!
- Don’t talk at all.
I didn’t use slides but if you need some, here you are:
Here is the video of the talk. Have fun :
ACE 2010 – Confession of a lightning talk addict
Apr 19th
Yes, it’s true I’m a lightning talk addict. How that happened? Well, that’s how the story goes:
Day 1
Two weeks ago I attended the Agile Central Europe in Cracow, Poland. I arrived in the late evening the day before the conference and wanted to met Pierluigi Pugliese for dinner. As Pierluigi already started dinner with the other speakers he invited me to join them. Besides that I nearly sat on the brand new iPad of Paul Klipp (sorry for that ) I had the pleasure to sit between Thomas Sundberg and Robert Dempsey and had some great conversations. After dinner we went back to the hotel sat in the lobby and talked till midnight.
Day 2
This day I met for breakfast with Robert. And that’s where it happened, where everything began. It started with a tiny little question Robert asked: “When is your talk?”. “Hmmm” I mumbled, “I do not talk at all.”. “I thought you are also a speaker as you sat together with us for dinner yesterday evening.” Robert said (hope he will pardon me for not using the exact words…). And that was the time when the idea was born to do a lightning talk. As I didn’t prepare anything I decided to do a talk based on one of my blog post: “10 things to drive a ScrumMaster crazy”. I went up to the lightning talk flip chart and added my talk. Then I registered for the conference at the registration desk which went really fast. Thanks to the guys of Ekobilet no waiting line at all. The conference started with a great keynote of Rachel C. Davies about retrospectives. As this is my confession I won’t dive into the details The next talks I attended were “An an intro to Software Craftsmanship movement” by Maria Diaconu and Alexandru Bolboacă (were I get some great new ideas to resolve our current development problems), “Clean Code” by Thomas Sundberg, “The Invisible Coach” by Mack Adams (I still wait for the *poof* at the end of his presentation ) and last but not least “Making Scrum Stick: Sustainable Scrum Transitions” by Simon Roberts which for me was the best talk of the first day. In between I prepared 12 slides for my first lightning talk ever.
My first lightning talk
Then it was time for my lightning talk. As the first entry on the flip chart was skipped I had the one and only lightning talk of day 1. I was quite nervous when I connected my laptop with the beamer and just curious if the audience would like it. After the stage-fright went away I started to enjoy talking. After about 2 minutes I started to love talking and at the end I got addicted to it. Some people who know me for a bit longer may say I was addicted to talk even decades before but who cares Thanks to the audience for positive feedback in personal and twitter! As soon as the video of the talk is available I’ll post it here.
Day 2 ended with a great dinner, a lot of deep conversations and of course the idea to do another lightning talk…
Day 3
Day 3 started with the preparation of my next lightning talk. Robert Dempsey and I thought that the ScrumMaster has to be able to pay pack what the team did to him. So the topic “10 things a ScrumMaster can do to drive the team crazy” was born. I did a fast brain storming put 12 slides together and went to bed. After some hours of sleep I went down for breakfast together with Paul Klipp and Robert, added my next lightning talk to the flip chart and dove into the new conference day. I attended “Solution Focused Agile Coaching” by Pierluigi Pugliese were I got some great new insights (Thanks, Pierluigie), “Beyond Agility” by Andrea Provaglio, “Distributed Agile in a Multicultural World” by Robert Dempsey and last but not least my favorite talk “The Sword And Other Tales” by Gwyn Morfey and Laurie Young. Besides the great content and new ideas the talk performance which was some kind of impro theater was awesome!
My second lightning talk
As the first entry on the lightning talk flip chart was skipped again it was my turn to start with the lightning talks. There was it again: the stage-fright. I breathed deeply and started with my talk and before I was aware that I was already talking the 5 minutes were over and the talk ended. It was so much fun to talk to such a big audience. Unfortunately I had to leave the conference immediately after the second lightning talk to catch my plane back to Germany (at this point in time no volcano ash in the air )
The Agile Central Europe was my first agile conference and I enjoyed every single minute. I’m already looking forward to Agile Eastern Europe in Kiev and of course to the lightning talks. See you there…
How to kick off your new Scrum team
Apr 13th
I’m currently working on a recipe on how to kick off a new Scrum team that is completely new to agile practices and Scrum. After some iterations I came up with the following recipe. The ingredients:
- 1 team
- 1 team charter
- 1 team room
- 1 experienced Scrum coach
- 1 Scrum training
- at least 1 whiteboard or pinboard
- at least 1 flip chart or flip chart paper
- a lot of post-its and din a6 cards
Train and coach the team
First of all you need to train the team. From my point of view this is the crux of this recipe. It is important that every team member knows the elements of the Scrum framework and even more important why Scrum or other agile processes are working. If they don’t understand the principles of agile software development the team will fail. You don’t have to send the whole team to a CSM or CSPO training but it is no disadvantage As we have an experienced Scrum coach in our ingredients we can do in-house trainings and accompany the team through the whole process.
Create the team charter
The next step in our recipe is to create the team charter. The team charter defines how our team is working together. It defines the communication rules, code of behavior, the development tools used, the time and location of the Scrum meetings and one of the most important things: the “Definition of Done”. As the name implies the team charter is build by the team itself. To create the team charter a dedicated meeting is scheduled were all team members attend. Creating the team charter is a perfect way to boost the team building process. I prefer to create the team chart on flip-chart paper so that it can be easily put on the walls of the team room. If you need some input for your team charter, have a look at the great presentation of Simon Roberts called “Effective Team Chartering”.
Collocate the team
Latest now it is time to collocate the team into one team room. I know that this is not possible in every building without excessive reconstruction of the room structure. So if you can’t place all team members into one room they should at least sit on the same floor. This is really important if you want a hyper productive team. The more the team is spread the less is the productivity. So if you’re one of the lucky ones able to put everybody in one room I prefer the following setup. The room should have enough space for the team members, the sprint backlog, the burndown charts, the team charter and some space at the walls to be able to put some flip chart paper on them. This environment supports the communication and creativity of the team and therefore the self-organization.
Now your team is ready an eagerly waiting for their first sprint. This is my current recipe but I’m sure that it’ll change over the next weeks and month. What is your recipe? Comments?
10 things a Scrum Master can do to drive their team crazy
Apr 12th
You are a ScrumMaster, you hate your team and you want to give back what they did to you? Try these 10 things and you will be overwhelmed by the success
- Be unaccessible for the team. Is the team self-organizing or not?
- Ignore their impediments they will vanish by itself
- Always schedule the Scrum meetings at different time and location. Your team loves suprises.
- Don’t protect your team.They are adults and don‘t need a babysitter anymore.
- Schedule the Scrum meetings as early or as late as possible.
- Lead the daily scrum by asking each team member the 3 questions and take notes
- Keep asking the team members to do things which are not planned for the current sprint
- Ignore any ideas from your team during the retrospective. You know best what to improve next.
- Always tell the team members what task to do next
- Be late, always.
You want to have slides for these items? Here you are:
Thanks to Robert Dempsey (@rdempsey) the talk is also available as video. Have fun.
Any other ideas on how to torture your team? Let me know.
Recent comments