Daily Scrum or not Daily Scrum, that is the question!

A couple of weeks ago, back from Christmas vacation, I had an interesting view exchange with some Scrum Masters about what to do when the team is not motivated to have the Daily Standup. 

What I experienced is that, when the team argue the value of the Daily Scrum, most time it's because they misunderstood it.

Credit: Playmakers! Theatre School

They normally say: Why do we need a meeting to share what we're doing if we're sitting together all the time and know it already?
I would say that, from this perspective, they are totally right!

The point is that the Daily Scrum is not for the sake of sharing, but it has a totally different goal: stand back for 15 minutes and collectively assess where we are compared to our Sprint goal and collaboratively decide what is the next most important task each team member have to complete to move forward towards our goal.

So what I did in those case is to re-discuss with the team what is the real purpose of the Daily standup. That normally worked! I prefer to call the Daily Scrum as Daily Planning to make the real purpose more clear.

If that didn't work, I would name this as a good chance for the Scrum Master to wear his/her teacher hat and re-affirm the fact that the Daily Standup is a fundamental part of Scrum.

Here the Shu-Ha-Ri metaphor works perfectly.

BTW, are you familiar with martial arts?

If yes, you might know the Japanese concept of the 3 levels a martial artist goes through on his way to get mastery in his discipline.

In the first place, the Shu student goes to the master and simply observes and replicates the master's moves, even if he doesn't fully understand the concepts behind.

When he becomes a Ha, he starts to understand the principles behind the moves well enough that he can stop imitating the master rigidly and start trying different moves.

Finally, when he reaches the Ri state, he finally becomes a master himself: he has understood the principles of the discipline so well that he can shape new moves himself to adapt to new situations and can teach others.

So, it's essential for the Scrum Master to openly share with the team his/her feedback/advice that, since they're probably still in the initial (Shu) phase of the learning curve towards Agile, they'd better follow the practices suggested by Scrum and give them a try for a certain amount of period, even though they do not understand them completely. 

When they fully understand the underlying Agile principles, they can dare and break the rules.

A good compromise here is to suggest to keep the Daily Scrum and stand-up anyway at the agreed time: if they are happy about the daily planning for every team member and do not have anything to add, they can sit down after 1 minute. 

You will see they normally take the whole 15 minutes instead 

A final option could be a healthy safe failure approach, which normally works with kids as well as with teams   

How to build a big product in a collaborative way – 3

Well in shape into 2013 after the end of the Great MayanCycle, let’s continue the posts thread talking about how to help a Product Owner team work effectively.

We talked already about how to setup the team and how we build the Product Backlog collaboratively.

Let’s touch today the way our team grooms and orders the backlog and I will start telling you the story of a failure.

A “good” failure indeed: one of those you learn something out!

Some months ago, facing the development of customer requests based on the business priority order, the team realized that implementing a new feature would have required moving to the new version of a 3^rd party we integrate in our system.

No big deal: they said!

And everything would have been ok, except for the fact that, after some weeks, we realized that the new version of this product was not actually properly working with our new operating system.

Result, as you can imagine, was: a lot of troubles, blaming games, fights, time wasted and, finally, the decision to roll back to the previous version.

What went wrong then?

The question is that requirements are prioritized according to business value, but Product Backlog is ordered instead, taking into account other factors than simply customer priority.

Otherwise, what would be the added value of a Product Owner?

My 10-years old son would be perfectly able to do tasks strictly following a prioritized list given by someone else.

Of course, I oversimplified the question a bit.

But not too much indeed!

However, out of this failure, we learned how to arrange our backlog better, putting into it competence and brains, not only from Product Owners, but from developers and managers as well.

Now, before ordering our backlog, we take into account 3 parameters mainly:

1. Business value
2. Dependencies
3. Risks

So, before giving the backlog a certain order, we evaluate the business value ranking coming from Product Manager, we consider the Product Anatomy and rate both the technical and non-technical risks we see associated to the requested MMFs. 

So the PO team defines the backlog order, putting high in the list not necessarily the most valuable items, but obviously the ones which the others are dependant from. We give special attention to the riskiest features, many times splitting them and touching them first, so that we can have an early feedback and take actions accordingly.

Actually there’s a fourth parameter which comes into play many times, that is cost: since the goal of a Product Owner is maximizing the Return on Investment, one could choose to anticipate cheaper features, given a certain business value.

That’s the kind of brain we have to put in, to move from prioritized requirements to an ordered backlog.

What else would you suggest to consider in order to get a proper backlog ordering?