Design Cards!

Gamification is a great thing to get fun and motivation into daily routine. When working on Software there can be long discussions about how to solve a problem or which problem needs more attention. Good, that there are principles like KISS or Divide and Rule. If you’re like me, you will have examples of situations, where the discussion was over and you remembered one of this principles. It would have been marvelous to come up with the right thing at the right time! What can we do about this pitty? Right, train these principles and have something physical, reminding, near the discussions! Luckily there is now something to get this problems solved: the Design Cards from Christian Rehn and Matthias Wittum. They are here to help you memorize and remind you the right things at the right time. Lets have a short look at them:

Different types of principles have different colors.
A very nice box and high quality!

I am happy, that we have those cards now in our team and couldn’t be more keen to see the results in the discussions. For now i can recommend the Design cards fully!

What different types of cards do you have? And what are they for?

As always thanks for sharing and reading!

Scrum won’t fix any of your problems!

Ahhh, it’s out! Scrum won’t fix your problems. Ok, in some chaotic situations it will bring order into the game (like the speaker in the british House of Commons :)). But everything else it will only show you very transparent. You will have to find the best ways to solve your customer problems and yours. You are in charge to fix your broken culture, the conflicts in and between your teams.

Scrum only gives a frame. You remember how the Scrum Guide starts with “Scrum is a framework for…“. And that’s it. A framework giving you the chance to work with consistency and even more important: transparency. If you do it right, you will end up with an endless stream of problems to solve. Scrum shows them unforgiving. You will have to talk frequently about them. And it divides the problems into “how you work”, “what you achieved (or not)” and “what your next goals are”.

Conclusion

A huge pro of Scrum is the big transparency it brings to your organisation. It helps to develop every part of your process in a human centric manner. And on top it is easy to explain!

Hard thing is, that culture is hard to change. There can be resistance. Unaware values can make things even harder. Often you see high expectations and when people realize not everything will end up in well in a wink, they are disappointed.

What are your experiences with Scrum and the expectations at it? What disappointments did you saw? Which resistance did you realized and how did you got over it? Leave a comment and let the world know!

As always thanks for reading and sharing! I hope you liked it!

Scrum is just another leadership attempt

Lets put a finger on some hard spots: Scrum is no silver bullet! It will not fit in every situation. On top it will not be the best solution for every situation. Whenever the humans in the organisation aren’t ready to accept and internalize the mindsets behind Scrum, it will not work.

Next spot i want to look at is what i call the holy knowledge how it should be. The Scrum Guide leaves much room for the implementations. This is on purpose. There is room for finding the best fitting solutions for every problem you and the organisation encounter. You can’t expect that two randomly implementations of Scrum are exact the same. Ok, you can, but you will be disappointed! No two organisations have the same

  • customers and their needs,
  • employees and their knowledge and needs,
  • roles and rules and
  • relationships and contracts.

Having said this, we must step back and admit, that there can not be a role, event or artefact that has to be exactly as you imagine it or saw somewhere else. Everything may differ. And it is ok! I dare to say everything should differ to fulfill the specific needs.

So lets accept, that Scrum is just an attempt how to solve problems. It is a great one, with many pros. But it is not more than one of many leadership attempts.

What is Scrum for you? Have you stumbled upon somebody stubborn? Let the world know and leave a comment!

Thanks for reading and sharing, hope you enjoyed it!

Effective and efficient Daily Scrums

Lets talk about one of the most important meetings in the Scrum framework: the Daily Scrum. It is, as the name says, hold on every day of the Sprint (ok, just on the working days :D). In the daily the team comes together to find out how the Sprint is going, what could be a risk to not reach the Sprint Goal and how to prevent not finishing the most important stuff. With important stuff here is ment the things which give the most business value.

The famous three questions

The most frequent thing you hear or read about the Daily Scrum (e.g. the Scrum Guide) are the following three questions every team member should answer:

  • What did I do yesterday that helped the Development Team meet the Sprint Goal?
  • What will I do today to help the Development Team meet the Sprint Goal?
  • Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?

Lets have a short look who you need in a Daily Scrum. At least you need the team members (not the whole Scrum Team). Often it is good to have the Scrum Master and the Product Owner there too. The Scrum Master can give hints how to handle certain issues or point out risks which the team is not seeing. Also she can help the team focus more on improtant and necessary stuff. So for instance he can point out, that the team is premature optimizing a not yet proven solution or not focusing on customer needs any longer. The Product Owner can be a listening and answering part of the Daily Scrum.

Three questions – the dark side

The risk with the “three questions Daily Scrum” is, that the team is just doing a report. If your company has the structure, that the Product Owner is also the boss of the team, chances are high, that the team is not selforganizing and swarming around the problems, but just looking direct into the eyes of the Product Owner/boss and reporting to him. They will tell him what they have done and what will be done next. But even if there is no such structural antipattern the risk of unseen risks is given in this approach of the Daily Scrum. This risk comes with the three questions, which are easily mistransformed to the following questions:

  • What did I do yesterday?
  • What will I do today?
  • Do I see any impediment?

Maybe you see what happened? We completely lost the focus on the important part, the Sprint Goal. The questions are sounding very similar. If you don’t look, or better listen, carefully, it seems alright, that the team answers the shorter questions. But: without the focus it is very probable, that the team forgets fast which reason they have: the “Why?”, the “What for?”. The team lost the focus on the customer needs. Now the team can fill the fifteen minutes of Daily Scrum with unimportant chat. They can seem very busy and look like hard working, but can achieve no business value at all.

Other reasons for hidden risks can be fear or shame. If somebody isn’t feeling safe, she can come into the state of fear, that is the obvious way and shouldn’t need further discussion. The other way it is possible to become fearfull, if you have a hidden or personal goal. For instance you want a raise or a promotion. Than some colleagues tend to bury their mistakes deep under a mile of talking about nuts and bolts all the time. If somebody is ashamed, because she can’t solve a problem, the same can happen. Important here is transparency and security. Work into the why and fix it as deeply as possible!

Why Daily Scrums?

Short break and remember whatfor we do have Daily Scrums: we want to assure, that we reach the Srpint Goals. Therefore we plan on a very small scale what to do next. And we want to identify handle risks as early as possible. With this early access to the risks, we can plan the Sprint as safe as possible. Back to the How!

How to organize an efficient and effective Daily Scrum

The approach i am writing about is based on Eric Brechners presentation. He is talking about Kanban, but that’s no problem. I tried it with some teams and had great results. The teams were focused on the most important things nearly all the time. It is really simple: everybody answers just the questionAre there any risks or problems for reaching our goals?

  • Are there any risks or problems for reaching our goals?

The focus is just on the things which can go wrong or are already going wrong. First we decide, if it is an important issue. If it is not solvable on the spot, we don’t talk through the solution at all. We focus on the second question:

  • Who will solve this issue with whom?

You can decide to go person by person, story by story or just throwing the question into the room. Just figure out, what works best for the team. In my teams we only asked into the room and gave everyone a look. Normally every issue came out on their own, only sometimes a question about a topic was needed to see the risk.

Later we realized that focusing only on problems, issues and risks is a bit demotivating and we added “Are there joys or are you proud on something?”. That made the Daily Scrum much more fun!

Conclusion

Have you tried this method for Daily Scrums? Or the three questions mentioned in the beginning? Or a completely different method? Let us know and write a comment!

As always i hoped you liked it, thanks for reading and sharing!

Divide and rule in Scrum – the events

Sometimes it is fun to have a look on old knowledge from a different point of view! In this case the old knowledge is Scrum-you’re familiar with it, right? The viewpoint i chose today is the good old divide et impera or defeat in detail! As already announced in the first blog post about the roles in Scrum, here is the next part of the mini-series: the Scrum events in the light of divide et impera. Enough chitchat, let’s dive in!

The events

The official Scrum Guide talks about five Scrum events: the Sprint, the Sprint Planning, the Daily Scrum, the Sprint Review and the Sprint Retrospective. We will talk about them one after another!

The Sprint

I see you asking “How is the Sprint splitting anything?”. I asked myself too and here it is: by taking always small chunks of functionality, or even better business value, putting them into one Sprint and completing them one by one. Seems too simple, right? And it truly is very basic. When the Product Owner does a good job, the developed items are ordered by the maximum value. Here the divide et impera gives us the power to develop every section of the application only up to the point when another one has bigger value. This is one part of the huge power of Scrum – the biggest customer value wins! So we are dividing the “what” into doable parts while staying able to react very fast and not waste time on finishing unused features!

The Sprint Planning

The first meeting and the starting point of every Sprint is the Sprint Planning. It is there to shape the Sprint Goal and how to achieve it. The Scrum Team makes the very first step on the “how” level. Often this is done in two steps: looking for possible ways to achieve and than deciding which way to choose and clear the way further.

Another way this meeting divides and rules is by splitting and sorting: if a Product Backlog Item is too big for one Sprint, it is divided into several smaller ones until something fits in. If a Product Backlog Item is to expensive at all, it gets out of the Product Backlog. Hopefully!

The Daily Scrum

In this very effective meeting the Development Team goes through “how” questions of the most important Sprint Backlog Item. The team focuses on how to reach the given Sprint Goal as best and fast as possible. This can mean to decide who does what till the next day. Who will check which possible prototype idea or who will implement what part (maybe in pair programming with who). We have a further division of the how in a more detailed granularity.

The Sprint Review

In the Sprint Review the whole Scrum team looks at “what have we done?”. It is the counterpart for the Sprint Planning-here we look backwards on what was finished. If the Product Backlog Item was only a part of something, here is the first chance to decide, if we adjust this part, go further on the way or spend time and energy in another feature set.

The Sprint Retrospective

The place to look at the “how we are working” is the Sprint Retrospective. Here is the division: in the Sprint Review we looked at the “what was done”. By this segregation of concerns it is assured, that we have a focus on reaching the goals and improving always over time. So we work to reach our business goals and assure to be or become more agile/flexible/professional/whatever our market needs. This Janus-faced character is a wondrous feature of Scrum.

Conclusion

So we’ve seen, that the Scrum meetings are full of dividing and ruling on different stages and at different times. On an abstract point of view there is no need for breaking things more down than it is done in Scrum. If its done right ;)!

What are your thoughts on the Scrum events in general and in this point of view? Do you have something else you want to read about? Would you like to look from another perspective or do you want to see an other part of Scrum analyzed? Did you liked this blog post? Let the world know it and leave a comment!

Thanks for reading and sharing šŸ™‚ i hope you liked it!

Divide and Rule in Scrum – the roles

When thinking about Scrum what is coming in your mind first? The Scrum Master? The Sprints? The Product Backlog? Whatever it is, lets have a look on it from another angle: the good old divide et impera or defeat in detail! There are many historical persons who are attributed with it. We will not cover this part here, it could be a longer story :)!

With this blog post i am trying something new – at least a bit new for me: a series of shorter posts on a bigger topic. Let me know, if you like this more or the old way of sooo looong articles!

The roles

One part which i love about Scrum is the separation of concerns (sorry, deep in my heart i am still a software developer) of the roles. On one side we got the Product Owner. She, and only she, is responsible for the “what” is done and the “why” is it done. Business value and its maximization is her key responsibility.

Then there is the Team. Their business is the “how”. Nobody, not even the Scrum Master, can tell the Team how a specific thing has to be done. The Scrum Master has the right to intervene and ask, if there isn’t a better way to do things. But the Team has the final say!

Last but not least we got the Scrum Master. Her sphere of influence is the Scrum framework, its understanding and the living of it in the whole organization in the best way possible. With best possible here is ment, that the Team rises to high velocity and stays there. While we have many smaller parts in the servant leadership of this beautiful role, but in my eyes they fall completely under the correct understanding and living of Scrum and the high velocity of the Team.

Conclusion

Overall for me the Scrum Team is the best example of divide and rule! I love, that for every important part of the business there is somebody personal accountable. That gives Scrum the power it has! In the next blog posts you will read about the events, the artifacts and maybe the rules in Scrum corresponding to divide and rule.

What are your thoughts on Scrum in this point of view? Do you have something else you want to read about? Another perspective or another part of Scrum? Did you liked this blog post? Let me and the world know it and leave a comment!

Thanks for reading and sharing šŸ™‚

Daily Scrum Antipatterns

Let’s have a look on a very central thing in Scrum in my eyes: the Daily Scrum. You can find a section in the Scrum Guide and many other places in the web. Living in the heart of every Sprint and every day of the Sprint, the Daily Scrum is the meeting for the Development Team to plan the next day. As you may read in the Scrum Guide, the Scrum Master and others are allowed, but they are not allowed to disturb the Daily Scrum. The Development Team decides how it wants to do the actual meeting. The Scrum Master only has to assure, that the meeting takes place, that the team is able to hold the 15 minutes timebox and that no outsider is disturbing. One common myth is, that everybody has to answer the holy three questions. That’s simply not true. The three questions are a good start for new teams to find a way to talk every day about the Sprint Goal. And that is the point where i want to start sharing my experiences and little stories.

Actual Antipatterns

The first thing i want to share is the “forced three questions”. Here the team lead forced the team members to answer the three questions. Without a doubt, the team had no right to improve or change the situation and was not empowered to organize its work as it wanted.

Another one i saw multiple times is the “i’ve done this and that”. The team members didn’t focused on the Sprint Goal. If you have a close look at the Scrum Guide, the three questions, there is always a “meet the Sprint Goal” at the end of them. So team members chatted about phone calls and refactoring a class and fixing this bug. But the Sprint Goal was not focused. And that’s a problem! The team should focus on the Sprint Goal and find a plan to reach it in the Daily Scrum. It is a inspect and adapt meeting, if the first plan got impediments in the way, the team has to adapt and change the plan.

Very close to that is the “hiding what you’re doing beside the Sprint Goal”. There one or multiple team members did things, which had nothing to do with the Sprint Goal and did not tell anybody. This is a violation of the Scrum Values focus, openness and maybe also respect. When someone of the team is not working together with the rest to reach the goals, it is unfocused and maybe also harming the morale of the remaining team and company.

Another thing what can be hidden are the mistakes. So the anti-pattern of the “hiding my mistakes” is harmful cause nobody will learn from them and they will be done again and again. This is a waste and should not be permitted. Whatever brings a team member to hide a mistake should be taken really seriously. If there is a broken culture, than the Scrum Master must have a look at it. It should be fixed as soon as possible to not end up in a situation where nobody is showing his errors and nobody can learn from them. Without being courageous we can’t adapt to the reality!

Talking about the culture i have to admit one pattern i saw multiple times is the “report meeting”. Here everybody is giving his or her report to the boss or the felt next higher tangible person. So if the boss is somehow once not there, than the Scrum Master is the recipient of the habitual report. There are two misconceptions. First is, that you have to tell what you’ve done and present your personal plan to someone. Second is, that the Scrum Master is higher than the team member. The latter shows a misunderstood Scrum interpretation. The Scrum Team is completely equal. The power is partitioned to have someone responsible for every important part in the development of complex products: the team is responsible for the how, the Product Owner for the what and the Scrum Master for the process. They are equal and together they build something great.

Quite similiar is the “chatty boss”. The boss is talking nearly all the time and even exceeding the timebox. He is giving everyone a task and looking for presenting himself. As you read through all the other patterns, there is nothing to add why this is a sign of not working Scrum.

The “forced metric” i saw and heard multiple times. For instance the team lead forced to fill the happiness metric. Without a doubt, if the team wants to fill a metric, that is clearly allowed. And on top it is a good sign for having some healthy habits. It shows, that the team may focus on side goals or true norths like better bug rates or better code quality. Being forced to fill a metric is a sign for a not so good understanding of theself-organising thingy.

Another hard thing i remember in one team was “the silence” or “the elephant in the room”. There were nearly no discussions or a hard atmosphere. Everybody was happy when the meeting was over. At least it felt like a big burden was gone after the Daily Scrum finally was done. That could’ve had several reasons. A new boss nobody liked or a cold conflict n the team were nobody wanted to get in struggle or some other hidden things. Here it is important to find the root cause and to fix it. Sometimes the Scrum Master can do this, sometimes he has to delegate it to HR.

Conclusion

Many misunderstandings of Scrum and the concepts in it can lead to Daily Scrums, which are not so valuable as they could be. Sometimes the Daily Scrum is a good indicator, that something deeper is broken. That could be the culture or the relationships. Than it is important to make this things transparent and to adapt to the reality.

What anti-patterns did you saw in your Daily Scrums? And how did you handled them? Which things helped and went something to the complete wrong direction? Just leave a comment and let me and the world know about your experiences!

Thanks for reading and have a good Daily Scrum :)!

Management 3.0: #5 Happiness Door/Wall

As you may have mentioned i tried and wrote about some of the Management 3.0 practices before. In this blog post i am writing about my experience with the concept of having positive things publicly visible. The practice i tried out next was the Happiness Door or the Happiness Wall.

Happiness what?

You may have heard of the method of switching the focus toward positive things. This could’ve been in private live, like the positive thinking, or in professional live, like with the Kudo Cards. The Happiness Door/Wall aim on the same thing: pushing the focus towards more positivity. They try to get the positive things more into the awareness of the people around by showing them public and in written form. Everyone at your company is allowed to write something positive he or she experienced on a piece of paper and pin it at the Happiness Door. That’s it. Not much more magic here. The magic starts when you engaged enough people to write something down and your colleagues see it often enough and value it. They can take a bit of energy out of the made experiences and load their heart again with positivity. Nothing more and nothing less.

My experiences

Let me be honest at first: i didn’t found a good place in my actual company for “the Wall”. We have rooms in multiple houses and the rooms were flats before. So we have more stairs than expected and it feels really like Hogwarts if you show guys all the rooms the first time. So unfortunately i only found a movable whiteboard in one of our meeting rooms as the first point to start. In one of our company retrospectives (do you hang around once in a while with all your colleagues to inspect and adapt all the processes? No, try it, it really matters!) we filled it with positive things. It was a overwhelming moment, when more and more positive things came up in our minds. It felt great, when even the hard feeling guys brought something good. Another thing i tried was hanging out the testimonials of some of our customers in one room of developers. It was a mixed reaction: some liked it and some came up arguing why to do this and that there is no benefit in it.

Conclusion

So for me there is a absolute plus in doing things like the Happiness Door or Wall: the positivity comes into the halls. Sometimes very slowly and somtimes it is hard to push it further. But it is absolutely worth playing around with such things. I learned, that in some situations you shouldn’t force the positive energy, because it can end in resistance. And that’s a thing you want to avoid. Or maybe in the resistance lies the root cause of some other problems? I will see

What positivity techniques did you tried? Did it worked well? Were there resisting forces? What did you do about them? How did you handle those things? Thanks for reading and leave a comment if you want to connect in one or the other way!

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!