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.

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? 

Duties and Responsibilities of a 21st century employee

Since I started working as Agile coach, I’ve been seeing the same pattern many times and on different levels:

• Individuals committing themselves to learn, by reading books or blogs for instance, even with a defined plan, and constantly postponing this plan
• Teams committing to dedicate time to self-learning, study groups or coding dojos and cancel these appointments many times (even cancel retrospectives) due to real or artificial urgencies and for the sake of firefighting
• Organizations not taking explicit time to reflect and learn from past experiences (btw the only procedures an Agile organization should have are the ones to allow a systematic continuous improvement)

Many times I challenged developers, ScMs, POs, teams or managers and asked what was impeding them to fulfill their commitment to study or learn and the answer I got most times was:

“You know, we have other priorities this week. We’re responsible to ensure this and this and we cannot spend time on lower importance stuff”.

Priorities, Responsibilities..., but what should we really be responsible for in an Agile organization striving in an age of dramatic changes within a tremendously dynamic environment?

Last week I got inspired by a post I read on Crisp’s blog, called Responsibility the Agile Way.

The main point of the post is that people cannot be responsible for end results, because results depend from many, sometimes not controllable, variables. But people are responsible and must be held accountable for good behaviors, because good behaviors and focus on improvement lead to good results. Here is one sentence that hit me and summarizes my thinking as well:

We are all responsible for contributing with our intelligence and senses for the best of the product and the process.

So, if we’re responsible to improve our product and process, why do people not consider that spending time on learning (retrospective, feedback, self-study, etc.) has at least the same dignity as spending time for coding, testing, reviewing documents or any damned operative meeting?

I think the answer relies partly in the modern western culture approach, but mostly in what are the expectations on employees in the 21^st century.

If a bureaucratic organization demands human resources to strictly follow rules, processes and detailed plans to work, a Lean-Agile organization should demand people to continuously improve themselves, their skills, their team and their process as their main duty.

Paraphrasing Steve Denning, I would call it: Radical Responsibility.

And managers’ duty should be not only to state this very clearly, but hold themselves and people accountable for spending time to reflect on how things are going on and coming up with and implement concrete actions to make things better.

Yesterday I was joking (not too much indeed) with a colleague by saying: let’s put Learning in everyone’s Role description.

Why?

Eric Ries gives an answer: “The only way to win is to learn faster than anyone else.”

I also read an article reporting an executive saying recently "If the rate of learning outside our organization is faster than the rate of learning inside our organization, then we will prepare to die."

Are you preparing to die? Hopefully not.

I wish your people and your organization another kind of disease instead: a tremendous allergy to whatever does not work and a victimizing obsession to learn and make things better :o)

The hard job of growing great Scrum Masters - 2

As you might guess, I'm really interested in this subject for taking the time to write a second post about it.

Few weeks ago I was talking with one of the Product Owners in my team (I am currently coaching the PO team). I had asked him to give me feedback on my work and we happened to talk about what I think is one of the missions of an Agile coach: to recognize Agile talents.

Surprisingly enough for me, he could recognize this as a very valuable point, but the rationale behind his belief challenged my current thinking quite a bit.

We came to discuss about what he considered as key characteristics for a potential Scum Master.

"There are some key qualities" - he said - "that a person who wants to be a Scrum Master must have and cannot be learned, regardless how many books you read or how good your coach is!”.

I must say this was a bit hurting my self-esteem: I thought I could teach or help any apprentice Scrum Master to learn practically any skill necessary for the job.
At least until then, when I realized he had a valid point.

But then I asked myself: what are these skills or qualities which are essential to hire a new apprentice Scrum master?

This question reminded me a blog post from Esther Derby I had read some days before, called Scrum Masters and Agile Coaches: More than a Title.

With the usual inspiring style, she talks about what are the Essential Qualities for a Scrum Master (Initiative, flexibility, optimism, determination, resilience, working in a team environment, supportive, not cowed by authority) and what are the Desirable Qualities (Detachment, discernment, Able to navigate conflicts).

However what hits me most is what she calls The Elimination Factors, patterns of thought and behavior that would eliminate a candidate from consideration. 

Here they are: Preference for directing others, defensiveness, judgmental attitude, low threshold for frustration.

The most interesting and surprising coincidence for me was that 2 of these relate exactly to the key qualities my colleague Product Owner mentioned and was able to see given his experience in Scrum: impressive, isn't it?

But what is your view about this issue?

3 things we can learn from TPS

Last week I mentioned my participation to a seminar organized by the Industrial Association of Salerno on Lean Management and Continuous Improvement.

This week I would like to share more about that event, by highlighting what I think we could learn from experiences of organizational transformation and Lean management in other industries together with some (hopefully) powerful questions to facilitate further reflections.

1) Visible problems do not exist: they have been solved already!

One more interesting insight I got from Minoru Tanaka, CEO of JMAC Europe, in his speech about Toyota Production System (TPS) was his classification of problems into 3 categories: potential, invisible and visible. It’s important that potential problems to the desired target are identified as well as invisible problems are made visible and improved immediately. Instead, visible problems do not exist actually, because they have been solved already. 

• How many clearly visible problems are you still stuck with in your organization?

2) Most efficient way becomes standard: standard must be improved every month!

Then Mr. Tanaka discussed about Continuous Improvement, describing that, once a process has been improved in one department, than the most efficient way becomes a “standard”.

When hearing this word, I got disappointed wondering how hell the definition of a standard process could fit into a Continuous Improvement approach.

But then he added: the “standard” must be reviewed every month!

And more: the “standard” is visualized and each manager is accountable to improve the “standard” every month! 

• How much are you still striving to find one-size-fits-all "best practices” to make you move quickly to the next rigid and comfortable status quo?
• What are your managers accountable for? 
• How much are they encouraging the “stop the line” principle?

3) Measure organizational capacity of solving impediments to generate trust

Last enlightening reflection to me was from the local director of a cans manufacturer with around 1500 employees.

You might wonder how cans may be relevant for high-tech industries, but let me continue.

Well, he was describing their transformation journey to Lean and talked about the importance of impediment handling in his organization to be trustable. They have a graph, clearly visible to everybody, with 2 curves: the accumulated number of raised impediments per month and the accumulated number of fixed impediments per month.

The 2 curves must always be parallel, because he said: “If the curve of fixed impediments goes flattish, all my employees will understand I do not believe in what we’re doing and I’m just cheating them”. 

• How is your organization serious with fixing impediments from teams?
• How much are you living the values you’re preaching?

Why Agile?

At the end of May I participated to a seminar organized by the Industrial Association of Salerno on Lean Management and Continuous Improvement (btw a surprisingly crowded event with more than 500 participants from more than 200 companies).

One of the most interesting takeaways for me was from Minoru Tanaka, expert of Industrial Engineering and CEO of JMAC Europe. In his speech on Toyota Production System he stressed the vital importance of understanding “Why” you are doing a Lean transformation and even every single improvement or change, to get a real commitment to succeed.

That’s why I decided to include during my agile trainings a short module called “Why Agile?”

The purpose of this very interactive module is to engage the class in a discussion to share and agree about why they are attending the training, what is the purpose of the Agile journey they want to (or are told to) start and, finally, what are the intended issues they think an Agile SW development can address.

I ran this module 3 times already and I can tell you that the variety of answers is sometimes impressive, showing 2 things at least in my view: how many myths Agile development is surrounded from and how many, sometimes false, expectations come from discussions about agility.

I do not want to list all the answers here and many are right indeed. It’s just that sometimes, even right answers are not pointing to the ultimate goal of agility, but rather to (what I call) sub-products coming from all goods inherent for instance to Focus, Collaboration or Cross-functionality.

The core of the question comes actually from the nature itself of SW development, especially in the 21^st century: SW development is a dynamic complex system, where change is king.

Nothing endures but change!

That’s what Heraclitus of Ephesus said in the 6^th century B.C.

But we all know that changes are going faster and faster in the world around us: current change rate is unprecedented, even change has changed.

There’s only one thing you can be sure of when you start a project: almost everything will change! Requirements will change, environment will change, solution will change, because you will most probably discover things you were not even aware of 2 weeks before.

So you have a choice: you can pretend change does not exist and that your plan will stick or accept the reality and find a way to live with change.

It’s like the law of gravity: you can take it into account or not, but you’d better do it, if you decide to jump off a 30-floor skyscraper ;o)

To describe the core of Agile, I like very much the great summary I heard from Craig Larman at a Conference in Shanghai last June: Agile is mainly intended for a 2-fold purpose:

1. Make changes easy
2. Make changes cheap

That’s what Agile is meant for: it is a framework for applying common sense to SW development in a systematic way.

The hard job of growing great Scrum Masters

Back to trenches after restful summer vacations, I was reflecting about what could be my focus areas for the last part of 2012 as an Agile coach.

Feeling me committed as Certified Scrum Professional to the Scrum Alliance motto "Transforming the world of work", I was wondering what could provide me the highest Return On Investment, given the always scarce resource of my available time and the goal to be a change catalyst for my organization.

Then, as a careful Product Owner, I made some calculations: if I coach a team of 7 people, I will get 7 agilists in the best possible case, but if I coached 7 Scrum masters, I could theoretically get 7 team of agilists.

So: what would you do?

Yes, one of my focus areas should be coaching Scrum Masters to get great Scrum Masters and eventually good Agile coaches to coach even other Scrum masters in a domino effect leading to the transformation of the world around me.

Great plan, you would say, but...

I don't like "Yes, but...", but there's a "Yes, but..." this time. 

If you are satisfied in growing average or inadequate Scrum Masters, well it is not a big deal, BUT most of the troubles we have also in our private life are due to the fact that there are too many inadequate or average people around. 

Instead the biggest concern of an Agile enterprise should be to build self-developing high-level professionals in all roles, including world class developers and high professionals as Agile leaders, either Scrum Masters, Product Owners or Managers: all require high skills, correct behaviors and discipline.

Focusing on Scrum Masters, if you want to get an idea about what a great Scrum Masters should do and how he should behave, you might want to have a look at the Scrum Master's checklist website.

Said that and given the incredible amount of skills a good Scrum Master is supposed to have, growing a great Scrum Master becomes really a hard job, which implies using a lot of different tools and approaches to get the learning through.

I consider 3 pillars as fundamental:

·        Training

·        Mentoring

·        Self-Learning

In particular here is what I found in my experience relevant to be addressed with an apprentice Scrum Master, meaning a person having worked for a while in a Scrum team, willing to become a Scrum Master and, most important, passionate to learn:

·        Dedicated training for a diversified skill set, ranging from Agile leadership, Coaching techniques, to “How to write a good Product backlog”, to SW craftsmanship

·        2/3-months mentoring from an experienced Agile coach, co-preparation of Ceremonies, co-coaching and, what everybody always finds very valuable, concrete feedback by real observation in the daily work

·        Since agility, as we said, asks for self-driven competence management, where people actively educate and improve themselves, self-learning is an essential part, including participations to CoPs, reading blogs and books, watching webcasts or listening to podcasts.

Whether you find this interesting for you or not, enjoy your own journey in transforming the world of work, whatever it is.

Creating a culture of effective SW development

Last month @maubagnato and I completed our first experience of holding a dedicated class about Agile SW development in the Computer Science degree course at University of Salerno.

What a great time interacting with clever guys eager to learn and experiment new things!

It was long ago we started discussing the opportunity of sharing some of our learning and experience with our local university where we hire most of our people from, since we found essential to instill a culture of agility into the new generation of students, who, after more than 10 years from signing the Agile Manifesto, are still taught mostly traditional SW development techniques and lack an accurate introduction into state-of-the-art methods and practices.

Consider that almost no student we met knew even the name “Scrum” before we taught them.

So last year we managed to convince an interested professor to give us 10% of his 60-hours SW engineering class to talk about Scrum and SW craftsmanship.

The response from the students was so enthusiastic, that rumors flew very fast around and another illuminated professor came with the idea of organizing a 20-hours class about Agile, containing all subjects we considered important.

It was the chance we were waiting for.

So we designed our class, which we named “Agile methods and practices”.

Yes, because that’s what we think an Agile team needs to be successful: using an effective method like Scrum to organize the work, but at the same time master effective practices to get the job done.

That’s why we decided to present Scrum in the first half of the course (where we could leverage on our 400+ class hours experience in teaching Scrum to Teams and Product Owners) as a simple, effective and educational framework to help a group of people become a high-performing agile team.

However, being very conscious that Scrum is not enough to sustain an effective agile SW development, we wanted to spend at least the same amount of time to explore together “The Land that Scrum forgot”.
But how to do that?

While teaching and coaching our Scrum teams on SW craftsmanship, we realized how difficult is for people used to develop SW with a traditional approach even imagine how it can be possible to have an emerging architecture, or doing the analysis by writing Acceptance Tests or writing iteratively Unit Tests before even thinking at the code and continuously re-factor the code.

Therefore we needed to create a consistent story!

Our approach was then to zoom inside a Sprint and practically show how a selection of agile methods and practices could be used effectively to transform a User Story in a potentially shippable product increment.

Yes, because this is the real challenge for a Scrum team: get a bunch of User Stories done without doing a mini-waterfall inside the Sprint.

The framework we proposed during the lectures was the following:

• Use Behaviour Driven Development to collaboratively write Acceptance Test scenarios out of a User Story
• Use Test Driven Development and Pair Programming to write the minimum amount of code to make a single Acceptance Test passed
• Use Continuous Integration to make sure you always have a potentially shippable product increment
• Repeat the approach iteratively until all Acceptance Tests are passed and then all User Stories are done

We did this by assigning them a real SW project to develop in teams, partly during the lectures and partly as homework.

Obviously our ambition could not be to make them learn these practices in few hours, but mainly to create awareness and stimulate curiosity about alternative ways of thinking about SW development than what they are taught everyday. However what some of them achieved, regardless the small amount of time available was really incredible, as one can smell from this link.

Given the feedback we got from the students, the class was appreciated, also because of the interactive teaching techniques we used to get the content through.

Thanks also to @desimone71 and @Dario_DeVito for their useful help.

It looks we raised the bar of what these students will require to a teacher from now on :o)

Living in a river of conversations

Last night I came back from my first round of vacation, which I spent leading our summer Scout Camp.

Great time, btw, as usual and refreshing feedback from our guys revealing how many things they learned.

While on the train on my way back, I had the chance to read again chapter 11 of the book "The Leader's Guide to Radical Management” where the author Steve Denning tells the story about how he started to change the way of managing at World Bank: what he calls his initiation into Radical Change Management.

Surprisingly enough, reading this story back looked like somehow reading a lot about the story of our own Agile transformation in retrospective.

Moving from one page to another, I got more and more impressed from how many parallelisms I could draw between Denning’s experience and many things we have been doing similarly, mainly intuitively, which turned out to be success factors for us.

First of all the starting point: a passionate belief in the idea from a small team to inspire and lead the transformation, an energized group of people, who trusted one another, with no role description, but willing to do whatever it took beyond any border of responsibility.

The most effective tool, though expensive, for this team was having a lot of conversations with colleagues, peers or managers, all over the place, to share experiences, enthusiasm, beliefs, understanding and concerns about the deep transformation at hand.

At the beginning, people couldn’t sometimes understand what they were talking about, but finding good stories to tell in corridors, coffee break areas, meeting rooms or even in the canteen, helped some other people understand the idea and build upon it by themselves.

Nothing happened through a traditional change management approach, delivering change upon a certain program and time plan: how could we plan something we didn’t know and never made before?

Instead it grew more organically, based on a shared vision and a holistic approach, but applying baby steps and an empirical process control.

And talking!

Support from senior management was essential especially at a certain point in time, where some people, afraid of losing their position, started to be alarmed by the serious challenge of the status quo and did their best to slow down the change.

Meanwhile the team of passionate believers grew and started acting more openly to each other: they could recognize the different qualities and strengths of each person, while appreciating how much everybody was doing despite what it took.

We had (and still have) a lot of fights sometimes, but we have so much trust and respect in one another, that disagreements make the team stronger and each person better.

And we have a lot of fun, despite the hurdles, the hard work and the frustration sometimes for not harvesting the fruits we thought we should have.

Keep talking is increasing the group of enthusiasts, who believe in the cause and start doing whatever it takes to advance the change.

We are really living “in a river of conversations”: no precooked message to be rolled out top down, but an evolving idea crafted by means a continuous dialogue and resulting actions.

And we learned to put the principles ahead of mechanics: when we run into a new problem we refer back to principles to guide us and adjust what clashes with them.

Reading Denning’s book helped me see also what is probably our main pitfall: not enough courage or ability to make the change quicker which generated, as Denning says, a massive quantity of antibodies and thus an even harder transformation.

Yes, because what we’re talking about, exactly like Scrum, looks easy in principle, but it turns out to be very difficult in implementing.

Nevertheless it is an exciting and rewarding journey.

Do we need managers in Agile?

I think we do!

And I found very interesting what Portia Tung and Pascal Van Cauwenberghe wrote at the end of their session at Agile 2010 Conference:

In an Agile organization, where the managers are freed from the day-to-day project tasks and decisions, we need them more than ever as leaders doing strategic work, removing organizational obstacles, building trusting relationships with technical staff, coaching, providing feedback, assisting with career development and building the capacity of the organization.

Tough job, eh? Especially if you come from years where you were taught doing a totally different way.

In one of her blog post from last year, Esther Derby had an inspiring say about something to remember about managers (especially those in middle management roles), instead of being just easily critical of them.

I cannot agree more.

In the last 2 years, I had the chance to talk to a lot of managers and most time I could feel and sometimes concretely hear a sense of frustration for the many "don't's" they said they were subscribed and by the too few "do's" they were suggested so that they could perform their "new" job great.
BTW, Scrum is agnostic about managers (as it is about technology)!

"Don't tell the team how to do something!"
"Don't take decisions the team can take by their own!"
"Don't speak at Daily Standup!"
"Don't ..."

"What shall I do then?"

I think they got a great point: it looks like asking a person, who was used to nail, to tighten a screw instead by using his/her old hammer.

Agile and Lean transformation is probably the most challenging and difficult change for a company, no matter if big or small, because it affects both business and people – developers and managers…everybody! And just like before, managers must understand the business they’re dealing with very well.

But business is changed and new challenges are out there asking for being adaptable, innovative and engaging for people: therefore, in order to be successful in the new environment, a manager needs to learn a lot, as well as unlearn. So it is crucial to help these people having such a role in the organization find the proper behaviors, skills and tools to nurture successful teams and to help them improve.

On the other hand, the Annual State of Agile Survey 2011 by VersionOne, shows that 52% of respondents see the Inability to change organizational culture and 34% see Management support as top barriers to further Agile adoption, while 32% see Management opposition as greatest concern about adopting Agile.
It doesn’t look like a pointless concern, does it?

Last week I and a colleague of mine delivered 2-days Lean Management training with the goal to kick-off a group of 16 leaders' journey towards becoming effective Lean managers.
Moving from the reasons why a new type of management is needed and the principles of Lean Management, we explored some concrete tools and practices out of the 7 Lean Disciplines. But the basic message of the training was: if you're serious about changing your organization, you must be even more serious about changing yourself.

The problem is that we all know that most times telling and doing are well far away from each other; my philosophy professor used to repeat a quote from Saint Bernard of Clairvaux: “The road to Hell is paved with good intentions”.
The only feasible path I see to improve is to honestly assess where we are, get feedbacks, realize our flaws and take responsibility for concrete actions (baby steps) to move forward.

Wisdom is knowing what to do next; virtue is doing it. - David Starr Jordan

Scrum teaches us having meetings with concrete outcomes and that's what we aimed for during this training as well: each manager left the class with a personal improvement plan of 3 SMART actions to start right the day after. Awesome, isn't it?

And it was even greater to see motivated faces leaving the room, with a sense of urgency for sharing with other colleagues the insights they got during the 2 days!

Improvement takes time

And commitment indeed!
You might ask: "Commitment to whom?". My experience says: "Commitment to yourself!".

I've seen several times many teams striving with practically implementing the agile key concept of Continuous Improvement. That’s why I decided to talk about this subject in my first post: no (r)evolution exists without improving and adapting.

The fact is that Continuous Improvement, as many things, does not happen naturally, but requires some steps.

“Change is inevitable. Growth is optional.” -  John C. Maxwell

The first step is to "stop the line" and take the time to reflect on hot things are going and find ways to improve.
A Scrum team could say: "Great! We have this. We do Sprint Retrospectives!"

The second step is to have effective retrospectives. It means finding SMART actions the team can concretely try and measure results.
A good Scrum Team can reply: "Our Scrum Master is good. We always manage to find SMART actions to implement".

That's still not enough. You need to plan for them to make that happen. And Scrum helps us again here: thumb rule should be that a team plans at least 10% of the Sprint time to dedicate to improvement actions, so that it has the necessary fuel to boost innovation.

The bad news is that this is still not enough. A lot of teams plan time to implement their retrospective actions (even though a lot do not indeed) and still strive to innovate. That's where commitment to yourselves comes into play. If you want to improve, you should take it very seriously and be disciplined in making it happen. Nothing normally happens in agile without discipline.

But discipline could be funny as well. Below is a picture which shows the agreement found by one of the teams I coached: every day one person must work on an improvement action. He/she takes the role of "Innovator of the Day" and deserves a prize: the jacket you see in the picture around his/her chair.

Do you think it is enough now? No, it's not.

Have you ever heard about Active Learning Cycle? The point is that applying an empirical process to improvement as well. It's not sufficient to try things, you have to evaluate the effectiveness of the actions you tried and consciously decide whether to keep or drop them.

Looks difficult? Might be. I'm not saying it is easy, but it is not impossible.