Agile Coaching

Penitence For The 7 Agile Sins

2
Penitence

http://www.flickr.com/photos/21561428@N03/3734800195/

Half a year ago I wrote a blog post about 7 Agile Sins. As I’m sure, that I’m not the only one who is guilty for one or more of these sins, I collected a list of possible ways to show penitence and to do it better next time :) So here is my list of the sins and their appropriate penitence.

Stop learning

The first way for showing penitence is to help to create a learning environment in your company. One possibility to do this is to introduce so called brown bags. This is at least one corner stone to foster learning and bring new ideas in your working environment.

Don’t listen

Listening is a fading skill in our society. Most men know at least one situation where their girlfriend shouts at them, because they didn’t carefully listen. But hey, there is help underway. Listening is a skill you can learn. There are a lot of great books out there on how to become a better listener. One of them is “The Art of Active Listening“. It’s a quite short one and a good starting point to improve your listening skills.

I also recommend listening to the TED talk of Julian Treasure “5 Ways of Listen Better”. One of the things I found valuable is the acronym “RASA”. It’s the Sanskrit word for essence. The single characters have the following meaning:

  • Receive
  • Appriciate
  • Summarize
  • Ask

If you keep this acronym in mind during your next conversations, it will help you to get a better listener. So one way to show penitence for this not listening is to learn to listen.

Stop thinking

This is simple. Start thinking! I know, the guys behind XP, Scrum and Kanban are keen thinkers. But you know what: They don’t know your context. So, before you blindly follow “the book”, try to understand WHY you are doing these practises. Show your penitence by doing the following: Map each of the practises you use to one or more agile values and principles. This will be the first step on your journey to understand the theory behind the agile frameworks.

Be dogmatic

Your penance for this sin is to look beyond your own nose. There are still agilists out there who believe, that there were no successful projects before agile frameworks came in. Fortunately this isn’t true. There are a lot of successful “waterfall” and V-model based projects that were successful. And there was one entity that collected best practises and created a book out of them. So your lesson to show penitence for this sin, is to read the PMBOK (Project Management Body Of Knowledge). I’m sure, even as hardcore agilist you’ll find some valuable things in this book.

Ignore the agile values and principles

There is a great exercise described in the book “Coaching Agile Teams” by Lyssa Adkins name the “High Performance Tree”. Lyssa also created a short Youtube Video where she describes how to create such a tree. This tree has many functions. One of them is to use it as part of a retrospective. You can ask questions like “Why did x happen last sprint? Where were our roots weak?” or “On what of our high performance traits do we want to work in our next sprint?”. As the tree should be placed on one of the team’s walls, it is always visible and part of the team’s daily business. To make a long story short, your exercise to show penitence for ignoring the agile values and principles, is to draw a “High Performance Tree” together with your team, put it on you team’s wall and use it in your next retrospective.

Misuse the agile toolkit

I’m sorry but for this sin there is only one way to show penitence: Go get a priest. In our case this means to get help from an experienced coach. I have this opinion because IMHO this happens especially in inexperienced teams. I had teams that were only “trained” by reading the Wikipedia entry on Scrum. It’s quite clear that there are some misunderstandings in the beginning. But also other teams benefit from an experienced coach, who will help them to understand how to use the agile toolkit correctly.

Ignore the transparency

IMHO this is most deadly sin of all. There is a simple way to overcome this sin: Be even more transparent! Don’t put your backlogs and boards into an electronic tool. Make it visible. Put it on the walls, but not only in the team’s room, also on the floor or near the management’s offices. In one of my last projects we used a so called “master board” to foster the “Scrum of Scrum” meeting every morning.

Masterboard

Masterboard for 5 Scrum teams

 

Each row represents a team and the cards on the board only show on what the teams are working on User Story level. This really helped us to get the big picture of the whole project. Additionally we introduced a dashboard to show the project status using “traffic lights”.

Dashboard

Dashboard for the management team

In the upper left corner we showed the overall status for every planned release. All open issues were shown on the right upper corner. The left lower corner was used to show on what epics the teams are currently working on and last but not least, the lower right corner showed the already delivers epics. This way we were able to completely remove all status reports. Now the management was able to get the status on one single view. One way to show penitence for ignoring the transparency of your team would be to introduce a master board for your Scrum of Scrum meetings.

I hope you like one or more of my suggestions to show your penitence. I’m looking forward to your comments!

Food for Thought #9 – Be honest

6

http://www.flickr.com/photos/60852569@N00/2204909532/

Are you honest? Every time? To every one? In every situation?

Oh, come on, be honest! Most of us aren’t honest every time, everywhere and in every situation. And, to be honest, this isn`t implicitly bad. There may be situations were the truth isn’t appropriate (at least for the moment). But most of the time it is and the only thing that stops us, is our comfort zone. Unfortunately, the truth is not always positive; otherwise, it would be easy to tell. And so it is often a matter of leaving our comfort zone.

My wife is one of the honest persons I know. In the beginning of our relationship, it wasn’t easy for me all the time. I had to learn to cope with her straight honesty. But now I really love it. Most of the time I know the score, and that’s a great thing. What if everybody would be more honest? Wouldn’t this be great?

I bet every one of us knows a scene in a movie, where the main actor has to confess something, but he didn’t do it. In the end, everything escalated, just because he didn’t confess right at the beginning (OK, I know the movie will be crap if he does ;) ). But I’m sure if you think for a second, you’ll find similar situations in your life. For me honesty is also quite important in agile teams. Without honesty in your team, you won’t be able to benefit from Scrum, XP or any other agile toolkit.

Honesty is also important for your self development. The first step is to be honest to yourself. But to be able to evolve positively,  you need the honest feedback from other people around you. Without their help, you’ll fail. But it is also important to be honest to others. If they ask you for your honest feedback, give it to them. Stop beating around the bush even if it unpleasant some times. Most people will be thankful for this. And if you aren’t asked for feedback, give them uncalled feedback.

And now give me some honest feedback, because I want to improve my blog posts. Thank you!

My wife is one of the honest persons I know. In the beginning of our relationship, it wasn’t easy for me all the time. I had to learn to cope with her straight honesty. But now I really love it. Most of the time I know the score, and that’s a great thing. What if everybody would be more honest? Wouldn’t this be great? 

I bet every one of us knows a scene in a movie, where the main actor has to confess something, but he didn’t do it. In the end, everything escalated, just because he didn’t confess right at the beginning (OK, I know the movie will be crap if he does ;) ). But I’m sure if you think for a second, you’ll find similar situations in your life. Honesty isn’t for nothing one of the core values of Scrum. Without honesty in your team, you won’t be able to benefit from Scrum, XP or any other agile toolkit.

Honesty is also important for your self development. The first step is to be honest to yourself. But to be able to evolve positively,  you need the honest feedback from other people around you. Without their help, you’ll fail. But it is also important to be honest to others. If they ask you for your honest feedback, give it to them. Stop beating around the bush even if it unpleasant some times. Most people will be thankful for this. And if you aren’t asked for feedback, give them

7 Agile Sins

6
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.

How to defend against the 10 things that drive your ScrumMaster crazy

6

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:

Want to rate my talk? Go here:

What`s your favorite Agile Game?

3

gameI 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:

If you have any other resources or any other addition to this blog post, feel free to leave a comment.

Go to Top