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

Conclusion

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.

Conclusion

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!

(Agile) Games

I was really excited when i discovered “Magic Maze” at the Agile Coach Camp Germany 2018. The game is a real fun way to understand each other and the planning factor. Later in this year i stumbled upon “The Mind”. There the key is to find a common … hey, i really shouldn’t tell this secret here! It is a real great way to find a common feeling in the team. And on top it is strange how you feel (and later on loose the feeling, just to recover it again) the spirit and the mind in this game. I am overwhelmed and recommend this game for team building too.

For a bigger variety of games and more experience in social games i started to search communities in my nearer surrounding (around 100km around my hometown Freiburg in Germany)… and i found a great thing in Basel: the play14 chapter in Basel. Play14 was founded cause they were motivated by the “hey, the play4agile is booked”-shock and did not just wanted to complain. It is inbetween a movement and an unconference, where people show up and talk about how to play and actually play games.

play14-movement, copyrights at play14
play14-movement, copyrights at play14

Overall i am really happy, that i found the games, the fitting community for them and so much fun in bringing some laughter beside the bad jokes (ok, some are really great) into our offices.

Do you know some more great games? And some conventions, (un-)conferences or whatever format for playing and games?

Let me and the rest of the world know it by leaving a comment! Thanks and have a beautiful day!

Book review: the dip

In this book review i will tell you a bit about one of the books of the great Seth Godin. You never heard of Seth Godin? Then you have a task to find out who he is! (For all the guys who have not much time: he is not only one of the marketing gurus, for me he is the marketing guru. He brings whisdom and razor sharp conclusions into books which lift you up and tell you how to go and where to go and why to go or stay… sounds good? Its worth!)

Now we’ve set the stage for some parts of whisdom we can extract from the book: it is named after the key concept, which Godin is gifting us:¬†the dip. Sounds clear and easy? Lets come to the explanation! Whenever you face a situation where you could quit, there are mainly three different curves you could find yourself in: the dip, the dead-end road and the cliff.

The dip

The dip is the point after the easy starting days, before everything pays off. After you learned a bit of a new language. Lets assume you are new to asian languages and go for it by trying to learn mandarin. After the easy first words for daily usage, you will somewhen come to the idea to learn some letters. And than it gets hard. You realize, that there are over 100.000 letters in mandarin. Okay, for daily usage its enough to know around 3.000. Which is nicer, but also hard to learn, if you’re a mediocre european, who never learned an eastern asian language. So after the first words you wake up in a situation, where you know how much work it will be to be able to have a normal exchange of letters with a friend in mandarin. This is the dip. The motivation and results curve is going down. And it can stay on this bottom for a tremendous time, until it gets better and you see more results. Its like the desert walk, and after two days you finally reach something like an oasis. The good point about it is, that there is a better time afterwards. The bad part, on the other side, is, that you have to go through the dip, to have more and better results.

Other curves

Beside the dip Godin named two other curves: the dead-end and the cliff. The dead-end, or cul-de-sac, is a situation, where you find yourself investing time and it doesn’t change anything. It is like the famous fight against the windmills or the Sisyphos stone. You can try harder and harder and end up always in the same spot as before. Often this is the case in smaller companies: you can reach a certain carreer level and thats it. You will not climb higher there, even if you buy certificates (ahem, i ment improve yourself). This can have several reasons. It could be, that you reached the level under the CEO and he is not giving more too you. Or there could be an overflow of guys on your level. Often only one gets the chance to climb a step further, the rest stays there. Sometimes even all the willing guys don’t get a chance: some extern dude gets the job. Sounds tragic, but its a dead-end, which will not lead you anywhere.

The dead-end is the better curve of the “other curves”. The other one Godin talks about explicit is the cliff. The cliff is, as you expect, a situation, where you see it coming: the tragic end. You literally know, that it can’t end well. For instance if the sales of the company decrease month by month and nothing in the strategy changes. Your company is maybe on a sinking ship branch of economy, like mass production of carriages when the first cars evolved. Or you find yourself in a company, which isn’t caring, what any of the customers want and the product is only fulfilling requirements nobody needs. In the best case these example companies get bought by some other company because of the employees or some other assets. The worst case is that they go bancrupt. If you’re like me, you don’t want to waste your time in those environments.

Another curve Godin points out is the market distribution. As also described in “The Long Tail” he tells, that the biggest fish in the market segment gets plenty times more of the revenue than the number two and number three combined. In the long tail they focus on the niches, on the number ten till to the end of the market. Godins viewpoint is, that you should always look for being number one in the world. Just for having the chance to get two or three times more than number two and three combined. Than you can build a dip on your own for new competitors. If this is to hard, you can focus on a part of your market or change the market complete. The latter is a bigger risk than going deeper in a part of your market.

Is it a dip? And if so: what’s next?

Godin gives some tips on how to find out in what kind of curve you are at the moment. For instance in the end of the book is a list of questions, which helps reflecting yourself, your life and your carreer. Very powerful! But the point which really excited me was that he comes up with an easy, but really cool change of the viewpoint. You should think before you even start and decide what¬†quitting conditions you set. Before you start you can think about what benefits you will have behind the dip. If there are plenty of benefits, you can decide, if they are worth the invest. If they are worth the invest, you can think about, if they are really worth for you or if there is something else giving more benefit to you and your plans. With this little steps you seperate the unthought and fast forgotten starts of a new hobby (how many guys do you know with once used skis, dumbells or things like this?) from the real beneficial things. For everything which sounds cool, but is not giving you a thrill for at least a year, isn’t worth starting. A big point to not start and quit stupidly everything which comes in your mind, you decide while starting when to quit and why to quit. So everytime you decide to give a new hobby a try, you give yourself the conditions when you allow yourself to quit. For example: my decision to blog again has the conditions, that i would quit, if i don’t find anyone reading my blog constantly in a year. Than it makes no sense to blog in public and i can go to a private blog/diary and save time by not watching my style and grammer and switch to my mother language german. With fixing the quitting scenario you bound yourself to the new hobby or passion until you find yourself behind the dips. This prevents you from quitting in panic. Because you can directly go to your conditions to quit for this thing and (wo)man up by saying “ok, its (a bit) hard right now, but i can’t allow myself to quit now”. I really like this idea to define front up what circumstances you would allow to drive you away from the new part in your live.

So the way to not quit unthought in a dip goes over the clever starting, defining the conditions to quit before starting and deciding to do all this more aware than up to now.

Overall for me the book the dip¬†is a diamond. It is full of wisdom and thouht-provoking impulses. Thats the big value. It is short, concise and really fun to read. You really want to read “only” this next chapter. And another one. And than it is over and you know: i will read it again, to be sure, that i don’t forget everything in a blink. This conciseness and fun are the polish of the diamond Seth Godin gave us with this little book. An absolute must read for everyone who really want to live more aware and push all his or her games to the next levels. Thanks for not quitting to read this long article!

Think on different organizational layers

When i started to learn about Scrum, it was a great mind opening pleasure for me to have some easy rules combined with a set of values and best practices. Over the years seeing multipe more or less agile surroundings it got crystal clear to me, that without the management support Scrum can only work in a small scale. At best on team level. But often without a good environment its doomed to only give some team members an inner peace. With this differentiation somehow i started to look for habitats where everone is convinced to go with a process. But this was not all what popped up in my mind. After a while i realized, that there are more layers than a person and a team. Sure, its really obvious, but here’s the observation:

  • teams are composed of team members,
  • departments are composed of teams,
  • companies are composed of departments,
  • companies have partners,
  • companies have customers,
  • companies have competitors in markets and
  • last, but not least, there is the rest of the world.

What can we do with this list of layers as for instance as a Scrum Master? First of it all it helped me reflect my (re-)actions. So whenever i get a question from any team member, i try not to answer immediately. I started to ask myself things like:

  • What would be best for this team member?
  • What would be best for the team of this guy?
  • … and so o, up to the whole universe

This little thoughts made my answers more holistic and helped to build a better environment. The next step i am going with these questions is, that i start to open the minds of my team members and colleagues by asking them back. So if somebody asks me “I see, that XYZ is happening between colleague A and colleague B. I feel the urge to do something about it! What should i do and where should i start?”, than i can ask him back

  • “What would be best for your team?” followed by
  • “What would be best for your department?”
  • and so on…

Twice i already remembered to go this way. The interesting point was, that the questioner came out of the mind of doing things for the sake of doing things into a state to deeply think in a bigger scale. The best part about it was, that both persons understood the problem better and saw how hard it will be to find a good solution. As you recognize, i am not talking about the best solution, because you never know, what would be really best to do. Sometimes there are only bad solution and you’re doomed to find the least bad solution. But with the knowledge, that there are many solutions i find myself often giving more valuable answers than before or i even lead by questions.