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

Our_Logo_T_Shaped_People

Why we created Practical Agile?

Get your paper tissues ready, as this is a love story. Maybe we should make a Hollywood movie of it someday. Well, jokes aside, it really is, albeit not in the romantic sense.

Elad, Lior and I set Practical Agile in 2012. To be precise, the day the company was minted was the day of the first Agile Practitioners conference, and the two organizations go hand in hand. One is a commercial organization, the other non-profit.

But I am ahead of myself. A little bit of background first.

The three of us, Elad, Lior and I, had various experiences of working in organizations. By using two vignettes (Elad loves it when I use this word) I will divide these experiences into two major groups:

Add a comment