agile, scrum, coaching, lean
Posts tagged Agile
A Checklist for a Distributed Retrospective
11262 days
http://www.flickr.com/photos/adesigna/4090782772/
More and more agile teams have the problem, that they are not collocated. If you work in a distributed team, you know how difficult it is to stay in contact. It gets even worse, when you have a big time shift between the teams. But in such situations it is even more important to do a team wide retrospective. That’s why I created a checklist for retrospectives in distributed teams. I believe that most of the points also apply to other meetings, like e.g the Sprint Review in Scrum. To facilitate a successful distributed retrospective you need the following:
A Co-Facilitator
It is very difficult to facilitate two teams, if one of the teams is located 1000km away. It don’t has to be a experienced coach, just somebody who prepares everything off-site and helps facilitating the retrospective.
Laptops
As I suggest to use an online tool for your retrospective, every team member should have access to a laptop. At least two team members should have one laptop to create their virtual post-its.
Beamer
Every team needs a beamer, so that you can show what is happening on the wall.
Network
Make sure that every laptop has network access. If you’re lucky a WLAN is in place, if not you need a switch and enough network cables.
Video conferencing
If available use a video conference system. In my experience it is very important, that everybody can see each other. A face speaks more than a thousand words.
Online Cardboard
As you won’t be able to use a physical cardboard, you need one online. There are several tools out there:
- linoit.com
- cardmeeting.com
- edistorm.com
- piratepad.net
- corkboard.me
- Google Docs
I use corkboard.me as it was updating the screens of the other participants very fast. It is also quite important, that you don’t need to create an account to use the tool. Thanks to Nils Wloka, Pawel Wrzeszcz, Barry O’Reilly, Angeline Tan and Katrin Elster for helping me to collect this list.
Prepare the Online Cardboard
As you would prepare a normal whiteboard or cork board, you also have to prepare your online cardboard. Make sure to search for a nice picture which presents the theme for the upcoming retrospective and that you put the agenda online.
More time for preparation
As you also have to care for the technical stuff and need some time to try if everything is working, the preparation time increases. That’s why it is important to plan for some additional preparation time.
Final thought
If you have all these things in place, there is no real difference to a normal retrospective. You can use nearly all retrospective tools, that are out there. And don’t forget the different phases of every successful retrospective.
Even though a retrospective with a distributed team can work out great, the team should meet in real on a regular basis. If possible the whole team should meet in real every second retrospective. I know that won’t be possible anytime, but it is worth trying. As Jutta Eckstein says: “You will pay for it anyway”. Either you pay for the flights or for less productivity.
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.
Food for Thought #10 – Bring food
1311 days
by scrumphony
in food for thought
http://www.flickr.com/photos/jeff-anderson/4385042770/
Have you ever been invited to a wedding without food? Have you ever been to a birthday party without a cake? What about a barbecue without the meat? Watching a football match without chips and beer? Even at a funeral they serve some food. Usually when people meet, there is also something to eat (and to drink). People love to socialize around some (great) food.
So why don’t you serve some food, when you have a meeting in your company? I attended an awful big number of boring (and even some interesting) meetings without food. But what I did observe is, that food is one of the secret ingredients for a successful meeting.
Think about your last sprint planning meeting. In the worst case, (for a 4 week sprint) the whole sprint planning lasts for 8(!) hours. But even a 4 hours sprint planning is quite long. It doesn’t matter if you plan such a meeting in the morning or in the afternoon; towards the last 1 or 2 hours, everybody gets hungry. And if you are hungry you start thinking, where to get food. And if you think about food, it is very hard to focus on the latest user story. But if of you’re a smart ScrumMaster, you’re prepared. You ordered a big chunk of pizza that will arrive just in time. That way nobody has to think about food, because everybody knows that the ScrumMaster took care for it. But bringing food also has other advantages, even in smaller meetings:
- The atmosphere is more relaxed and comfy
- Better results
- People will love to attend your meetings
- Less late comers
- No collywobbles
If you still don’t believe me, ask e.g. @vinylbaustein. He loves to bring food to his meetings. Try it, you won’t regret it. I promise…
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:
Recent comments