A conversation with the CIO community

Leadership quote by photosteve01 / CC BY 2.0

Last June I had the pleasure to get my interview published on Netweek, the biggest magazine for the Greek CIO Community (the Greek IT Managers are both readers and editors). 

I am thankful to George Fetokakis, Editor-In-Chief of Netweek to make it possible and for the interesting questions.

Since I realized that the interview was only published in Greek, I decided to post it here in English and share it with a bigger community.

Trust you will find value in it.

Looking forward to your feedback and comments.

1. How did you get started in the Agile world?

Interesting enough, I actually started my Agile journey in Greece. At the end of 2009 I got the chance to be part of kicking-off the Agile transformation in a big development organization of around 2000 people. So I got to spend 3 months in Patras, together with other 18 apprentice coaches from all over the world and 9 consultants among the most knowledgeable Agile coaches and trainers at that time. Every single day of those 3 months was an incredible learning experience and that still remains the most exciting and fun period in my professional career. Which better place to start a life-changing journey than the place which gave birth to the Western culture?

2. What does success mean for you in this world? 

In my opinion success in this context for a company or an organization means: effectively leveraging on Agile values and principles to achieve your specific goal sustainably in the fast changing world we are called to live right now.

For a development team success means delighting your customer with products that actually solve their problems. For me personally success means contributing to transforming our world of work in something more meaningful for human beings.

3. What are the top skills that an effective Agile coach should have?

The two coaching skills which helped me most in my 7-year experience as Agile coach are: empathy and situational awareness. Empathy is a crucial skill for coaches and leaders.

I learned that people want to feel themselves valued and appreciate when someone is truly listening and not judgmental. This doesn´t come easy: it is a skill to practice to be able to listen for potential, namely listening to people not for what they are, but for what they can become in the future and be committed to help them become the best they can be.

With situational awareness I mean the ability to be really present, observe carefully and understand what is going on around you: the ability of “reading the room” or “smelling the room” beyond what is said.

4. How Agile (and Scrum) has changed the way that the developers think and work?

Agile and Scrum are incredibly effective change engines: they trigger a paradigm shift in everything. Not only in how we develop products and services, but in how we lead, in the way we collaborate with each other, in the way we interact with customers, in how we consider ourselves as professionals. Embracing agility means embracing continuous change, which in turn simply means embracing reality. Someone said: life is what happens while we are making other plans. Believing that things will stay still just to please our plans is the ultimately insane wishful thinking.

5. Scrum is simple but not easy.  How difficult is to make a company Agile?

Being simple is definitely one of the strengths of Scrum but also one if its pitfalls: it is so simple that many managers fall into the trap of believing it can become a magic wand for the company´s problems. A famous quote from Ken Schwaber, co-inventor of Scrum, is: “Agile development will not solve any of your problems. It will just make them so painfully visible that ignoring them is harder”.

And that´s where the tough part starts! Scrum is not plug-and-play! It´s not just a SW methodology upgrade. It changes some of the basic assumptions about how products get developed! It´s like installing an iOS 9 app on an iOS 4: it won´t work! You need to upgrade the Operating System! Only courageous leaders, who are willing to make an impact, dare to start the journey to upgrade their company´s operating system.

6. What should companies do to achieve a successful transformation in the Agile world?

The first step is about asking “Why?” What is the problem we are trying to solve? There must be a clear need for any improvement change: imagine how crucial it is to start off such a dramatic change. So any successful Agile transformation implies a top-down approach, in terms of Company values, leadership culture, business goals and management support. However, there are aspects that need to emerge bottom-up, like practices to be selected by self-organized teams. It has to be a sandwich strategy! Given the importance of the top-down part in the enterprise change, one of the initial steps is to educate managers, for them to understand the why, be able to share and communicate the vision, embrace Agile values and be ready to support people with a new leadership style. Many times this critical step is down prioritized, if not even neglected.

Finally it is extremely important that teams are organized so that they can deliver value to customer as fast as possible, replacing functional teams organized around the system architecture. Effective teams are cross-functional and have all the competences needed to transform a backlog item in a product increment within one Sprint.

7. What words of advice would you give to people who are just getting started with Agile themselves?  

Every context is different: so simply copying from others will not work. Scrum is a good way to start, it is a great teacher: if you have never tried Agile development, Scrum can give you the framework to be able to start. At the same time, you need to know many things outside Scrum to make Scrum work effectively: having an experienced Agile coach to guide you through the first challenges can be a key differentiator between success and failure.

8. What are the biggest challenges that they have to confront, what are the biggest mistakes that they should avoid?

I have seen few recurrent failure patterns: Product Owners without authority, knowledge or time, superficial knowledge and lack of coaching on Agile practices and principles, complacency as opposite to a culture of continuous improvement. Well, avoiding these failure patterns is one of the biggest challenges to confront. One of the biggest mistakes is considering Agile as something to implement: Agile is rather something you are or can be. Agile is an adjective, not a noun.

9. What should people and teams do to make their workplaces and lives more productive with Agile and Lean?

There are few things that helped me become more productive and I have seen also helping individuals and teams I have coached:

• When you have a question to answer, spend time in understanding the question before jumping to the answer.
• Do not make assumptions: genuinely ask why. If you have to make assumptions, try to validate them as soon as possible.
• Challenge how things have always been done.
• Work on your strengths, more than your improvement areas.
• If you wish to succeed at anything, have a clear vision of what you want to achieve and consistently take baby steps in the right direction.

10. Where do you see things going to Agile in the future? What changes are coming?

I see contrasting things. From one side I see more and more “Agile” instances which have nothing to do with agility, where people and especially managers have lost or probably never got the original meaning of Agile manifesto: where, for instance, individuals and interactions are in service of processes and tools rather than the opposite. This can be also considered a normal evolution. When an innovation reaches the hype, it starts getting late majority or even laggards in the game: they probably accept Agile just to look fashionable or to please their boss. On the bright side I see a convergence of researches, theories, methods and practices coming from really different domains (Entrepreneurship, Neuroscience, Psychology, Finance, Management, Non-profits, even Military and Government) which are collectively creating a very visible red thread. And this red thread is all about coping effectively with fast change by using an empirical approach, embracing individuals as whole human beings not as resources to exploit, being mindful, decentralizing power, and creating meaningful relationships. That´s really exciting and resonates a lot with agility. On a broader scale, our generation is experiencing a growth in our consciousness as human race (let’s take for instance social responsibility) and that´s going to create benefits not only to our industry but to the entire world. 

Psychology of continuous improvement

Abanico en el mar by Ollui Samall Zeld / CC BY 2.0

I am an engineer! We engineers love well-crafted solutions.

Most of us studied Operations Research: we are excited by finding the optimal solution to problems and we like to fix all at once and even design future-proof solutions.

Sounds great to feel so powerful, doesn´t it?

But why is it so difficult to solve problems when they involve human beings?

Why can’t we make things happen even when the solution and the benefits appear so obvious even without analysis?

For instance:

Why can’t people simply quit smoking?

Why don’t most of us parents manage to get their teen-ager son to clean up his room?

Or why don’t we simply manage to increase the test automation level in our team?

Don´t they look like much simpler problems than many technical issues we face every day?

When it comes to challenges involving people, the issue is that human beings are not as nice creatures or as beautiful systems as the ones addressable by mathematical sciences, such as mathematical modeling, statistical analysis, or mathematical optimization.

God could have done a much better engineering work! Too many bugs J

• We are the least rational creature on earth: we are driven by emotions and gut feelings at least as much as by rationality, but feelings take the lead many times
• When the rational parts takes the lead instead, we usually got stuck in analysis paralysis
• We are reluctant to change: we like our current way of doing things
• We are programmed to save as much energy as possible: changing our routines  requires effort
• We are blinded by cognitive biases: we interpret the reality not for what it is, but by comparing it with the maps we have been creating in our brain since we were born
• We are addicted to the now and not very much used to accept delayed gratifications

So how can we ever achieve anything with such a flawed baseline system?

Imagine when you have multiple individuals together forming a team or even a bigger constellation: an organization!

Still surprised that up to 70% of all change initiatives fails? Can we ever succeed?

The good news is that human beings have also great properties and very effective strengths to use as leverages.

People are able to go straight to the point if they feel that the goal is clear and within reach and can be moved by incredibly powerful intrinsic motivators if they perceive the goal as meaningful and desirable.

All successful football coaches, for instance, know the trick very well.

How many times have you heard a journalist asking about possibilities of a team to win the championship?

And what was the answer from the coach every time?  “We want to play one match at a time”.

Good coaches do not ask their team to focus on the ultimate goal, but establish goals which are within immediate reach and clear criteria for their players to know when they have fulfilled those goals: by playing and possibly winning one match at a time, they get into the habit of winning and eventually win the championship.

Cheap and Dan Heath report in their book “Switch” that psychologist Karl Weick, in a paper called "Small Wins: Redefining the Scale of Social Problems," said: A small win reduces importance ('this is no big deal') , reduces demands ('that's all that needs to be done'), and raises perceived skill levels ('I can do at least that')." All three of these factors will tend to make change easier and more self-sustaining.

That´s why the Lean concept of Continuous Improvement (or Kaizen) is so effective and resonates so much with the way we as humans are wired: consistently taking baby steps in the right directions makes big goals appear more feasible to achieve.

However, being social systems classified as Complex Adaptive Systems, usually it´s not a smooth path of small wins.  More probably it will be about taking one step forward and two steps back, then three more steps forward and then five steps to the side. 

Nevertheless, by taking the vision of what we ultimately want to achieve well defined and in sight and, by coupling Hansei with Kaizen, meaning practicing Continuous Reflection at every step, we are much more well equipped  to achieve anything.

Instead, when a task is too big, the effect on human brain is overwhelmingly scary.

The book “Switch” reports also that Alcoholics Anonymous challenges recovering alcoholics to get through "one day at a time". To an alcoholic, going a lifetime without another drink sounds impossible, but going 24 hours sounds doable.

Small targets lead to small victories, and small victories can trigger a positive spiral of behavior.

Human brain has no trouble achieving baby steps, and as it does, something else happens. 

With each step, you feel less scared and less reluctant, because things are working. 

With each step, your brain starts feeling the change. 

A journey that probably started with anxiety and skepticism evolves slowly, toward a feeling of confidence and pride. 

And at the same time the change is happening, you as a person grow.

The Mango Tree

I found out that I like the “gardening” metaphor a lot (see also my latest article).

Last Friday I met a colleague during a coffee break.

We were sharing some views about what had happened during the week, when he said: ”You know, this transformation we are all undergoing is like a mango tree. Everybody seems to want mangos, but no one seems to care about how juicy they are and to know how to get juicy mangos”.

Nice way to put it: don’t you think so?

Then we started building upon this metaphor and having fun taking it to the extremes.

And I think that, what we got out of it at the end, was really good way to explain what does it take to get a team or an organization become Agile or more generally to make a change successfully happen.

So what will a good gardener do in order to get the juicy fruits she wants to harvest in her garden?

1.    Decide what fruits or vegetables you would like to collect

The first step is definitely to define what kind of garden you would like to build and what fruits or vegetables you expect to get. Then you can go and buy the corresponding seeds to plant: of course you need to plant mango trees if you want to get mangos. On the other hand you will never get mangos out of onion seeds (for instance have look at this article from Lyssa Adkins to check out what to seed to get a high performing team)

2.    Work a good piece of land

Quality of seeds is essential to get juicy fruits, but so is quality of land. So make sure to have the right environment for the plant to grow strong. Plants growing nearby can also affect the taste of fruits and vegetables: for instance if you grow lettuce close to artichokes, it will probably get bitter. A good gardener knows that, same as she knows how air pollution can also be very detrimental.

3.    Start growing small plants

So how do you think you can verify whether you bought the right seeds and you worked the land properly? Will talking about how the plant should look like help? Most probably not.

Instead a good gardener would start planting some seeds and grow some small plants. She would water the plant; she would ensure it gets enough sun (but not too much); she would fertilize it and protect it, so that it grows strong and can produce the first fruits.

4.   Taste the fruits and decide what to do

Finally she will happily pick the first fruits and taste them to check if they are sweet and juicy enough. Sometimes you will not even need to wait until the fruits are mature. It won’t be hard to see quite early if you’re getting the right fruits in the first place: you will pretty easily tell a mango and a pineapple apart. If you’re getting the right fruits with the expected quality, you can keep growing the same tree and maybe plant more of the same. Otherwise you can even remove the plant or adjust your gardening, trying a different type of fertilizer or dose the water differently. Until you get the wonderful garden you were looking for.

Does this remind you anything? Right, it looks like the Plan-Do-Check-Act cycle from W.E. Deming.

BTW, gardening follows just an empirical approach, the same as Lean and Agile. 

Both gardeners and agilists don’t spend time talking about how things should be done in the best way, but they start doing things, just enough just in time, and most important they learn by actually doing, one experiment at a time.

So, what about your Agile transformation?

Are you actually planting seeds and tasting the first fruits?
Or are you just talking about how a good mango tree should look like, maybe even without having ever seen one?

Change is optional: survival is not mandatory

As many of you can have guessed, the title I chose for this post is inspired by a quote from W.E. Deming.

When I got to know Deming for the first time, many of his lessons came as a revelation to me: they were kind of resonating with my personal thoughts and reflections, but still they cleared out many clouds.

One of those I prefer is: 

“…most troubles and most possibilities for improvement add up to proportions something like this: 94% belong to the system, 6% are attributable to special causes.” 

I think that this simple sentence can trigger several reflections about how to make things happen and especially how changes can have a chance to happen and possibly stick.

Below are mine, from my personal survival handbook J.

1. Look at the system

An organization, even a single team, is a complex network of people, who are complex beings. If you really want to leverage on all potentials to affect it, you must look at it as a whole system. 

Try to sketch the possible options you have ahead, possible impediments and way to overcome them to reach your goal: you might realize that you need to take many steps, in order to get any progress. 

Prefer actions who affect the environment around or the process to do things, instead of addressing directly a specific problem: they will have a more lasting impact. And, whatever level you want to affect, consider acting also one level up.

“It does not happen all at once. There is no instant pudding.”-W.E. Deming

2. Involve people

Try to understand your team or organization very well. Learn about the invisible networks, the inner relationships among people, who is friend of whom, who is most sensitive to certain subjects and who counts more or is more influential on certain subjects, whether he has a formal power or only a de-facto leadership. Talk to people, with a preference for informal chats (coffee machines are a perfect place sometimes).

“A desk is a dangerous place from which to view the world” – J. Le Carré

Create an alliance: find initiators to support you and involve them in creating a shared strategy for the change. 

Chase innovators eager to try new things out first and learn from people actually doing the work. 

Find also sponsors to support you in difficult situations and leaders who can help with crossing the chasm and reach out the majority.

“The greatest waste … is failure to use the abilities of people…to learn about their frustrations and about the contributions that they are eager to make”- W.E. Deming

Strive for ways how to collect as much feedback as possible, especially from skeptics, but do not spend time in convincing cynics and possible saboteurs.

3. Communicate properly

You cannot just plan your change at your PC, create a slide ware and then ask to deploy it to the whole organization.

How many times have you tried to do that way? How many times did it work?

“Insanity: doing the same thing over and over again and expecting different results.”- A. Einstein

Instead explain the “why” for the change; make people aware of what it might mean and relate the change to their daily problems.

Have people desire the change (what’s in it for me?), support them with the change, provide the necessary knowledge and give them time to learn. 

Offer role models, lead yourself by example and help people with mentoring and coaching on how to change.

“If you want to build a ship, don't drum up people to collect wood and don't assign them tasks and work, but rather teach them to long for the endless immensity of the sea.” – A. de Saint-Exupery

4. Reward behaviors not outcomes

When you make a change or learn something new, usually your performances at the stuff affected by the change are getting a bit worse, especially at the beginning. So give room for experiments and possible failures, so that people are not afraid to try new things.

Celebrate short-term wins and success stories; make them visible and share the results with information radiators. 

Publicly reward those who are learning more or sharing more with others, so that the change can go viral. Express appreciation for the right behaviors so that the desire for change is continuously reinforced.

“The most important figures that one needs for management are unknown or unknowable” – W.E. Deming

5. Use an empirical step-wise approach

Before taking any step, try to guess which effect it will have in relation to your goal.

Make a hypothesis and try to validate it as quick as possible with minimum viable actions and fast feedback.

However changes in a complex environment are never a linear process you can plan upfront, set goals and KPIs, deploy it to the organization and track the progress. That’s why sometimes you must simply try things out. That is sometimes absolutely not bad, stated that you try to fail fast and reflect on what you learned to find a different path.

Of course using an empirical process control implies that you can observe your system to be able to inspect and adapt. Therefore enable full transparency; make relevant information visible as much as possible from everybody to everybody to be able to really understand what’s going on and act accordingly. Otherwise your change will degenerate into chaos.

“It is not enough to do your best; you must know what to do, and then do your best.” – W.E. Deming

How much time and effort are you spending really nurturing your system?

How much are you learning from people actually doing the work?

Are you really making changes happen or just increasing the entropy of your system into chaos?

And if don’t mind about change and how to make changes effectively, skip the whole article and just consider that: 

“It is not necessary to change. Survival is not mandatory.” – W.E. Deming

12 secrets of a successful Agile transformation – Part2

Following the blog post from last week, here is the continuation of the list of 12 tips for a successful transformation towards enterprise agility. We mentioned already the first 3:

1. Why?
2. The approach
3. Training managers 

Let’s move on with 5 more:

4. The pilot project

Since we’re talking about applying an empirical process, the starting point is to setup an experiment in terms of a pilot project. Scrum can help out with its framework to give some guidance and some practices which help understand the agile principles behind. A pilot project can provide objective information on the feasibility of rolling out Agile to all the organization. Craig Larman says that if an organization is not able to implement real Scrum with only one team, how can they succeed in scaling it in the whole enterprise? But be aware of choosing a proper pilot project. It needs to be important and critical enough so that people will consider it a serious try and a valuable success (it should be used to gain even more management support for the change), but not too critical to create a safe environment for possible failure. It should be end-to-end and therefore include all the stages that are needed to bring an idea into a product and it needs to be closely monitored and supported by senior management, ready to fix possible impediments.

5. Scaling up

Leveraging on the feedback from your pilot project and acting on the findings, you can start scaling up incrementally. This will allow better control and will enable the organization to build internal capabilities to help the teams that start later.

If you don’t know what you’re doing, don’t do it on a large scale – Tom Gilb

However beware not to be too slow, to avoid the organization finding them in the ford for too long and losing momentum, sense of urgency and a clear direction about the change to make.

6. The Transition Team

Creating a successful Agile organization does not simply mean make a number of Scrum teams work: it means creating all the conditions around to enable those teams to succeed and get astonishing results. The Transition Team is an operative team, with the goal of helping and supporting the organization in implementing the Agile Transformation, by supporting teams, removing organizational impediments, training and coaching people, spreading the Agile values and Lean thinking. The team works as an agile team, driven by the so-called Transition Backlog populated top-down by the organizational transformation strategy and bottom-up by impediments from the team.

7. Create the new roles

In order to scale up you need to build new skills and behaviors for people to fill the new roles of Scrum Master, Product Owner and Scrum Developer. This is best done by means of a mix of training, mentoring and coaching and is a typical item in the Transition backlog. Understanding that we’re talking about new roles, you cannot find in the existing organization, is a critical success factor. One of the worst (and yet easy and most common mistakes) is to create a mapping between existing and new roles, like System ArchitectàProduct Owner or Project ManageràScrum Master. They are totally different jobs and you need to realize this and prepare to help individuals who are willing to learn and challenge themselves to fill the gaps needed to move to the new roles.

8. Cross-functional teams

Cross-functional teams who can deliver potentially shippable product increments at each iteration are a key element in a successful Agile enterprise. So one needed step is to change your organization, remove functional silos and have self-organized teams of 5-9 people with all needed competences working together permanently. And this might imply changes in the office logistics as well, to create the right environment to enable team collaboration.

The most efficient and effective method of conveying information to and within a development  team is face-to-face conversation – 6^th Agile principle

It’s probably enough for today: any comment?

Let’s have a date for the next blog post to talk about the remaining secrets for a successful Agile transformation. 

12 secrets of a successful Agile transformation – Part1

Last week I was discussing with my brother, who works as chemical engineer and is now preparing to pass his exam for a Lean Six Sigma Green Belt Certification.

He’s studying mainly about Lean production and I was explaining him how Agile has its roots in the Lean principles and disciplines and how essential is Lean thinking and Lean management approach to support an Agile SW development.

My brother is a clever guy: so he understood very well that embracing Lean means much more than the mere application of a number of practices. So is for Agile SW development.

He’s maybe a little too clever to ask me something like: “You say that you’re an experienced Agile and Lean coach: so what do you think it is needed for an organization to really leverage on Agile and Lean to deliver quality products in an effective way? What do you think are the key ingredients to have a successful enterprise transformation?”

Cheeky enough, isn’t it?

But somehow he forced me to step back, reflect, gather my thoughts and summarize my experience and learning from the last 3 years.

Here comes then a list of 12 tips as outcome of that exercise, which I intend to share with you in a series of posts. I will start with the first three today:

1. Why?

Before exploring how to implement an enterprise transformation to an Agile organization, the first step is about asking yourself “Why?” What is the need behind? What is the goal you intend to achieve? There must be a clear need for any improvement change: imagine how crucial it is to start off such a dramatic change. The “Why?” must be clearly understood and the vision for the change communicated and shared to align the whole organization. Otherwise you’re doomed to fail even before starting (more about Why Agile? here)

2. The approach

Due to what we said above, it is easy to understand that any successful Agile transformation implies a top-down approach, in terms of Company values, Management culture, Vision, Business goals and above all senior management support: you cannot do anything otherwise. However, changing an organization (irrespective whether big or small) into being Agile is not like the nth Change Program to be deployed with targets to comply with and a well-defined plan to stick to. There are aspects that need to emerge bottom-up, like practices to be selected by empowered and self-organized teams. So an Agile transformation is a sandwich transformation: you need 2 equally big slices of bread and both are essential.

3. Training managers

Given the importance of the top-down part in the enterprise change, the very first step is training managers, for them to understand the why, be able to share and communicate the Vision, embrace Agile values and be ready to support people with a new leadership style. Many times this critical step is down prioritize, if not even neglected. It is too easy to fall into temptation that becoming an Agile organization means making Scrum teams work and that managers, well, they are clever enough that can handle themselves or can get it with a short summary from a developer attending a Scrum course: being a manager in an Agile organization is a totally different job and requires new tools which must be learnt and cannot be improvised.

How do you see yourself and your story compared to these three items?

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.

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.

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.

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.