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.

56 thoughts on “7 Agile Sins”

  1. However, it has been proven that everyone needs some down time
    so they can just relax. It provides recording customization and captures parameters adjustment in order to help
    users record professional video in good quality. Things are easily explained when there is an accompanying presentation that people will directly see.

    my web site read webpage (http://www.youtube.com/)

  2. First off I would like to say awesome blog!
    I had a quick question which I’d like to ask if you don’t mind.
    I was interested to find out how you center yourself
    and clear your head before writing. I have had trouble clearing my mind in getting my ideas out there.
    I do enjoy writing but it just seems like the first 10 to 15 minutes are
    generally lost just trying to figure out how to begin. Any recommendations or tips?

    Cheers!

    My blog – where to get turmeric

Leave a Reply

Your email address will not be published. Required fields are marked *


*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Notify me of followup comments via e-mail. You can also subscribe without commenting.