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.

Bootstrapping a successful Agile Team

When starting up a new Scrum team, you cannot assume that the team starts sprinting right away. 

Setting the foundation for the team success is key! 

Lyssa Adkins very well says in her book Coaching Agile Teams that basically a new Agile team needs to learn 3 things:

• Learn about the Process (for instance the Scrum framework)
• Learn about the Team itself (starting from learning about one another as human beings and then setting the stage for self-organization and cross-functional behavior)
• Learn about the Product to build (i.e. learning about the work ahead) 

But how can an Agile coach make the team learn that?

I normally take inspiration from an interesting story from 17th century to help the team learn in an organic way: the story of the Hudson's Bay Company created by England's King Charles II in 1670.

This company was (and is still today) in the fur selling business: they provided supplies for the hunters who went to the North Canada to hunt bears or foxes and bought animals back from them to sell furs. After a while they realized their business was affected by a lot of hunters dying because they forgot essential supplies. Then in 1874 they developed a practice they called Hudson's Bay Start.

They provisioned the expedition with the necessary supplies. Then they sent the expedition team a short distance in their canoes to camp overnight. This was a test, very necessary so that, before finally launching into the unknown, one could see that nothing has been forgotten or that, if one had taken too much, being so near to the base, the mistake could be easily corrected.

In this part of Canada having the right supplies in the correct amounts was literally a matter of survival!

As I said, I take inspiration from this story and normally organize a Hudson's Bay Start for every newly formed Scrum team with a number of goals: 

• remove the first impediments to start
• check the development environment
• start building the team
• buy time to groom the Product Backlog 
• practice Scrum with a "safe failure" approach. 

Therefore I ask to build a fake application (a bowling game tracker, for instance, but you can find many ideas at http://codingdojo.org/cgi-bin/wiki.pl?KataCatalogue) in order to get the team away from the daily work and take them into a creative environment to let them learn faster and have fun.

When you start something completely new it is better to go out of your usual context, so that people are put on the same level (regardless their starting point) and thus are not afraid to experiment and challenge themselves.

The fake application creates the safe failure environment to practice Scrum, but it must be implemented in the real system and developed by using the actual tools, so that the development environment can be checked by really trying it out.

With a Hudson Bay start, you're less interested in the actual product and more interested in making sure the development and deployment process works.

One could ask: Why are you spending precious team time to build a fake application? Don't you have shipping deadlines to meet?

Of course we have, but it is also a matter of reducing risk.

The Hudson's Bay Start was not free for the Hudson's Bay Company either.

But the alternative for the hunters was dying in the wild!

Is Scrum Master (or team coach) a full time job?

That is a dilemma which pops up frequently and I'm pretty sure you got asked or asked yourself at least once.

Is this a real job or just a bit of meeting facilitation one can do in the spare time (maybe doing it for 2 or 3 teams at the same time)?

Someone told me few days ago: “You know: we have 7 development teams, 5 Product Owners, 3 Technical Coordinators and 4 Project Managers: we cannot afford to have full time Scrum Masters.”

!!!???@#**&%*!?: I thought.

A manager also asked me some months ago: “We decided to have one Scrum Master every 5 teams. Is this ok, according to Scrum?”

Well! The point is not if it is Scrum or not. The point is: what is the probability to have successful teams!

All in all, it's really interesting to see how much this role is challenged everyday, like maybe no other role in any company anytime before. And I also wonder why.

• Is it because we didn't manage to explain it in the Scrum courses?
• Is it just counterintuitive in our western culture?
• Is it simply because we do not have enough great Scrum Masters or team coaches to play as role models and the average players do not think they can (or are not allowed to) provide value besides pulling some coding or testing tasks?

However, this hot subject got up during a retrospective of one of the local communities I’m part of in Italy. While discussing the fears which are preventing Scrum Masters doing their job well, the most voted post-it recited more or less the following:

"I'm always puzzled whether I'm doing the right thing and sometimes I'm really scared because I do not know what to do".

So, what are the typical tasks a Scrum Master is supposed to do concretely to perform his job well?

And how much time you'd better spend on each task as a minimum to make it effective in an average 2-weeks Sprint?

We held a 1.5 hrs workshop and here below a present for you: a nice picture summarizing the results of our discussion.

Awesome, isn't it?

Evidence of few numbers is most times much more powerful than many words.

Getting back to my original question: is Scrum Master a full time job?

What would be your answer now?

Agile development will not solve any of your problems.

It will just make them so painfully visible that ignoring them is harder. - Ken Schwaber

Measures which matter

About one month ago I was following a couple of colleagues discussing on Twitter about measures and specifically about measuring productivity. It was a nice exchange of views on whether development of a new product is production or creativity and what to measure in either case.

I personally think that SW development is most about learning: make an assumption, do the cheapest experiment to validate that assumption and evaluate the results by means of customer feedback. That’s why Agile makes sense.

Now I do not want to come into specifics (I do not know the background of the discussion), but I was thinking: I cannot give THE right answer to the question, but I would put on the table some basic principles about how a good metric should look like.

1. Measure one level up – Whatever you want to measure you might better look at the next level: look at teams if you want to measure individuals, look at the development organization if you want to measure teams, look at the e2e flow if you want to measure the development organization
2. Few, Simple and Visible – Full transparency makes the chosen metric powerful. Don’t over measure.
3. Drive right behaviors – Don’t measure outcomes, but put functional behaviors in place and the outcomes will take care of themselves. You get what you measure.

Some time ago we had an issue about high pressure on teams to deliver (actually from both inside and outside), so that many people (and many influencers in the organization) did not consider important improving as individuals and teams. So management decided to measure teams’ improvement ability.

I’m scared already only by thinking at possible solutions a traditional and bureaucratic organization could have thought about in the attempt of achieving this goal.

We simply tried to apply the 3 principles above and setup a metric called:

Organizational improvement factor = % Total Time dedicated to Improvement actions vs. Total available time. Here is the rationale behind:

1. Measure one level up – We wanted to measure teams, so we decided to measure the development organization: it is not finger pointing to any individual or team, is collaborative and everybody feels accountable for the overall value.
2. Few, Simple and Visible – A unique metric which is simple, updated at each sprint and fully visible on a white board in a common space.
3. Drive right behaviors – Behaviors are a function of people and their environment: this metric resulted to be a good way of influencing the environment and then the teams’ behavior. Everybody feels now that improvements have a recognized dignity.

The same applies when talking about measuring stuff like development productivity or efficiency.

1. What is the next level up which makes sense to measure?
2. How can we make it simple and transparent?
3. What good behaviors should we look for?

In that case I would rather measure organizational effectiveness:

Are we doing the right things and only what is strictly needed? 

How is our Return on Investment?

You will realize that you need to consider delivered value (not only costs) and discover that effectiveness eats efficiency at breakfast every morning: if you drop 50% of the scope because it is not needed,  manage to deliver faster and get money earlier, there will be no cost efficiency program or productivity improvement whatsoever that will give you comparable results.

However, being a team or an organization a complex system of human beings, I would like to leave you with a quote from master W.E. Deming:

97% of what matters in an organization can’t be measured. Only maybe 3% can be measured. But when you go into most organizations and look at what people are doing, they’re spending all their time focusing on what they can measure and none of their time on what really matters – what they can’t measure. Why would we do this? We’re spending all our time measuring what doesn’t matter.

Peter Pan

This week was the time for Scrum Gathering Barcelona 2012, the Global Scrum Alliance event in Europe.

Unfortunately I could not attend this year, like instead I did last year when I went to Scrum Gathering London 2011 (by the way I was one of just 3 Italians attending out of more than 300 people and was actually the only one working in Italy: don’t know exactly what it means, but it doesn’t smell very good anyhow).

On my way to England, I happened to read a nice article on the British Airways magazine describing Peter Pan as an ideal business man. 

Yes, you got it right: a business man! 

This made me think a bit.

Then I realized: Awesome! Peter Pan is also a prototype of a great Scrum Master or Agile coach.

He persuades and stimulates others, leads by example and isn't afraid to get hands dirty when needed.

As a mentor, he can take any young person and mould them into a fearless and vital member of the team.

Socially aware, Peter gives his team a strong sense of community and a reason to get up in the morning. The work is dangerous, however: battling pirates and crocodiles is not usually a career path open to the under-16s, but Peter helps his team overcome all impediments, show courage and face challenges looking impossible at a first glance.

Since he loves to fly and isn't afraid of confrontation, he is a perfect leader and by using unconventional tools out of normal practice (like brandishing a small sword in the boardroom), he gets great results.

His tendency to remain eternally youthful can be grating though: sometimes he can't understand why adults forgot their childhood and refuse to join him to fly. 

Thus, deep down he's lonely, with his only constant companion Trilly who sometimes he's not even very nice to. But as a good servant leader, he inspires trust and makes his team of young people able to do anything and get what they dream.

Well, I must admit I feel like Peter Pan sometimes (and be sure not because I suffer any syndrome).

And you?

Who (or What) is the Hook to defeat in your organization?