agile, scrum, coaching, lean
Scrum
5 Steps to Introduce an Agile Tool
8269 days
http://www.flickr.com/photos/jrvogt81/4264575563/
There are tons of agile tools out there. Just have a look at this looooooong list on Mike Cohn’s site. But what is the best way to introduce such a tool in your team or company? I collected the following steps for you.
1. Start with no tool at all
A fool with a tool is still a fool. Before you introduce a highly sophisticated agile tool, you need to know how Scrum, XP, Kanban or any other method are working in your own context. If you use a tool right from the start, you won’t follow the process that best fits your situation, but the process the tool dictates. Every agile tool has it’s own understanding, how to implement Scrum or Kanban.
2. Use pen and paper
You don’t need a full blown agile collaboration tool to start your agile journey. All you need is a white- or cardboard, some super stickies and pens. That’s it. If you’re working in a collocated team, this is all you need. No distracting electronic tools and no fiddling around how to get this thing working. This is the best way to find out, how to implement your agile frameworks. When you understand, what agile is all about and how to adapt to implement it, that it fits in your context, it is time for step 3.
3. Start with the simplest possible
If you still think you need an agile tool, start with the simplest possible. You can set up a Kanban board in 15 minutes with Google Docs. Or use another simple card based tool like Digaboard, Flow or Linoit. Most of them are free, at least for small teams. The main advantage of those tools is that they don’t follow a certain process, and you can easily adapt them to yours.
4. Choose wisely
You’re still here? So I guess that you still think you need a “real” agile collaboration tool? Than choose wisely! As already mentioned, there are a lot of tools out there. If you followed step 1, you know what your agile process looks like. You need a tool that is easily adaptable to your process. Don’t become a slave of the tools process! If you can’t adapt the tool, skip it. Don’t hurry, when selecting the tool. You’ll probably have to work the next decade with it. That’t why it has to be the right one.
5. Get a training
After you chose a tool, it is important that everybody in your team gets trained. It is important that everybody knows how to use the tool. Nothing is more drowsy than a ScrumMaster fighting with the tool during a Sprint Planning. The tool has to serve you, not the other way around.
Conclusion
IMHO a full blown agile tool only makes sense, if you work with a distributed team. In all other cases, it decreases the productivity instead of increasing it. At least that’s my experience. I’m looking forward to yours, so please leave a comment.
7 Agile Sins
6340 days
http://www.flickr.com/photos/throgers/2891142432/
There are still a lot of people out there who believe, that agile methods are the silver bullet to all their problems. This leads us to the 7 agile sins, that I collected in this post. Let’s have a look at the 7 agile sins (I’m sure you’ll be able to add some more in the comments).
1. Stop learning
You think you know what Scrum is and how it works. That’s why you think you can stop learning new things, am I right? Wrong! Learning is an integral element of agile methods. If you’re open for it, you’ll learn something new every day. The inspect and adapt cycles are not for nothing. If you don’t learn from your experience, every agile implementation will fail.
2. Don’t listen
Or don’t start listening at all. There are some people out there, who think that only their opinion is worthy. It doesn’t count what other people are saying. But as the self-organizing team is the core of every agile implementation, listening is an important trait. Most of the time is more important than anything else. If you don’t listen in a Daily Scrum, it is a waste of time. Of course, the same applies to any other meeting.
3. Stop thinking
Yes, the agile manifest, Scrum, XP, Kanban etc. were created by smart people. But this doesn’t mean that they know everything. At least there is one thing they don’t have a clue about, and this is your current situation. Most of the time it is a good idea to start by the book (at least if you’re new to agile), but don’t stop there. Some things may not fit in your situation, your company or for yourself. Start to think what can be adapted, but still keep the agile core values in mind.
4. Be dogmatic
Unfortunately, there are many dogmatic Scrum teams out there. But being dogmatic has nothing to do with being agile. There is a real life out there, a real project and (what a nasty surprise) real people. When you have a product in production and it crashed, you can’t just sit there and say: “Sorry, we are in a Sprint. Just put it in the Product Backlog, we’ll care for it in the next Sprint”. I bet your customers won’t appreciate such a behavior. Instead, you have to inspect such cases, and adapt your current processes and behavior to be able to handle such requests. Use what fits to your situation and don’t be dogmatic. It’s more important to live the agile values and principles, than to stick what’s written in some book.
5. Ignore the agile values and principles
I saw teams out there behaving like Scrum zombies. They follow all the rules, schedule and attend all of the Scrum meetings, but still don’t get any benefits. Most of the time it’s simply because they ignore the agile values and principles. There are a lot of agile values out there, because most methodologies define their own (Scrum, XP, Agile Manifesto). But in the end there are a lot of analogies. If you don’t know why you are attending a Daily Scrum, and what the value is, it won’t work. Of course, the same applies to all the other things you do in an agile team. Without accepting and living these values and principles, you’ll behave like a zombie and not more.
6. Misuse the agile toolkit
Most of the agile tools and practices are simple to explain but difficult to implement. That’s why there are a lot of great coaches around 
I saw a lot tools misused, but one of my favorites is the Daily Scrum. Often it is used as a reporting tool. But that’s not the intent of the Daily Scrum. IMHO it’s a smaller version of the Sprint Planning (see “Don’t be a Scrum Zombie”). What I also saw a few month ago, was the misuse of the sprint backlog in a team. The former project manager went around, to track what each of the team members was doing. And even worse, he confronted some of them with their performance, because they finished fewer tasks than the other team members. Primarily the sprint backlog is a tool for the team, and not for the management or the PO. Use every agile tool like it was intended and don’t misuse them.
7. Ignore the transparency
This sin I saw a lot of times, and it’s one of the most evil. Contrary to other opinions, Scrum and other agile toolkits won’t solve your problems. They will make them visible. It’s up to you and your team to handle this transparency and act accordingly. I know there are people out there, who love to close their eyes and ignore what’s happening around them (see also my article about watermelon reporting). If they know about a problem, they have to do something about it and are not able to blame somebody else. But ignoring the problems won’t help you. You have to cope with the truth and act accordingly. In the past, you were able to set a deadline in your ivory tower, but know an agile team is able to question such a deadline, based on their velocity and the size of the backlog. You can ignore that you won’t make it, or you try to find a solution for it. In short, if you want to be agile, you have to embrace transparency.
I know there are even more sins out there, and I’m looking forward to yours. Please leave a comment, thanks.
Kaboom – Blow up your watermelon
2397 days
This is the video and the corresponding slides of my talk “Kaboom – Blow up your watermelon” at the ACE! conference in Krakow. You can read a retrospection of the conference here. Enjoy!
And here are the slides:
How to defend against the 10 things that drive your ScrumMaster crazy
6590 days
During my time as ScrumMaster I collected an interesting list of bad behavior in Scrum teams called the “10 things that drive ScrumMasters crazy”. At the same time I started thinking about what I could do about it and how to stop the dysfunctional behavior in my team. I searched for the causes of the different behaviors and I found a lot. But what you tend to see at first is only the surface and not the real reason. That’s why I began to dig deeper to find the real cause. In the end I found out that everything can be condensed to four root causes. I call them “The four evil root causes from hell”:
- Ignorance
- Fear
- Indolence
- Apathy
Ignorance
I met teams were the only Scrum training they got was the link to the Scrum article on wikipedia.org. It’s no wonder that they don’t know how to implement Scrum if there’s nobody to train or coach them. Sure, there are some rare teams were wikipedia may be enough but most teams new to Scrum, especially in bigger organizations are in need for some initial training and at least somebody who has some experience with implementing Scrum. E.g. if a team member is doing tasks that are not part of the Sprint Backlog because Harry Smith* told him it may happened because nobody told her that it is the job of the ScrumMaster to stop these disturbances. It’s the same with hidden impediments. Most of the time they are not hiding their impediments on purpose they just don’t know that they can bring it to the team or ScrumMaster. There are several other things on the crazy list that are caused by ignorance.
Overcoming this root cause is relatively easy: Train and coach the team! When I start with a new Scrum team I’m using a special recipe. You can read about this recipe here: “How to kick off your new Scrum team”.
Fear
Fear is not only a problem in software development (Oh, really?). Fear can be a problem in any domain or private life. In software development it’s primarily the fear of change, the fear to learn something new or the fear to lose control. If a team member don’t want to work on a task because it doesn’t fit in what he was doing in the past it’s mainly a fear to leave his comfort zone. If the team member doesn’t want to split his tasks into smaller ones it’s maybe because he has the fear to be tracked. Or if a team member always asks the ScrumMaster what to do next she may have the fear that she won’t be able to solve any of the tasks in the sprint backlog, Fear can be the reason to a tremendous amount of dysfunctional behavior. And that’s why fear is one of the evil root causes.
A few years back I was working for Volkswagen. After one year as employee my manager told me that I’ll attend a training called “Self organization and self management”. When I talked to other Volkswagen employees about this training I was faced by a lot of rumors. They told me that this is a real tough training and that several attendees canceled the training because they could not stand the psychological pressure. Now I was curious The first day of the training started and nothing special happened. But in the evening of day 1 they came up with the rules for the next 3 days: Everybody has to do something which is out of their comfort zone. The procedure was like this: When you think you are ready for your “Performance” you have to stand up and say load “Performance”. After that the other attendees are clapping their hands. Then you start doing whatever is challenging for you. It was up to the attendees when they start their “Performance”. Interestingly most of the attendees did their “Performance” before lunch. We had people praying with us, reading books (everybody laughed at him in school), dancing and so on. And now guess what I was doing? I did a presentation in English. At this time it was a real challenge for me and completely out of my comfort zone. But after the 3rd presentation in English I started to feel comfortable. I increased my comfort zone. If you like I’m a living example that this method worked. This is why I still believe that this methods work. So kick your team mates out of their comfort zones
Indolence
Ever tried to move a car were the motor is broken? You have to put a lot of energy into pushing the car to get it moving. It’s the same with indolent people. They are sitting at their desk or standing at the coffee machine and are just doing nothing. They don’t have the energy to get themselves started on a new task and instead they are procrastinating all day, week, month or even year. These people are late at meetings, won’t start to work on something new or doing any other stuff but their work. If you have such people in your team it won’t take long until other team members will complain about him. You have to find a solution to start their engines on a easy way to get them working with the team.
The following methods have been proven to work:
Get their commitment
It’s not only a phrase if the ScrumMaster asks the team in the sprint planning if every team member commits to the sprint goals. But sadly this is sometimes happening. Comments from team members are ignored or everybody is just nodding their head without really being committed. Get their real commitment, this is important. In new teams you could write an informal contract with the sprint goals that every team member has to sign. Put the contract on the wall of the team room so that everybody can see it.
Rotate the moderator role
In Scrum there is no rule that the ScrumMaster has to moderate all meetings. Instead rotate the moderator role. The sprint retrospective is a great meeting to start with this approach. Try it you’ll be surprised by the results.
Use Avatars
Every team member should have an avatar on the sprint backlog. With this approach everybody can see who is working on what. This helps the team to recognize if somebody is working on the same task for days and gives them the chance to check what’s the problem with it.
Involve them
I saw a lot of e.g. sprint plannings were one or more people didn’t really participate. They were just sitting around listening (or playing with their phone) instead of working with the team. If you recognize this behavior involve these team members. Ask them what’s their opinion on the current backlog item. Avoid that only 2 or 3 people are working on a new story. Involve everybody!
Apathy
Apathy is the most evil and most dangerous evil root cause of all. If their’s one team member getting apathetic you have to immediately do something about it otherwise it will spread like cancer. A apathetic team member is easy to recognize. He talks bad about the company, the project or the management. He doesn’t participate and nothing matters to him. It doesn’t matter for him to be late it doesn’t matter to him what is defined in the DoD and it doesn’t matter to him what the feedback is like in the sprint review.
Even if apathy is IMHO a root cause in most cases their is an additional cause which leads to this state. Often this isn’t an easy one. Start doing face-to-face interviews with every apathetic team member to find out what’s the problem. After you collected the data from everybody decide what to do next. If the reason is technical debt schedule a workshop to define how to cope with it. Build a vision describing how to solve the problem so that everybody sees that a real chance to overcome the problem. If you find out that their is a insulating layer between management and the developers I wish you good luck No serious, that isn’t an easy one and I can’t really tell you how to overcome this because this could mean a complete mind shift in the whole company which isn’t simple. It really depends on the management and if they are willing to change something.
You can also try to introduce an FedEx-Day or 20% time like Google or Atlassian. At Google every employee has one day in the week were he can work on whatever he likes. In this 20% things like GMail, Google Maps, Google Buzz or the Google Wave were created. If 20% sounds to much start with 10% (e.g. Friday afternoon) and try it for e.g 6 weeks. Do a retrospective after this time to find out if it had some benefit. You can read more about this in Daniel Pink’s book “Drive”.
Conclusion
There are no silver bullet solutions for the 10 things that drive ScrumMasters crazy or any other dysfunctional behavior. But their are some things you can try. Let me here if you had success with one of the suggestions above or if you solved on another way. Every feedback is welcome…
Here is a short ligntning talk I did a few moth ago about this topic. Enjoy!
How to Defend Against the 10 Things that Drive Your Scrummaster Crazy from ACE! Conference – Best Practices on Vimeo.
Here are the slides of my talk. Unfortunately Slideshare doesn’t like the color of the font:
Howtodefendagainstthe10thingsthatdrivesscrummasterscrazy slideshare
View more presentations from Marc Löffler.
Want to rate my talk? Go here:
Don’t be a Scrum Zombie
3612 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.
Recent comments