Tag Archives: kanban

5 Steps to Introduce an Agile Tool

Toolbox

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

Sin

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.