"It is not the strongest of the species that survive, nor the most intelligent, but the one most responsive to change!" - Charles Darwin

Friday 26 October 2012

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!

Friday 19 October 2012

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

Friday 12 October 2012

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.

Friday 5 October 2012

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?