Bugs_Per_Sprint_Gauge

We have a bug in our industry: We over glorify bugs. We love them so much, that we use them as a primary metric for quality.

My take is that that is a bad idea. Bad, as in driving undesired behaviors that are misaligned with our desires to improve quality.

Let’s begin with an analogy, and then move to modeling this on software.

A tale of two restaurants

Joe was hungry. He was on a business trip, and it was lunchtime, and he just entered Bologna, an Italian restaurant.

It took almost 3 minutes before a host led him to a table, which was set up simply, yet invitingly. There were some loud voices from the kitchen, and Joe wondered what they are arguing about. When the waitress came back he ordered a pizza, which he noticed was recommended in reviews on TripAdvisor. While he was waiting for his order, he saw the staff going around customers - acting nice, but not overly nice, smiling from time to time, but not overly eager.

Add a comment

Fun Effective Meetings

We all love them. Those hours of pure fun, creativity and innovation. Meetings.

How come that we love them so much? Is it the coffee? Is it the the comfortable chairs and large tables? Is it the fact that we have time to break another world record in candy crush?

Now seriously, why is it so common for people to hate meetings? Why do many of us continuously complain about the fact that there are too many of them?

Probably because in many cases our meetings suck (This is a technical term BTW).


 

Often meetings are just a waste of our time. They are ineffective, lead to no action,unfocused and we feel that we could have had better use of our time instead of sitting in this large room filled with people.

The good news are that It doesn't have to be that way.

Some meetings are not a waste of time, some meetings are considered valuable by the participants. How you ask?

Below are 10 tips to amplify the effectiveness of your meetings, I hope that after reading this you will schedule a meeting to share it with your team ;)


Tip 1: 5 minutes to empty your mind (brain dump)

Meetings can sidetrack, in fact they often do. The reasons are ranging from a discussion about a movie or a concert we went to, to office gossip and the latest new open source project discovered.

One Scrum master i have worked with experimented with a way to reduce this behavior by allowing 5 minutes of brain dump at the beginning of every meeting. It helped them improve meeting focus, it may help you as well.


Tip 2: facilitate

Meeting don't just become effective out of the blue, it is a result of deliberate action and specifically facilitation. Do you have a facilitator to your meetings? Does she have the skill and knowledge to effectively facilitate a meeting? Was there enough time to prepare the format?


Tip 3: Start on time

Meeting are often scheduled in advance, which means participants had enough time to make sure they can arrive on time (there are exceptions).  And still what if people are late, to me it often means that they do not care enough about the meeting (what if the meeting was to ruffle 10,000 Euro - would they be late then?), if people are late you need to examine the reasons and in the absence of good reasons, define working agreements that will allow this to work. Examples are:

  • If you are late you are a silent observer.

  • If you are late three times, we stop inviting you to the meeting.

  • If you are late you should bring refreshments.

Tip 4: Finish on time

People are busy, some of the hop from one meeting to the other, back to back meetings are not rare. If you do not finish on time your own meeting, how can you expect others to do so, also this will probably be a factor in having people being late to other meetings. If the time is about the finish and you think more time is needed, consult with the participants what would be an effective way to continue, avoid extending the meeting for “just 3 more minutes”.


Tip 5: talking stick

This is a very popular tool originated in Indian tribes for meeting with the problem of having people talking over others.
The concept is to have an object and only the person holding that object gets to talk, then when the person is done she can either place the object back at the center or hand it over to another person she wants to hear.


Tip 6: talking tokens

Have you ever been to meeting where one or two people take over the meeting and just never shut up? I have. One solution i have found it to give tokens based on the time of the meeting.
Example: for a 60 hour meeting i would assume the facilitator would take roughly 10 minutes, which leaves 50 minutes for the participants, so if there are 10 participants each one gets 5 tokens that can they can use. Whenever they want to speak they need to pay a token and a timer starts, after the minute passes if the person wants to continue they need to pay with another token. Simple & effective,


Tip 7: Digital equipment - out!

Please please please!!! Leave all your electronics outside unless they are super essential. Place a box at the door for phones, don't allow laptops in, they are the most distracting things ever!


Tip 8: Avoid projectors

One of the things that causes people to fall asleep are long and boring presentation, especially when lights are dimmed or off. This is normal but can be avoided many times, How?

If you have only a few slides, can you copy them to a whiteboard or flipchart?

Provide handouts to participants with the diagram you want to explain?

I bet you can come up with more ideas..


Tip 9: Be prepared

If you are about the host a meeting or attend a meeting, be prepared, preparation may mean to check that you have all of the knowledge expected, that you have enough time and mental capacity to attend effectively, that you understand your role in the meeting, are you an observer?  A contributor? A facilitator? Once you know, one suggestion is to act based on your role. Are you unclear what your role is? In that case you should probably read tip number 10.




Tip 10: Don't attend meetings

I beg you, PLEASE… Stop attending meeting that you don't need to, don't go just because you are invited and you feel obliged, this is probably one of the major reasons why meetings become ineffective! If you are not absolutely sure you need to be there, you probably don't. If you do not have a good understanding why this is an important investment of your time, just stay in your chair and do stuff, or go and have a cup of water. I know some organization consider that behavior to be rude, if that is the case for you, you probably need to call a meeting to change that :)

 

I hope you find these ideas useful, if you do and if you don't please let me know by commenting.
Got other tips? Please comment.
For more, follow me on twitter @eladsof

 

May the force be with you,

Elad.

 

Add a comment

Yes, this blog post is going to talk about agile. But, first, let’s talk about money - who doesn’t care about how much money does he have in his bank account.  

If your income is significantly higher than your expenses - you have nothing to worry about.
However, in most cases this is not the case. My life has taught me that no matter how much my incomes increases, my expenses increase accordingly. I am putting more money in savings, I travel more, and in general I enjoy life more. 
Once in a while I notice that I am losing it. Enjoying life costs me more than it should, so I either need to cut down on my savings or put more control on my expenses… 

Usually, what happens at that point is that I am trying to pause my intuition. I believe that I have a really good idea where my money goes (restaurants or cloths) and I try to cut down on my expenses there. Surprisingly, nothing changes :). So, I am taking the situation seriously, and I begin to collect the data. Every day or two, I write down what did I spent the money on. Now, I can easily understand two things:
1) What I am really spending so much money.
2) The trend - What’s my status going to look like at the end of the month if I will continue with this trend.  

The big pro of basing my decisions on statistics is that I can easily adjust my behavior immediately based on empirical data compared to my goals. It takes me only 2 minutes tops (every day) to do it, and in the end of the month I am still smiling.

So, why did I tell you all of this and how it relates to agile and scrum? 

This is exactly what frequently happens every time with many scrum teams.  

Burn Downs Chart

Every day, during the daily meeting, the scrum team is gathering up in order to answer the following questions: “Are we going to achieve the sprint goal? If not, what do we need to / can do differently?”

Most of the scrum teams I work with, answer the first question based on intuition and not based on real data and statistics (which would be very easy using a burn down chart).

  • For some teams it works well  - and then great, continue exactly as it is! 
  • For some teams it works really bad. We can compare it to a family with a big debt on their bank account, who will do whatever needed in order to survive. Then, they will do whatever is needed in order to track their progress out of debt and back to credit. 
  • For many teams (maybe even most), they believe it works very good (some will call it “wishful thinking”), when actually every time in the last two days of the sprint, they shockingly get surprised of the remaining work they still have to do in order to achieve sprint goal.

 

Here is a real  life example of one of a scrum team board. I would like to examine your intuition vs. statistics: 

* The team had 7 working days in that sprint 

Let’s see what your intuition will say after 2 days into the sprint (out of 7)?

 

 

 

I would say, it seems good. The PBI #1 almost done, and it took us only 2 days. PBI #2 is already half way, and we already started PBI #3.

Now, let’s look on the burn down chart after 2 days into the sprint:  

 

* The red line is the team’s remaining work over time. The green line is the theoretical ‘perfect’ progress rate.

You can easily understand that if they are not going to close up the gap they will not achieve their sprint goal.

 

Now, let’s take another look on what happened after 5 days (we have left with only 2 days till the sprint ends):  

Based on the Scrum board I have a great feeling… Look at how much work they completed in 5 days. What’s left is about a fifth of what we already completed so my intuition says that we can make it! 

However, what my intuition doesn’t take under consideration is the amount of work that was added during the sprint. Also, sometimes, we are biased by the first column and don’t take into account that the intuition that neglects work that is already in progress but not done.

While looking at the burn down chart, in one second we can see there is no way we are going to complete all the 3 PBI’s (Actually, we could tell that to the PO already on day 2).

Combining the scrum board and the burn down chart, we can also understand why this happened. There is a lot “unplanned” worked that was added to PBI #2, mainly during day 3 (great input for retrospective). 

 

Question: How long does it take to create and update the burn down chart? 

Answer: Create about 5 minutes (if we want the lines to be straight). Update - it is maximum 2 minutes (we need to count all the work in the “To do” column and in “In Progress” column).

Let’s go back to our money again. When we are talking about our money, I can understand why we wouldn’t want to face the hard facts as soon as possible. When we do that, we might need to skip the next vacation, not to buy this beautiful shirt, or even (heaven help us!) starts to cook at home. However, when we are talking about our day to day work: If we do the burn down chart, we are gaining  the ability to adjust our plan, improve our predictability and transparency, and bring back the smile on our manager’s and PO’s face. When we do not visualize both our work and trend-over-time, we miss all of that, and earn nothing instead.

So I have this question for you - how come there are still so many teams that perform poorly, and yet are not using burn down charts? Could you please help me understand that fact? 

P.S.
Here is a link to view the entire 7 days sprint - Please use it in order to explain your team members why a burn down chart is a great idea.

Spoiler: In my next blog post I will explain the additional data which we can collect from the different types of burn down/up charts 

Add a comment

Iceberg_As_Metaphor_for_Process

We got this one wrong, us the IT people. We view process through a rather narrow prism, so much that we grew to value “Individuals and Interactions over Processes and Tools”. But process is way more than just a set of activities that get executed in a specific order. 

Wikipedia alone has about 40 different disambiguation values when looking up “Process”. But the most concise definition is the following: “A process is a set of activities that interact to achieve a result”.

In many ways when we talk about a process we omit the latter part: “that interact to achieve a result”.

Start with basics

Take chemical processes, as an analogy. Say you want to make mayonnaise. You take an egg, oil, lemon, mustard, seasoning, and combine them in a very specific order. Should you change the order to activities, you might spoil the process, and get something, which might be tasty, but is ultimately not mayonnaise. That’s the set of activities involved in the process.

But the ingredients also interact to cause a certain set of chemical reactions. Without those interactions you will not have a mayonnaise, either. For example, if you used a boiled egg or a stale lemon, you are unlikely to achieve the desired result.

What more, if you get the ingredients and do -nothing-, other unplanned (and undesired) additional chemical processes will interact and prevent you from using those same ingredients for your desired gourmet mayonnaise. Your egg will go off, your lemon will become moldy, well, you get the point.

Add a comment

“A good Scrum master can serve a few teams. A great Scrum Master will serve only one”.

rephrasing Michael James

 

There’s an ongoing debate on whether a team needs a full time Scrum master for the long run or not. Many teams feels that the duties of SM only fills a part of his day, and therefore he can do more than "just be a Scrum Master”.  In some cases the expectation from the SM was to pick up tasks like any team member, in other cases the SM was working with 2 or 3 teams in parallel, and in other teams spread the roles of the SM between various team members (and not having a dedicated person as the SM).  And there are of course many more options.

and honestly speaking, all are valid solutions that can be really effective. What I did learn over the years though, is that no matter how you approach this, you should always keep in mind the following when you decide on how to approach this:

Add a comment

How can we help?

Email:
Subject:
Message:
multiply one and three and get

Register to get notified about new blog posts