Management 3.0: #4 Exploration Days

After we talked about the management 3.0 techniques Kudo Cards, the Moving Motivators and the Delegation Poker it is time to talk about one of my favorites: the Exploration Days!

Exploration what?

You may have never heard of the term Exploration Days, but you may know them by a different name! They’re often called slack time, hacking days, pet projects, ShipIt days and sometimes hackathons (which in my eyes is something completely different, but that’s another story :)). What’s exactly meant by this? Quite easy: giving the employees the chance to self educate or to develop something on their own. And all of this great things in and while their normal working hours. Some of the main goals are a better motivation of the individuals, a better connection between the team members among themselves and the company and more outside the box thinking team members. You can fill the time with whatever ideas come up from the crowd. Important is to make it fun for everybody who wants to join! I’ve heard and experienced a variety of implementations. For instance google lets it completely to your own what you’re doing in your twenty percent of each work week. The other side i know is, that the company (often somewhere in between your boss and the team) decides what you are allowed to do. Both have goods and bads.

My experiences

It is a bit tough for me to find the right balance between respect and full honesty. In one company we were waiting for the implementation of this kind of stuff for a longer time. When we finally were allowed to start, it was quite unclear who had to approve the topic and it was a mess. Somehow there came up big discussions what to do when and if doing some things at all. Overall it was nice to have the time to do something to develop further. On the other side all the waiting and the big discussions gave an off-taste to the whole thing. Not the greatest experience. For me some things are clear: whenever Exploration Days are implemented, it should not be talked to long about it without starting and the rules have to be crystal clear. Even if the rules are too harsh, because the company fears employees are wasting time. Reasons for this can be cultural (some kind of distrust) or business need (the business model can’t handle non earning time).

What contact to Exploration Days (or their brothers) did you have? Which experiences did you made? Did it helped to be more motivated or was there a drop in motivation caused by strange rules or bureaucracy? Let the world know it by leaving a comment!

Thanks for reading and have a good time exploring!

Management 3.0: #3 Delegation Poker

A while ago i presented the first management 3.0 technique, the Kudo Cards and Box, in an earlier post and the Moving Motivators in the second post of this little series. Now i will write about the next technique: the Delegation Poker. Have you ever delegated to someone else? If so, you maybe have found yourself in a situation where you not knew how the status of the delegated job is or where you were not satisfied with the quality of the result. This two examples point out things which can happen, if you miss to make things clear. If you delegate, you should try to make the what, how and why as clear as crystal! Lets have a short look from the other side: have you ever had a boss who complained or even worse redone your work after you finished a job for him? There we have the unclear expectations again! The Delegation Poker tries to solve this problems and to make aware how much the person who receives the delegated jobs can and wants to handle them. This last point is reached by giving the chance of saying “i want you to do more in this particular case”.

As you see, delegation is more a scale than just a binary thing. Not only you or me, but little nuances like i will ask you or i will discuss with you. With this in mind we are able to find compromisses and negotiate where both of us see the job and the responsibility. Lets have a look at the actual cards we have in the Delegation Poker! There are the following:

  • tell
  • sell
  • consult
  • agree
  • advise
  • inquire
  • delegate

Now that we know the cards, we can have a look at the game itself. First we need a set of scenarios we want to decide who should have what responsibility. This can be easy little jobs or complex and complicated things like leading a whole department. We pick one after another of this scenarios and everybody selects secretly which card is nearest to his wished delegation level. All cards are revealed together, when every player decided for a card. If everybody has the same card, it is clear and decided, which level of delegation is chosen. If there are different cards, than it is obvious that there is a need to talk about the diverging ideas and wishes. After a short discussion there is the next round for the same topic, until there is a consensus. The results are noted on the delegation board: horizontal are the tasks to delegate (or not) and vertical are the seven cards. We make a mark on every line for which level of delegation we agreed on.

My experience

In the receiving position it was really fun and helpful to play Delegation Poker! It helped making clear to me which priorities we as a department have. Afterwards there was a motivation boost and i felt heard and valued. Even if there was not everything what i would liked to have in my direct influence. When i first wanted to play the Delegation Poker game it was a hard time. I chose an emotionally really charged situation. We had to put the cards aside to get out of the stressful area. Afterwards we found, that we can’t decide, if not also everybody is there to make all the decisions. So giving the Delegation Poker has some easily assessable conditions. Make sure there are no big emotional stress points open and that every decision maker is aware what you are going to do and even better: they are in the room and want to join too.

What are your experiences with delegating? Did you talked about it or was there just a “Hey, could you do this?”? Did you used the Delegation Poker and the Delegation Board? Just leave a comment and let the world and me know what you learned!

Thanks for reading and have fun delegating and being delegated!

Book review: The Five Dysfuntions of a Team

Have you ever worked in a team? Was it always easy and trouble-free? I hope not, because without some little conflicts something is really wrong! At least it feels not really vivid and not really human. The point is to handle this situations well. One approach to tackle the most problems is the one of Patrick M. Lencioni to watch out for the Five Dysfunctions of a Team. Lets first list them and then discuss a bit further what they meen:

  1. Absence of trust
  2. Fear of conflict
  3. Lack of commitment
  4. Avoidance of accountability
  5. Inattention to results

They are build like a pyramid: the ground and base for everything is the trust. Without trust in the team, you don’t need to think about conflict or results. If the team members don’t trust each other, it is hard to go in good conflict, the healthy conflicts. They are necessary to feel committed to the common goals. Without this the team members see no reason to hold each other accountable. And if nobody is having a look at the others, there is no attention into the results. That’s it. As easy as this all problems are in a simple line of causes.

How to get to attention to results

Whenever you see a dysfunction described in one of the five pyramid layers, start fixing this exact layer. If it is not directly one of those five, try to find out in which layer it starts. Sometimes the teams are not showing distrust openly. You find one member is asking everybody else, but not her team for a thing. Or you feel a slight thing around the results, like everybody is doing stuff, but there are constant hard discussions about the direction. Whatever you feel the actual layer with a not perfect running team is-start there! Find out in private talks to each of them if it is really the right layer. Look into the book, find a good excercise and go through it with your team. Tell them, that you will have an eye on the thing and want them to look for it too. Tell them repeatedly, what their goal is. For example “you are a team, our goal is, that you’re working effective and efficient together”. If the layer of dysfunction is fixed go to the next higher one and fix this one. Always be on only one layer at a time. Stay there, till it is fixed! Reflect with the team, if the layer is fixed before going up.

My experiences

The most astonishing thing for me was to realize how many things can break a teams attention to results. It can come from so many directions: from above, from the side and from below. If the boss is not respectful, nobody stays respectful for a longer time. It needs so much discipline to maintain respect in such a situation. If you are not allowed to keep your team members accountable, it will end up not well, if nobody interrupts the vicious circle. And it is a real vicious circle: if one thing is broken and not fixed, the layers below will break soon! Why should you hold someone accountable, if nobody cares for the results? Why should anybody commit to something, if there are no consequences?

The awesome part about this book is: it really works! There is a magic behind it, which makes it easy to approach any overwhelming seeming problem. And after some attempts your team is getting better. Already the sign that you care helps the team to feel better. In most cases they want to understand and help fixing the problem. If you keep repeating that the problem will be solved, it helps fixing it. The greatest feeling is, when your team members come up with ideas how to solve the problem and make the team work even better. You only have to start and stick in some situations.

Sometimes it is not the best idea to tell the guys what you are going to do with them. Some don’t want to have the touchy-feely things at work and in their live. For these situations i don’t have something what works really good. Only to not tell front up next time, to not disturb the walk through.

What experience do you have with team building? Did you read other great books on the topic? What problems did you had in your teams? How did you solved them? I would be happy if you would leave a comment!

Thanks for reading and have always great ideas for fixing your team problems!

Story Points

After i’ve wrote about User Stories there were some questions about the closely related topic of the Story Points. I will try to cover those in this blog post.

What they are

A Story Point is an artificial estimation measurement for a User Story. It is artificial on purpose. We don’t want to have it exact, because this would take us too much time to reach. The main value in estimating in Story Points is this: the ideal Story Point estimation makes every story, which is estimated with the same scale by the same persons comparable to every other story for which the same things apply. We need this two conditions, the same scale and at least nearly the same group, for important reasons. If we try to compare stories which are estimated with different scales, we are comparing the famous apples with oranges. This will not help in seing how long a team will need to finish the given set of stories. Same applies if completely different people estimate the stories. Even if they know the original scale, they will see the world through different eyes. Which makes the estimation different. This can be good, if the estimation gets more realistic, or bad, if it is tending more to the unrealistic direction.

The difference of Story Points to the famous man-day is, that we not only have a look on the effort it will take, but also on the risk and the complexity. So a nearly effortless story with a huge risk can be estimated higher than a easy, boring, time eater routine story. Same for a not much to do, but complex set of tasks: it can be estimated higher.

What they are not

We are trying to make the estimation in Story Points more adequate but not exact. Trying to reach exact estimations would mean to have a complete plan for every step. With User Stories we try to give the team the possibility to explore the solution and work strong together. With the need of having exact times and an exact plan, we kill creativity, team work and the feeling of responsibility. As already mentioned Story Points contain not only the time! This is important to have always in mind, there is never a precise mapping of Story Points to a time needed or even to a precise point of time in the calendar. The agile part in Story Points is, that we try to get things like team work and responsibility in exchange for the illusion of an exact plan. Things will always go wrong and no plan survives the project, so we let the planning phase be a bit short and gain other values out of it.

How to get a first baseline

My first teams to be introduced into Scrum and Story Point estimations had a situation, where not everybody was comfortable to estimate. The reasons were somewhere inbetween estimation by management and hard deadlines made by sales without asking. Here comes what helped everybody not worrying, but just going: we layed out a Fibonacci sequence of cards (1, 2, 3, 5, 8, 13, 20, 40, 100) on the middle of the desk. As you may note, from twenty on the Fibonacci sequence is broken. That’s for easiness, everybody can remember twenty, fourty and one hundred. But try to remember 21, 34 and 55. Yep, only a little bit harder, but think in two weeks again. Back to the main topic! We take the first story, discuss what has to be done. If it fits around the eight or thirteen, we put it on the desk in between those two numbers or on one of them. If it is somewhere else, take another story to start, till you have one which fits between eight and thirteen. Ask everybody, if there are open points to discuss with this decision. If so, talk and move the card till everybody is happy with its place. Now take the next story. Decide, if it is bigger or smaller than the first. Try to find a good place for it. Take always only one story and sort it into the already given stories. After every story reflect, if the card sits correct where it is and if you need to rescale all the stories for a better measurement. Reasons for rescaling can be that everything is on one side of the scale in a range of two or three points or if there are stories which seem to fit nowhere. When the team found enough stories fitting in the scale, let them choose for each point of the Fibonacci sequence an example story. These stories you bring with you whenever the team will have to estimate the next two or three times. They can be seen as reference points, if there are differences in the points of view. After a while everybody should have a common feeling what an amount of Story Points meens.

My experience with these steps:

As mentioned the first teams i guided through the learning how to estimate had distrust against estimations. For this situation it was way easier to just talk about one story at a time than have the discussion why to estimate and how to do it. The guys were open to follow it step by step and no big discussions came up. The guided tour through the process made it easy and painless for all of us. When we came to the end it was even the case, that the team members came up with suggestions how to rescale and were in vivid discussions about if a story is a five or an eight. My theory is, that whenever you go through easy steps with a group of people, they tend to come with you. But if you tell them “we’re going to xyz” they can come up with the complains and boycotts. To me seems to be like in the great book Facilitator’s Guide to Participatory Decision-Making. There is a theory of how to get people painless to get to a solution or decision by guiding everybody through phases. There you first open the solution space and than talk through the possible solutions to find the best solution (or the least worse one ;)) and choose one solution in the end. Really excited made me, that even new guys had an easy time to get into the estimation after a few months. Almost everyone new to the team made it after just one time with only watching to get really fitting results! One developer made it arlready in the first Backlog Refinement she participated, to come up with fitting estimations. That left me speechless! The last observations i want to share are the following: there developed a game thingy in our estimations which is like “if everyone has the same number, than we get a shot”. Nope we aren’t drinking at work. Even if it seems as a good idea :)! That made the Backlog Refinements and the Sprint Plannings real fun, thanks for that guys! But its important to mention, that everybody knows, that the differences in the later on blind estimations are more a big value. Because we afterwards talk why the values differ. Within that talks we discover risks and clear questions.

What are your experiences with estimations in general and especially with Story Points? Have you ever asked yourself “How to get these guys to estimate?”? What worked well for you and what absolutely not worked?

Leave me a comment and tell me what you liked or not liked about this article! Thanks for reading and have a great estimation :)!

Management 3.0: #2 Moving Motivators

In an earlier blog post i wrote about the Management 3.0 technique of the Kudo Cards and what i’ve learned using them.

Today we’re going to have a look at my experiences with the Moving Motivators, as you guessed it right, also a Management 3.0 technique. The key question the Moving Motivators try to solve is the following: what are the intrinsic motivations of a person and what does she win or lose if something changes? So it is a tool to become aware of the things the player thinks are most important to herself and make them transparent. That said, we can have a look at the motivators one can choose from. They are the following:

  • Curiosity
  • Honor
  • Acceptance
  • Mastery
  • Power
  • Freedom
  • Relatedness
  • Order
  • Goal
  • Status

Note, that the first letters form the word CHAMPFROGS, which reminds me of the great book Eat That Frog! – you don’t know it? My recommendation: read it, its full of entertaining small pieces of daily usable wisdom!

Lets have a look on the overall process: we have a facilitator, a player and the deck of motivator cards. The facilitator explains the steps and asks further questions to point out insecurities and make things clearer. First step is, that the player sorts the motivators in descending order of how important they are for her. Second step is to ask a question to have a closer look at. This can be as simple as “How will my life change, if i take the next step in my carreer and go to XYZ?”. With this question in mind you now have a look at each of the motivators. Will this motivator change to the good or to the bad? If its getting better with this decision, you move the motivator card upwards as much as you feel. If the motivator will be damped or you feel it will go down, you move the motivator card downwards as much as necessary. If you want to decide between several options, you can play the game multiple times, till you have a complete set of “How my life will change”-situations. You than can compare the options from another point of view.

When i played the game myself, i found some helpful things for myself: first i loved finding out what my motivators are. Being aware about what i need and want a bit more clearly made my expectations more realistic. Seeing that some things can be better, while other things go worse, gave me a deeper understanding of the complexity. When seeking for the next job it helped me and still helps me to figure out what i really want and where to go and where not.

When i played the game as facilitator i found, that this little game is a powerful tool for many people to find their way. On top it is a great structure to get in touch with the deeper feelings of one another. Whenever two people need to find out the real intention and motivation of one another it is a good starting point to have a look at the cards and open up. This is easier than with the direct question, because the cards and fun of a game is making the situation not looking to serious. But: you can handle really serious situations, don’t be fooled by the nice looking cards!

As a bonus i developed a nice little browser tool, with which you can play the Moving Motivators online. You can even save and load your results to have a look later on (have a look in the lower right corner for the icons ;)!

Did you ever heard from the Moving Motivators? What are your experiences with them? In which role did you played them? And what did you learned while plaing it? If you never heard of it: did this post animated you to try it out?

Thanks for reading and have a successful day!

Great leadership

At this point of time i feel that its a good moment to fixate my learnings about leadership. The ones i felt how i would like to go, the ones i learnt by horrible mistakes or blind spots and the ones i read about. Why do i want to write about them? Just to reflect my situation and where i am now and what i want to reach. Some things i already live quite well, some things i want to achieve. Lets dive in directly with the first and biggest learning: leading starts with yourself!

Lead yourself first

This is the way most important thing about leadership i see: when you’re not able to lead yourself, you can’t lead others. Well you can, but you will not be as effective and successful as you could be. So the journey to become a great leader, starts with your first step to reflect yourself regularly. It is very helpful to be aware about the situation in yourself and in the others around you. This gives you the possibility to see the chances you and others have in this exact moment. And seeing more options opens a whole new universe of possible solutions.

Be respectful with yourself. This one starts with the thoughts you have and goes over the actions you take. If someone around you is consequently and constantly disrespecting you or your role, than first of all talk to them, if this doesn’t help to their boss and if it still doesn’t change, do yourself a favor and move on to the next position. Easy as this: you always have the option to accept it, change it or leave.

Win the inner game: don’t let the lazy dog do his “laying in the sun” game. Go progressive against procrastination! Don’t shout out every angry comment you have in your mind. Often its not making the situation going anywhere good. Don’t rant around about everything and everyone. Sometimes its good to show the energy of anger, but you should spare it for the points when the time is ripe and your peers are open for the extra energy shot. Exploding daily makes it common and nobody will listen to you any longer. So in a nutshell: you are the boss of the feelings you have and show. Win the fights with yourself, to win the ones outside.

The next point of leadership is focusing. I know a lot of guys with great ideas. They have plenty of them and are keen about all of them. They start to build a thing and a week later they tend to the next one and leave the first one aside unfinished. By this habit they leave a trail of started projects and none of them works. Sometimes its the point, that they tend not to get over the dip in a new area and sometimes they just leave it die because there is a newer, more sexy thing around. With focus on only a small set of goals or projects you will always reach better results. If you only have a little set of objectives, it will be easier to stay on track and reach them. When you finish one, you can and should put a new one on your list. My maximum which worked out very well was three goals at a time. More goals and i tended to not make the goals big enough. Less worked well, but if there is a external blocker in one thing, which you only can influence and not shape directly, its getting a bit unfocused again. You have no goal number two and don’t want to open a new one without finishing the old one. A small dilemma, but it’s ok. So three objectives is my favorite. By prioritizing them in the Eisenhower matrix you can assure to not work on things which are not important and urgent. More great hints on how to get the right things done are in the book Eat That Frog!.

In my eyes having a vision is another key to lead yourself to something great. Sure, often in life there is no easy planning for how to go step by step to where you want to end up in your carreer. You meet the most important people in your life sometimes on purpose and sometimes just by accident. But forming a clear vision helps seeing when the right ones stand in your door. You get the chance to feel that there is someone who can give you something, if you have your why as concise as possible in your mind. With the why often a what and a how comes for free. Find the leaders worthy to follow. And search for them! Look for great visions and the ability to inspire others with the ideas and the questions!

The last two things you can do are being proud and keeping your ego in its healthy boundaries. As often in life it is important to have a good balance. Here this means to have a standing, an opinion and to not stand still on this opinion. If there is a better way to see things, switch to it. If the new way doesn’t work out well after a time: go back! Be agile and flexible in your mind. Nothing is worth leadership than staying stubborn on your old point and expecting better results than you already got. Some things should form your core values. You should not touch these values. For example one of my core values is respect. Sure, its sometimes hard to maintain, if somebody is disrespectful over and over again on purpose, but its worth to have such a value and i won’t skip it for little things.

Lead others to grow leaders too

As we’ve talked about things which touch only you, lets see how to handle the easier part: the others 🙂

One thing i would like to point out first is this: don’t talk patronizingly to others. This gives them a feeling of not being worthy and takes away motivation. Even more you should not think about others in such a way. It already forms your actions and your mindset in a way where your opposite feels whatever they say, you are or feel to be the better one. Which is not only a strange feeling, but also a demotivating factor. The opposite of thinking like this is to ask for their ideas and try to get them involved by heart. This is done by letting them create the things they invented. They proposed a good product feature? Let the ones who had the idea build it! They came up with a better process? Let them improve the status quo with the help of you! They will feel included, valued and worthy. They are in it with their full hearts!

To have your team and coworkers on your side, you need to be crystal clear in where to go, how and why. That’s a key to have the ones which care, on your side (the other ones you will never get, they are already gone in their mind). You need to come up with a vision and communicate it. When you’ve clearified what the goal is, you can always set borders around it and communicate respectful feedback. This is needed to not get lost in anarchy and stay on track. Like parents you need to say “no” to things which get the organization and the team away from its goals. Its your responsibility as the leader to watch out where the team is going. And this borders, rules and visions have to be repeated over and over again! The repitition has to be done until things are improved and everyone understands the why behind the what.

Lets talk about one not so nice part of leading: the complains. Whatever you do, decide or tell, there could be someone complaining or even hating it. I am not sure, if it is a limiting belief, but you can’t be with every decision on the “love it” side for everybody everytime. So expect to make hard decisions and get harsh feedback from above, your side and the ones you lead. A big help for me always is to separate what is against me and what against my role. Try to find out where the complains come from. Is it an unfulfilled need? Try to figure out how to fill this hole. Is it a demotivation? Try to explain and find a motivator which you can use now. The key is to only solve the issues which are the root cause and not fiddle around with the symptoms. They will come back again with the next decision.

Ok, enough of the hard parts – back to the loving parts again! When you lead, you have responsibility. And with responsibilty comes the obligation to care for others. In my eyes one of the good reasons to become a leader. Make sure noone is overloaded with work or responsibility. That’s not easy: one guy can handle a workload or responsibility which is way to much for the next guy. Also the actual personal situation has to be considered. Most people can handle more when in a save position at home and at work. If there are hard times at home, it is not healthy to keep the same load on their shoulders as before. Whenever you give someone more responsibility make sure, that she gets the time to grow into the new situation. Nothing is more demotivating than being thrown into the too cold water. It is substantive to make sure they know it is their responsibility now and exactly in which steps they will grow into it. Therefore it is necessary to formulate the goals and steps as SMART as you can. Try to find the best fit for the organisations and the peoples needs. Watch out that they have everything they need! Including time, the support and all materials you can find and afford. Not only for the set of goals, but also for being the best version of themselve! Take a close look on the “attractive” part of the SMART goals. If the person is not accepting the goal you set, the end of the story will be disappointment. I know that not every interpretation of the smart acronym is with an attractive, but there is always an equivalent. Without the inner support of the one you lead, the failure is programmed and waiting in one or the other way. Assure, that your followers know the goal, like the goal and belief in theirself. Therefore appreciate their successes as often as you can and make failure a pleasure to learn from. No fingerpointing, no blaming, just say “that went wrong, lets have a look what we can learn and how we can do better!”. It’s as easy as this: be respectful! Nobody makes mistakes on purpose or to do harm. Or at least very few people. And if so, find out, if it is in their personality and set borders. If these don’t work, pick them out.

Try to delegate as much as you can. If you share responsibilty with your followers everyone wins: you win time to focus on better things than doing the daily work and the others win the chance to grow and feel seen in their full potential. Everybody can be happier with shared responsibilities.

By letting others grow around you and giving them the chance to grow into a great leader too, they learn to handle things in a healthy way. They are not thrown into a leaders role from zero to one hundred percent in a day, they can take over things slowly and learn to handle inner and outer factors in small and growing scopes. By this the things are not outgrowing and the feeling of being overwhelmed is not so often present.

The last two points i want to share are those: stay until its sure you have raised good leaders which can take over the situation and search for great leaders to follow by your own. When you stay till you know the new leaders are able to handle things in a good way, you are not leaving burned ground. Sure, sometimes the situation is hardened and there is no other way than leaving. For instance if you find yourself in a mismatch of your values and the organizations values. Or if constant disrespect is given to you or your role. If talking isn’t making things better, than you should pack your stuff together and search for something new. Here comes the last big point into play: if you change your position, search for environments that fit at least at the base to you, your values and your ideas. Therefore search for the leaders which do something better than you. Those you can learn from in one or the other way. Those, which inspire you just by little talks. Which let you grow and which are searching for more than power by having a leadership position. For instance they can be interested in virtuous circles or in the people around them. It is your responsibility to have a very close look where to go next before you leave anywhere! Be picky! Don’t go for less, you only have this one live and you want to life it as great as you can. Therefore try to find the best overall! One last hint: don’t blame yourself, if you made a mistake with one of your steps. Learn from it and go further!

What experiences do you have with leadership? What great points did you find in others, which made you follow them immediately? What worked well for you? Please let a comment, if you have great insights or if you liked this article!

Thanks for reading and have fun leading your life! 🙂

Sushi programming

Today i want to share a programming technique with you. My former fellow developer Felix and i tried it and had real good experiences while using it. (Damn, its a long time we didn’t worked together and i miss it!)

We named it sushi programming. I will explain later how we came to this name, the differences to Katas and Pair Programming and where we found pros and cons. Let’s keep things short and dive into the sushi bar!

How to do it?

We have two phases in sushi programming:

  1. the performance and
  2. the discussion

Let’s dive into the performance

The base philosophy behind “Sushi Programming” is to watch, and ONLY watch, note things, which will be discussed later. So we have one developer who is writing code with his normal IDE in the normal way he does this. Lets call him the author.

The other role is the audience, at minimum one other developer. The audience is only watching the author. It is important, that the audience in no circumstance (only a nuclear war or the lunch time should disturb us ;)) talks to each other or the author. No questions like “How did you get your IDE to automagically create this whole file?” or “Why don’t you use this fancy key combination to commit your code?”. The audience just writes remarkable things down. This phase should durate between 15 and 45 minutes. With shorter phases you won’t find enough new good or bad habits, with longer the amount of things will decrease.

In the second phase, called discussion, the audience and the author walk through the notes of the audience. Here all good habits swap around the team and the bad ones get out of the author. Rule of thumb is, that all points should be formulated respectfull and without a personal judgement. So only ask “How did you did that magic trick?” or “Do you know, that you could generate the getters/setters?”. I think it is important to write about this rule, cause it will keep the drama out of the discussion. The aim of this technique is to spread the given knowledge as much as possible in the team and increase everyones work quality and speed.

Differences to other techniques

Pair Programming

In pair programming you are allowed to talk all the time. This gives the software developers a better understanding of each other and the solution they build. With suhi programming we are aiming only at the habits of each other. Therefore the silence in the first phase is installed.

Peer Reviews

Peer reviews are either with one guy or with multiple guys. So whenever a piece of code, a software or UI design or an architecture is watched by a group of people, we can call it a peer review. The aim is slightly different from sushi programming: in peer reviews we want to improve the code at all. We should not mind who wrote the code, we just want to see, if it fits our quality standards and our understanding.

Code Katas

Code Katas are a great wy to learn things as a group. We sit together and work through a rigid plan of steps without thinking too deep while doing. The aim is to get a new habit into our muscle memory. For instance it is perfect to get into the Test Driven Development circle, if you never before used it. Or a new framework into your brain. This said, the aim is clearly close to sushi programming: train the new things.

Why the crazy name “Sushi Programming”?

I’m not sure where i got this information from and if it is true: i heard, if you want to become a sushi cook, you have to spend a certain time as a dish washer and as a waiter. This phase around your aimed work should give you the respect for the other activities and let you soak in the spirit of a sushi restaurant, like how to treat the food and the guests. This should beware you of doing the biggest mistakes in the everyday worklife over and over again. You’re filled with best practices before you even ram your first knive in the first fish. Soaking the spirit, for the learning developers, and spreading the spirit, for the master developers is a healthy habit in my eyes.

Pros and cons

  • the flow of the author isn’t broke by discussions – a big plus to get more knowledge moving from one to another individual
  • the author and the audience find more hidden treasures (a.k.a. IDE shortcuts or bad habits) in the everyday routines of the other than by Pair Programming
  • the team members get a deeper understanding of the used techniques
  • the team members get kwowing each other better, because they see each other finding solutions (hopefully they reflect their own too and thereby know themself better)
  • the team members train discussing techniques and routines without hurting personal feelings, which will be good for the team spirit
  • after a time only the knowledge of the team is spreaded, there is a “we don’t learn anthing new” if you do it too often, without developers from the outside of the team


For me it was a really useful habit to sometimes sushi program. Our team knowledge went up fast and it helped me and the others! So my recommendation is: try it yourself and have fun!

Did you liked the article or the idea? Do you feel the urge to propose a better name? Do you know, if it is part of becoming a suhsi cook to be dish washer and waiter first? Did you tried it yourself with some colleagues? What were your experiences? Than please leave a comment!

Thanks for reading and sharing!

Management 3.0: #1 Kudo Cards

You may have heard about the Management 3.0 system. It is a set of games, tools and practices, which helps managing oneself and organisations. In this little series i am explaining one by one some of these parts of the system and share my experiences with them. Lets dive right into the first part: the Kudo Cards!

Kudo Cards & Kudo Box

The Kudo Cards are a set of cards (you guessed it right ;)). On those cards some kind of compliment sentences are started and there are some empty lines to fill. Example compliments are “Well done …” or “Great job …”. Thats it. Your job is now to think of your colleagues and pick an event or quality which you really like and fill the empty space with your own words. Afterwards you can either hand it over directly or anonymously. For the anonymous way there is a Kudo Box. It is like a mailbox, where you can throw in your mail and then it is up to your organisation how to ritualise the handover. In our company we do it as one point to hand out the Kudo Card to the adressee. But he is free to only read it alone or to say thanks how he want.

Our Kudo Box with the great Kudo 2.0 QR Code Video Kudo Card.

My experience

When i introduced the Kudo Cards, i was just thinking, that they are a great idea. As i am, i handed my first set directly to the recipients and did not think about what they could think about it. So i didn’t installed a Kudo Box or a ritual, because in my eyes it was like positive things could be told face to face. Damn was i wrong. As a direct reaction to my announcement three guys came to me and asked why there is no Kudo Box. Asking them why they want one, brought up, that they are shy and don’t want to hand them directly. So our Kudo Box was born and the ritual was introduced, which made these shy ones happy.

To accelerate the usage of these ideas i started writing cards for the ones who deserved it before the company retrospective. Everyone who got one card was happy and proud in this moment. It was a great experience to see, what a little compliment in front of everybody else can do. Some where infected by the idea and also wrote compliments for others too. They mostly gave them directly or brought them to the desk when the recipient wasn’t there. One great idea was a “Kudo Card 2.0” with a QR code. Behind the QR code was a link to a YouTube video with an old german ad celebrity telling you what a marvelous colleague you are. At the moment the Kudo Cards are somehow in a hibernation. Since more than two months there is no card in our box. But i don’t stop to remind my colleagues and hold up the ritual of opening the Kudo Box while the company retrsopective.some gave the Kudo Cards directly to each other some over the Kudo Box


First of all i really love the Kudo Cards. Having a little positive wall near my desk keeps up my moral and helps over heavy situations! This experiment helped me learning things too! First a real obvious one: not everybody is as extrovert as me with compliments and feedback. Second they last much longer than the short term experience of a spoken compliment. Don’t get me right, if there’s something working well your rule of thumb should be to speak it out loud as fast as you can. Last but not least there is a big influence of just having this instrument in your company, organisation or tribe towards a positive way of thinking. Only some cards make a difference for those who get them. They walk around with a better mood for a while and give this happiness into a virtuos circle.

I absolutely recommend Kudo Cards for you! 🙂

Do you have any experiences or want to say anything about this topic? Just leave a comment, thanks for reading!

User Stories

Everybody who came in touch with Scrum or Agile heard about them, many used them and still there is confusion of what it is and how the Best Practices look like: you’re right, i am talking about User Stories! For the easier writing of this blog post i am talking only about Scrum here. But it fits to other Agile methologies too. Lets dive into the topic!

From theoretical point of view, a User Story is a requirement. User Stories are a subset of requirements. User Stories have a common look and feel, also called a common structure. There are mutiple kinds of structure for User Stories in the english wikipedia article described. Here i will take this classical style:

As … (role/persona) i can … (what) so that … (value/benefit).

For more clarity lets have a look at some easy examples:

  1. As Administrator i can manage users in the backend so that i do not have to insert SQL queries into the database.
  2. As User i can find web pages easily according to key words so that i do not have to rely on web pages which i or my coworkers already know.

As you see, this examples are a bit open. They leave space for the how to reach the goal exactly in many ways: there is no exact description how the user interface has to look, there is nothing said about how to reach the goal technically and finally it is not said how the user is guided to reaching his goal. As a good product owner you leave this level of granularity in your user stories until the team decides to be a bit more detailed to reach several goals:

  1. first of all you want to compare business value of your features, so you want to assure, that no technical or other solution detail distracts you while talking to stakeholders about “What’s more valuable for you, feature A or feature B?”
  2. than there is the part, that the team should be involved as the solution experts they are in the refinement and solution definition.

The first point helps you to keep a vivid Product Backlog. Also it helps the whole Scrum Team to focus (one of the Agile Values) on things which are important. Also it helps you and your Scrum Team to only do the preparation work necessary for the next upcoming Sprints. You don’t want to have a huge set of fully refined User Stories. As you may already have realized, the world sometimes changes. And so the markets do too. Some markets change really fast. The User Story you’ve written today can be invalid in a year or even a month. Or it could be, that it has to be changed on a non-trivial base. So it costs you and your company time, energy and money to maintain a big, fully refined Product Backlog. Somebody will be in a situation where she is remembering that one ticket/User Story which is nearly what is now under debate. But it is hard to find! Once in a while somebody needs to clean up and walk through all the User Stories and decide if they are valid any longer. With valid here is ment if they are not done yet or they are not longer the need of the customer. So my advise to you: there are better things to do with your time than maintaining millions of future maybe items! You’re here (in your company ;)) for only one thing: create value for your customers!

The second point helps the individuals in the team to feel connected to the solution they build. If they are involved early and can freely design the how, they have not only influence on what is going on, they really shape their work. With this said they can feel more self-efficient. And who is not feeling better, if she can build her own surrounding and decide how its done. For the why it doesn’t matter if team members are free to find the best fitting User Experience or the technical solution, both things should lay in the teams decision circle.

Properties of good User Stories

Another good hint into the direction of great User Stories is the “INVEST in Good Stories and SMART tasks“. The things proposed there are a good true north and ment more as a best practice. Often you find different definitions of the letters of the acronyms, so i decided to give you both words in case i heard of them. Lets have a short look what the acronyms meen.

Good User Stories should be:

  • Independent – the perfect set of Stories has no dependency, so we can implement tham in the order we decide. Unluckily it is not always possible…
  • Negotiable/Negotiated – the User Story of our dreams is not finally fixed and not very detailed. We are allowed to leave solution details open.
  • Valuable – that one is easy and hard together: we need value for at least one customer. Without customer value, we should not think about writing down a single letter or loose time and money.
  • Estimable – we need Stories, for which we are able to write down a number. Hopefully it is a Story Point ;)! Seriously: if we can’t say at least “This Story is as big/complex/risky as that Story.” or “This Story is bigger/more complex/riskier than that Story”, we are not able to compare the User Stories. That hinders us from being able to decide how a good Plan for the next Sprints looks like.
  • Small – a story is best, if it is not too big. The size described here is ment in two meanings: the story should be doable in few weeks by one person and it should fit on one card. The few weeks restriction helps us to keep the estimations for the User Stories realistic. The bigger the story, the wider the range of not hitting the real corridor with the estimation. To restrain the written size of the story helps us to not use a whole concept instead of a User Story. It forces us to break down bigger stories and Epics (very big User Stories, our example number one could be one) into fitting ones.
  • Testable – we need realistic stories. One way to achieve this is to think about how the story could be tested. If you have no idea, how you could test the story, than the chances are high, that your User Story is somehow not clear. Sometimes it is likely, that you have non-functional requirements. For example you want your application to be high performant or as small as possible. This things can be added as acceptance criterias like this: “the application should be live usable” or “the application should fit in 5 megabyte”.

Good Tasks should be :

  • Specific – hmm, that one is easy and hard at the same time: the tasks in a User Story should not be “design” or “implement”. That should be done latest in the Sprint Planning. They should be something like “implement the method save of the user controller”. So you see, we need very granular information what should be done here. Important side note: the team should decide what tasks to do, not the Product Owner or the Scrum Master. The later one can and should point out better ways and should not let the team get away with the given weaknesses. But he never should force the team to one specific solution.
  • Measurable – the example from the last point is very good measurable: either the method is implemented or not. “Fix the bugs” is a bit harder to measure. This comes from its unspecific formulation. Which bugs are ment? All known? All existing? Only a subset like “the new introduced”? Here the measurable is often tied to the “specific” property.
  • Achievable/Attractive – here we have two properties in the smart acronym, which point to slightly different directions. On one side a task should be doable in one Sprint and overall, that’s what we call achievable. On the other hand it should be meaningful for the customer, the team or the company. So there should be a sense behind everything we do.
  • Relevant/Realistic – this is another two-sided part of the smart acronym. As the attractive of the last letter, the relavant is pointing to the sense. We don’t want to have useless work done. This would be also called a waste of time and money. So we focus on relevant things. The realistic is somehow pointing to the achievable. With a task like “make the rendering of the finished, postprocessed animation movie happen in under a second” will not be reachable without huge preprocessing or huge computing power.
  • Time-boxed – There should always be the wish to finish the task in a given time. In Scrum this is easy: we want the User Stories done in this Sprint. Therefor all their subtasks and all other tasks should be finished in the Sprint too. Hopefully your Sprints are time-boxed too :)!

Now we have seen how the User Stories and tasks should look like. Lets take a short step into why, when and how to split things. As often the aim is to reach a reasonable granularity. We want our stories as small as necessary. This helps us to get to the point where we can estimate them very accurate. On the other side we don’t want to break them into too small pieces. So we want them as big as possible, to not have to deal with five thousand User Stories per Sprint, which is in the most environments a huge administration overhead.

How to refine User Stories

How can we go from the first version of our User Story to an adequate, good-sized final version? About that topic you can find plenty (quick) guides and advices spread all over the web. I like the Quick Reference Guide for Splitting User Stories from the agilelearninglabs for its conciseness and its powerful tools. It is a good starting point for a best practise for your team. It consists of these steps:

  1. Split, when you see conjunctions (and, or,…).
  2. Replace generic words with specific ones.
  3. Write down acceptance criteria, they:
    • are pass/fail conditions, that prove story is done or not
    • can become smaller stories
  4. Do a timeline analysis:
    • pretend the story is done
    • What sequence of events happen while the usage?
    • each event can be an own, smaller story

Lets go through this steps with the example User Story #1. You don’t have to scroll up all the way again, here we have it again:

As Administrator i can manage users in the backend so that i do not have to insert SQL queries into the database.

First question of a team member could be “What is ment with manage Users?”. As you see, in the first iteration we skipped the step one, cause there is no conjunction, and proceeded with step two. The Product Owner can answer now “create, edit and delete Users”. So we end up with the

As Administrator i can create, edit and delete users in the backend so that i do not have to insert SQL queries into the database.

Now we have the conjunction “and” and are able to split the Story into three smaller ones:

  • As Administrator i can create users in the backend so that i do not have to insert SQL queries into the database.
  • As Administrator i can edit users in the backend so that i do not have to insert SQL queries into the database.
  • As Administrator i can delete users in the backend so that i do not have to insert SQL queries into the database.

For brevity we only look at the third story from here on. It has no conjunctions and deleting is not very generic. Now we can proceed with the third step. An acceptance criteria could be as following: “the user is permanently unavailable from the whole system”. The team members can now ask, if they should remove the user completely from the database (step four starts: timeline analysis). Than the Product Owner can ask his lawyer and answer that the user data have to be stored for the timespan X and afterwards should be deleted completely. With that information the story can for example be refined to 

As Administrator i can delete users in the backend so that i do not have to insert SQL queries into the database.

Acceptance criteria:

  • the data of the user isn’t removed when the user is deleted
  • the data of the user is kept for at least for the timespan X after deletion
  • after the timespan X after the deletion of a user the data are automatically and completely

For now this one looks well defined and razor sharp.

Another example splitting

Lets have a look at the second example User Story. Here it is again

As User i can find web pages easily according to key words so that i do not have to rely on web pages which i or my coworkers already know.

The first refinement step, looking for conjunctions is not getting us further. There is only one between “i or my coworkers”. So we go directly to the generic word “find“. Here we can split the Story into the search and the results display like this (for brevity we leave the benefit in an abbreviated form):

As User i can insert my key words easily for a web search so that i do not have to …

As User i can view the result web pages easily according to my key words so that i do not have to …

A short note: if we oversee the generic word find, we could and would come to the same result in the timeline analysis in the fourth step. Back to the next step: the acceptance criteria. Lets clarify them only for the third story:

As User i can view the result web pages easily according to my key words so that i do not have to …

Acceptance criteria:

  • the searched key words are written prominently on the result page
  • the result web pages are listed with a link and a short description

Lets go with the timeline analysis. While thinking of the users timeline, for me two things pop up. Firstly i am not sure if all the billions of maybe results should show up and secondly i am not sure, if the result page should be immediately shown or if there can be a link send by email when things are ready. Asking our virtual Product Owner brings us to this additional two acceptance criteria:

  • the web page is loaded in realtime (< half a second)
  • the result web pages are paginated results per page

Lets have a look at the complete User Story:

As User i can view the result web pages easily according to my key words so that i do not have to …

Acceptance criteria:

  • the web page is loaded in realtime (< half a second)
  • the result web pages are paginated results per page
  • the searched key words are written prominently on the result page
  • the result web pages are listed with a link and a short description

The acceptance criteria can become new User Stories. Here the first sounds really like a huge thing (not forgetting to scan the whole web ;)) and should be extracted to standalone User Story.

Lets have a look on the INVEST properties with the result User Story:

  • Independent: the “maybe extracted” realtime story is not independent of the view results web pages story, which is not independent of the insert key words story… we have sometimes to deal with that.
  • Negotiable: all the result User Stories in this example seem for me to be 
  • Valuable: overall for every result User Story there is the value given by the why of the first one. Sure it can be written more clearly, but for demonstration it is enough to have it a bit raw here.
  • Estimable: the two result User Stories (inserting the key words and viewing the results) can be estimated. They are not vague. The realtime story carries a huge risk: we don’t know what we have to do to reach this. That one is nearly unestimable.
  • Small: like in the estimable point the two result User Stories fit the small condition too. Also the realtime User Story is here not really tangibly. 
  • Testable: for our result User Stories we can write real easy acceptance/front end tests. Also for the realtime User Story those tests are written easily and fast.

As you already realized, this User Stories describe the Google internet search page. The stunning part is, that we have enough space for the how part. The main benefit of this is, that the Team now has the freedom to ask questions about the wished solution, can be creative in the how and feel really connected to what they build. With this benefit we reach a situation, where they can go deep into being proud: they helped the organization to build something which gives value to the world. And i guess i don’t have to tell you that people with a why and allowed to build it how they want, tend to stay longer intrinsic motivated. So it is a real profit for the customers, the organization and the team.


We looked at what a User Story is, how good ones look like and how to refine them in an easy process. But this is only the tip of the iceberg. There are plenty other descriptions all over the web. For instance Richard Lawrence wrote a stunning article about Patterns for Splitting User Stories. I personally have good experience with the techniques i presented here to you. I love how concise and easy they are. For me they are best practices and i found them useful to start with and afterwards reflect what is fitting better to the team and the surrounding.


Agile Conferences/Camps/…

This is a list of all conferences, camps, gatherings and come-togethers i stumbled upon over the years. It is not complete in any way and is only here for finding them later and (hopefully) for your inspiration!

You see something is missing or want to share some cool stuff? Just leave a comment or direct mail me!