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? 

When we will get rid of Agile!

A short break within the Product Owners team posts thread.

It’s December 2012. Finally!

It has been since the beginning of the year that dozens of TV channels and magazines are filling up shows and pages with THE expected event this month.

Yes, exactly: next week December 21^st will mark the completion of the Great Mayan Cycle and the beginning of a New World Age.

I’ve been told by some people recently: “We’re not going to hear about Agile any more in 3 years from now!”

I tend to agree with this. We’re definitely not gonna use the scientific approach anymore and then will not be Agile any more.

The question is: When?

Once a New World Age will come. 

At that time major and maybe catastrophic events will have happened and the following 3 things will have changed profoundly:

1. The nature of SW development
2. The nature of human beings
3. The nature of organizations

1. SW development will not be a dynamic complex system anymore. Software will not be an intangible artifact and developing SW will not be a collaborative activity anymore, because only one person will be able to solve tough problems fast. Finally SW development will not be heuristic, because we will repeat solving the same problems over and over and build same programs the same way.
2. Human beings will change and our brain will become a simple linear processor. People will stop being driven by feelings, thoughts, emotions and beliefs and become perfectly predictable and rational beings.
3. Organizations will stop working as living systems and being complex dynamic networks of brains. BTW, brains will be flat and simple by that time and managers will be able to model their organizations like simple machines, where everything goes exactly as planned and no change in business or environment can ever happen.

This dreaming new era will definitely carry sheltered days, where all complexities are removed and future can be forecast.

I do not have a prophecy about when this will happen exactly, but until then I’m afraid we have no chance.

Complexity calls for complexity: we all would like things to be easier and schedulable. Meanwhile an empirical process control is the only way I know to handle creative work and dominate the chaos coming from a continuously changing environment.

Sorry!

Let’s see what happens with Mayan Prophecy in the meantime.

And if we will still be here, have a restful Christmas holiday and a great New Year!

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

In the last post we said that the PO Team’s job is to collaboratively develop a unique Product Backlog to feed all development teams.

So: how do we do that?

Look at this picture.

We basically do it iteratively, so that at each step we do the cheapest possible amount of work to verify our assumptions, get fast feedback and take a business decision together with our stakeholders: whether continue more or less on the assumed path or rather pivot (or even drop the development).

Given a customer request or a business opportunity, we start writing a Vision of what we’re going to develop (a pitch to explain what we’re going to do and why) and eliciting requirements in terms of needs and problems to solve.

We do it together with all involved stakeholders to be sure everyone is aligned. The requirements are then prioritized and basically divided in 4 categories: must have, should have, nice to have and must not have.

So far we stay on purpose in the problem domain and not consider the solution yet: in order to find the right answer, it’s better to spend time finding the right question.

And whether the question is worth being answered indeed.

The next step is to make a quick architectural analysis and try to identify a possible structure of MMFs (Minimum Marketable Features), which makes sense for the highest priority requirements. This requires again a collaborative approach with stakeholders and, if the team does not have all the needed domain competence, a PO pairs up with a system architect to get some help in the high level solution sketch which will inform the coming backlog preparation.

At this stage, a first cost estimation is provided: a relative cost estimation in story points, having actual efforts of already developed features as baseline.

MMFs, for which business opportunity is still considered valid at this point in time, become part of our global Product Backlog and represent items which can be pulled by any PO in the team to be worked upon and produce more detailed items in a hierarchy from epics to really INVEST User Stories. Pairing within the PO team and involvement of development teams, as well as collaboration with people from QA and Customer Support, help build high quality backlog items as a necessary condition to be able to build a high quality product.

The cost estimation is refined iteratively, leveraging on estimation from development teams actually doing the work.

A release plan is also provided, either as scope first planning, leading to provide a possible lead time interval, or a date first planning, leading to a scope scenario interval. The release plan is updated at the end of each Sprint taking into account historical data on team velocity and possible re-estimate, give the newly built knowledge in the iteration.

Daily work on the different global backlog items is followed up during a 15-min standup and work planning for the coming day is collaboratively agreed, considering which are the most important tasks to be accomplished to come closer to the project goal.

Next time we will have a look at how we groom and we order the global Product Backlog, so that the whole organization, including the PO team, is focusing at any point in time on the most important items.

How to build a big product in a collaborative way - 1

What happens when you have a product too big to be built by one team within the timeframe needed by your business?

You might answer: Well, I allocate more teams and then create an organization structure where each team is accountable for their part and with a project staff, headed by an expert project manager, to coordinate everything.

I do not want to judge this answer. However let’s have a look at the Agile principles:

• Business people and developers must work together daily throughout the project.
• Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done
• The best architectures, requirements, and designs emerge from self-organizing teams.

What do I get out of this??

Well, first that SW development is a collaborative game by its nature: there’s no complex problem which can be solved by one person in a time which is compatible with modern business needs.

Secondly that self-organization and servant leadership are some how embedded in being Agile.

Furthermore, if you look at Scrum, you will find only 3 roles: Scrum Master, Product Owner and Development Team.

I'm sorry: no project manager whatsoever.

Beware! I’m not talking about people here: there are plenty of great project managers serving with passion and competence their organization. 

I’m rather referring to roles and their effectiveness in an Agile context, in terms of: What is the probability I might have success in an evolving reality?

Said that, what I would suggest to a Scrum organization is to setup a Product Owner Team.

Yes: a self-organized team formed by all development teams’ Product Owners collaboratively working together. And I’m suggesting that, because I’m currently coaching a PO Team and I would like to tell my experience through this and some other post I’m planning to write.

Of course a team does not make sense if they do not have a product to build: the PO Team’s job is to develop a unique Product Backlog to feed all development teams, so that the following is ensured:

1. the whole organization is focusing at any point in time on the most important items
2. the development teams are as much independent as possible so they can move fast with little need to coordinate each other
3. the overall architecture of the system is preserved 

Like any other Scrum team, a PO Team might better have a Scrum Master or Team coach (it’s just me in our case) and a Product Owner, who is in charge to give a final word on the overall priority in case of conflicts.

To tell you our story I will start from the beginning and that’s the team setup.

In a recent post I described how it is important for a team’s success to set the stage to high performance and that’s just the same crucial if we’re talking about a group of normally quite senior people who need to learn how to collaborate for serving the entire organization at best, instead of only cultivating the silos they felt responsible for.

And we really started from the foundation by writing together our team vision and the ground values we wanted to build our team upon, as you see in the pictures below. After few months I really recognize that this exercise had proved to be tremendously effective.

So we set the first draft of our working agreements.

Since I wanted to introduce the Scrum values in the team in an organic way, I let them decide completely how to organize in the first place and here come our ceremonies:

• Global Backlog grooming once a week
• Global Release planning once a week
• 15-min daily standup everyday
• Review of work done at least by another team member according to our Definition of Ready
• Team retrospective once a month

I will describe each of these ceremonies, make you see our awesome task board and tell you how we build our backlog starting from customer needs in a number of coming posts.

Talk to you soon!

Cultural transformation through deliberate practice of behaviors

This week I was at LESS2012 conference.

The conference overall was really interesting and I would like to start right away to share with you the 3 most inspiring things I brought home with me from the sessions I attended.

1. The first one is from Jurgen Appelo’s keynote.

The whole performance rocked as usual, but I'm sure you will agree that the following concept is really great. He said that the verb “Manage” come from Italian “Maneggiare” and from French “Menage” which originally meant “drive and take care of horses”.

So Management is actually driving and taking care of organizations as they were living beings and they are indeed. That’s why management is too important to be left to managers: we must all lead.

2. The second great quote is from Beyond Budgeting track hosted by Peter Bunce (Chairman of BBRT) and Bjarte Bogsnes.

They echoed Steve Jobs saying: I discovered that sometimes the best innovation is the company, the way you organize the company. 

We need a more self-regulating way of management. We all agree in principle with this, but the problem is bringing this to practical consequences.

Most companies say or write that, but the problem is what we do, not what we say.

There are most times gaps between what we say and what we do and this gap is poison for the organizations.

3. Last reflections come from the other 2 keynotes.

Christopher Avery pointed out that traditional managers are always looking for single point of accountability, but collaboration does not work with single points of accountability.

Esko Kilpi added that from a social business standpoint, the individualistic view is fundamentally misleading: there's co-creation. So is the sense of personal responsibility. The new competitive edge will come from openness, transparent information and collaboration.

Awesome, isn’t it?

On the last day I held my workshop Learning to be a manager in the age of Agile.

The question I put was just the following.

If all the changes above are needed in 21^st century management, compared to current mainstream management (still focusing on the very same practices invented more than 100 years ago with totally a different goal than making our companies responsive, adaptable and innovative), what is a feasible path to get there?

The proposal I made is based on 3 steps:

1. Challenging current management beliefs
2. Challenging your actions in the light of Agile and Lean principles
3. Deliberate practice of functional behaviors in line with the principles

The idea is to break the maps wired so far in our brain by all experiences and beliefs in our life and which we follow naturally like a river bed to interpret the reality. Then build instead, drop by drop, new side river beds, which could allow us to see the reality with new eyes and act accordingly.

After the conference I had the pleasure to discuss this approach with Dawna Jones, who very well pointed out how just focusing on behaviors allows to achieve only short term and not permanent cultural changes.

I agree this is very true and indeed in line with the approach I suggested. Deliberate practice of behaviors (like deliberate practice of technical skills) and continuous self reflection are just ways to understand the values behind. This will allow behaviors to become habits and enter deeper in our brain and heart to create new beliefs, new assumptions, new structures and ultimately a new culture to provide different responses to our evolving reality.

It’s the management Shu-Ha-Ri!

Wearing the right glasses

Last night I made a strange dream.

I was tiny small, while very big words were flying around me and suddenly thrown in a gigantic mixer, which put them out in a changed order, building completely new sentences.

Different kinds of sentences and words were undergoing the mixer and came out changed.

Among the others I saw the 7 Lean Disciplines: they came out of the mixer like this.

- Eliminate quality

- Build Waste In

- Create Knowledge

- Decide as early as possible

- Deliver as late as possible

- Respect the whole

- Optimize people

One of those sounded familiar to me, but the rest? 

Am I seeing right? Am I wearing my glasses?
Were they changed to the "The Fat Disciplines" instead? Was it a dream or a nightmare?

I woke up sweat in the early morning and started reflecting with myself.

I got to compare the Fat versus the Lean Disciplines to evaluate, not which are the most effective, but simply which are the most sensible to really manage the business we're in.

The life would be great if I could give a specification to my team and ask them to commit as early as possible that the project will cost 96.356,55 EUR and will be delivered exactly on October 20th, 2013 at 12.45. Why can't I do that?

Well, just because that's the life.
Most of us might have experienced a certain degree of comfort in having a detailed plan in place and believing to have everything under control...
...no matter if the plan turned out to be no longer valid maybe just the day after.

Yes, but that would be developers' fault who were not precise enough with the planning or want to cheat me. And by the way, they are tremendously lazy.

No, it's just because building SW is a complex system made by teams of people which are a complex system as well: you do not know your final destination and the system is non linear, so how can you predict the exact steps to reach it or when exactly you will land there?
Complex systems have their laws (smell some flavour at here) the same as we are subject to the law of physics.

So why can't I simply decide a plan and stick to it?

Well, because complex systems are not deterministic: things change, there's not full visibility of the whole path, knowledge of the system increases on the way and new things emerge. Having quick feedback loops is the only way for you to learn as fast as possible.

Mike Cohn tells how Trond Pedersen very well describes this subject: "Complaining about requirement change is like complaining about the weather. You can't really change how the world is, but you can find ways to deal with it. Don't make an offering to Thor (the Viking god of thunder) to make the rain stop: get an umbrella".

So it's only your risk if you get an umbrella or not.
It might sound a bit less comfortable, since we must learn to live with some level of uncertainty, but isn't it just more sensible?
And maybe a bit more scientific...

Reflecting around, it was finally time to get ready and go to office. I made sure I get on my glasses.

We might not talk about Agile and Lean in 10 years any more, but they are definitely the glasses to wear to see and understand our business now.