Posts tagged Agile

An agile cloze

1
Cloze

http://www.flickr.com/photos/monkeyminddesign/4553428118/

I was just inspired by an german christmas cloze. It even inspired me so much, that I decided to write an agile cloze and let you fill the missing pieces :) So, here you are.

The best way _____________________.

Scrum is ______________ but XP _________________ with or without Kanban.

I currently read ______________ and think _____________.

___________ is the best thing that happened to our company because ____________.

Would you believe _______________.

_____________________ awesome.

If ______________ the world would be a better place.

Happy __________________.

You can either leave a comment or create a blog post based on the above cloze. I’m looking forward to your “fill-in” :)

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!

10 things to mess up your retrospective

4
Retrospective

http://www.flickr.com/photos/metabolico/583204694/

It’s about time for a new list. Today, I decided to write a list on how to mess up your retrospective. There are a lot of possibilities to do this and the following tips will help you doing so ;)

1 – don’t prepare anything

As the retrospective is the simplest and least important meeting of all Scrum meetings, it doesn’t need any preparation. Just come together and start. Wait, where are the pens and the post-its? Forget about it! Just sit together and chat a bit.

2 – Start immediately

As there is no need to set the stage, start immediately with gathering data. Immediately start the retrospective with asking the two questions: “What went wrong?” and “What went well”. That should be sufficient to get great results.

3 – Don’t check if the tasks of the last Retro were done

We don’t care about the old crap from the last retrospective. If it was important enough, it will make it again to our retrospective results. And again, and again, and again, and again….

4 – don’t use post its

Post Its are evil! Endless trees have to die to create this evildoing. You have silent and introvert people in your team? Then maybe it is time for them to learn to speak up. It also helps to reduce all of this retrospective waste, with all of these things that can’t be solved anyway.

5 – Forget about the Insight

Insight? Isn’t it clear why you failed in your last sprint? Maybe you should also skip the “Gather data” step and instantly start to “Decide what to do”.

6 – No DUE date

Due dates are for waterfallers. As we’re working in an agile environment, we don’t need any due dates.

7 – no responsible

Repeat after me: “We’re no waterfallers”. A responsible person is a concept from the stone age. We as a team will make sure that the task will be done.

8 – No time box

This whole concept of a time box is exhausting, isn’t it? Can’t we just skip it for the retrospective? Just sit together and talk and for sure we will have something valuable in the ehh, when it is over, eventually…

9 – try to solve everything

You collected a big list of issues? Then you should try to solve all of them. It can’t be that you ignore some of the problems of the last sprint. Define a task for each identified impediment or problem and solve it in the next sprint.

10 – Always use the same scheme

Always ask the same questions and do the same exercises in all of your retrospectives. This will create a comfy environment for your team and you ensure that you’ll always have a energized and creative team. Your retrospective results will be awesome. Ignore all of this fancy new methods to facilitate a retrospective. This is all new age shit.

I’m looking forward to your experiences, when trying these things out. Please leave a comment :)

5 Signs That Your User Stories Suck

9
Stop Sign

http://www.flickr.com/photos/arlette/3260468/

About one a half years ago, I wrote an article about how to mess up your user stories. In the meantime I saw other “User Stories” that gave me creeps. That’s why I decided to write this article. So here is my new list of signs, that your user stories suck…

1- Your user Stories Are Only a Wrapper

If your user stories only consist of one task, this is a sign that you just using them as a wrapper. I don’t know why, but it seems that some people believe, that they have to use the user story format for everything. A user story is “a promise for a conversation”. If there is nothing to discuss and it is a simple task, than write it down like this. Don’t wrap a pseudo user story around it. In most cases this is also a sign that your user stories are too small.

2 – Your user stories can be done in less than a day

If you have 40+ user stories on your Sprint Backlog, it gets really hard to get a commitment from your team. Some people might say now: “Wait, isn’t it great if they were able to create such small stories?”. Yes, it is great, but not if all of these stories are tasks. In such cases, these stories belong to a bigger story and don’t make sense on their own. Check if your stories are meant to add new functionality, if not something is wrong.

3 – Your user Story Doesn’t Describe a Feature

This is somewhat related to 1 and 2, because in most cases these signs come in together. If your stories are describing tasks for the developer, instead of describing a new functionality, something went wrong. I saw POs writing user stories that described thing like “Write document X” or “Create acceptance test Y”. In those cases I’m asking for the DoD of the team, because those things clearly belong there. And if you don’t want to add them to the DoD, create a task but don’t rape the user story format.

4 – You Use It For Everything

It’s great that you decided to use user stories to create your backlog. But you know what: You can use any format that you like. There is no rule in Scrum that you have to use user stories. You’re not forced to use this format for everything that is in your backlog. In a lot of cases it just don’t make sense, e.g. when you want to add non-functional requirements. Instead add those non-functional requirements to the acceptance criteria of your user stories. If they apply to more than one, create an epic and add it there. But please, don’t use the user story format for everything that is in your backklog.

5 – You Lost Your User

Did you write stories like: “As a project manager…”, “As a product manager….”, “As a developer…” or “As a test technician…”? Than you have lost the real user of your software. It won’t be the project manager or product manager who will use your software. Start over and ask yourself who will use it and write your user stories with their view in your mind. Another possibilty would be to create personas. But always have your user in the focus.

I’m looking forward to your comments. What signs did you observe?

 

11 Hints to Improve Your Scrum Meetings

6

I saw a lot of Scrum meetings out there, that are not more than a skeleton. Everybody is attending but nobody is participating. To improve such situations I collected 11 hints to improve your Scrum Meetings.

Daily Scrum

1 – Walk the Board

Instead of answering the “three questions”, which leads in most teams to answering only the first two questions, walk the board. This means, use your Sprint Backlog to talk about what is currently in progress and what is planned for today. That way you’re concentrating on the really important things, instead of talking about the past.

2 – Show what you’re working on

Pictures are often better than words. Show your colleagues what your currently working on. And yes, it is possible to still do this within the 15 minutes time box.

3 – Appreciate the Daily Scrum as a Mini Sprint Planning

The main reason for the Daily Scrum isn’t the reporting. The main reason for the Daily Scrum is to plan your work for the day. The meeting should be used to plan your next steps in towards your overall Sprint goal. Try to change the context of the Daily Scrum and use it as a Mini Sprint Planning meeting.

Sprint Planning

4 – Demand commitment

I know that in the last update of the Scrum Guide the commitment was alleviated, but I think I’m not the only one who thinks this is the wrong direction. At least in Europe I still think that the commitment is an important part of Scrum. That’s why I demand the commitment of every team member e.g. at the end of a Sprint Planning. Write your Sprint goals on a flip chart and let everybody sign it. Put it on the wall of your team room.

5 – Avoid big tasks

I believe every ScrumMaster heard this sentence more than once “This task is not splittable”. Bullshit! I’m convinced that 95% of all tasks can be splitted in smaller ones. Don’t accept big tasks, just because you want to finish the meeting and head to lunch. And this leads us to…

6 – Bring food

The Sprint Planning meeting is the longest meeting in Scrum. Avoid that the blood glucose level is going down and everybody wants to leave as soon as possible. Bring food!

Sprint Review

7 – Rehearse the Sprint Review

Nothing sucks more than an unprepared Sprint Review. Take your time and prepare the Sprint Review properly. If it’s the last day of your Sprint and a feature is still not running, skip it. Concentrate on what is working and prepare a great show. Your stakeholders will love you.

8 – Use the daily Scrum to plan the last steps

The last Daily Scrum should be used to talk about the last steps that have to be taken to reach the Sprint Goal. Nothing is more important that day.

Sprint Retrospective

9 – Define a responsible

At the end of a Sprint Retrospective you normally have a list of (a few) improvements for the next Sprint. But as long as nobody was assigned to the improvements, nothing will happen. I know there are exceptions, but having a responsible team member per improvement helps to keep the team commitment.

10 – Define a DUE Date

The same is true for a due date. You may decide, that all improvements have to be done till the end of the next Sprint, but there are tasks that will take longer. Set a due date for every improvement to help to track it.

11 – Make the results visible

I saw a lot of teams that put the results of their retrospective into a Wiki or an agile tool. The problem with this approach is, that nobody will see them anymore. Out of sight, out of mind. Put the results on a flipchart and hang it in your team room, so that everybody can see them. If a item on this list is done, put a check behind it. Another approach is, to add the tasks of your retrospective to your Sprint Backlog.

I hope this list is helpful. If you have other ideas to improve your Scrum meetings, I’d appreciate a comment. Stay curious!

 

Go to Top