Building an agile organic learning machine

Why is so important for your company to actually let the agile worth spread around it?

It happens that when a company decides to embrace agile, it thinks to help its teams during the transition from a previous software developing model (waterfall or in general any phase or gates development model), to an agile one. These companies often hire a coach in charge to accompain the teams throught this transformation, by delivering training and assisting and facilitating their way of working using the new paradigma.

After a first period, the honey moon period, the teams start to struggle because of difficulties of changing their working behaviors, because of many impediments often coming from external interferences or interconnections with some other external teams (agile or not).

This is the moment in which the coach and the company, start to think about scaling agile in the enterprise, introducing what Schwaber and Sutherland called ‘Scrum of Scrums’ or Shalloway revisited and named ‘PCT – Product Coordination Team’.

No matter what the name and method you and the company choose to adopt, start soon to scale agile, otherwise synch problems become so important and tough, that agile is no more the fantastic new model to adopt for developing software.

What I’ve seen and experienced, is that scaling agile is not enough. There’s at least one another step to nurture the change process that such a company needs to totaly and completely understand and embrace agile.

What is missing, at all, in a scenario like that, is an organic mechanism of knowledge sharing and learning.

Let me explain.

As you probably know, a superb way to share knowledge within a team, is to pair.

XP prescribes (yes, it is prescribed like what the doctor does with medicine) the practice of pair programming, in order to cure these main symptoms:

1. general knowledge leverage for junior, pairing them with senior guys
2. in case of particularly complex or important piece of code to develop: here the reason is that two pair of eyes is better than one
3. in case of high specialization of one team member over a specific professional domain or part of code (do you knowthe bus factor?)
4. help the team members to know better each other

Hence pairing helps a lot within a team; but how it can be used to involve the entire company? It cannot.

We have, instead, some other techniques to spread agile within the company and these are called: communities of practices, open spaces, user groups and conferences.

Communities of practices

This kind of “human aggregation” is what a company, the one that has several teams adopting agile, should initiate in its reality. These groups share common interests. ScrumMasters or ProductOwners communities or, yet, organized by methodology: Scrum, lean, XP or Kanban communities. Within these free association of the employees, the company have a great opportunity to create occasions where the people share ideas, experiences and usually create new standards or best practices to apply.

Open Spaces

Visit this link to gather detailed information about this open spaces.

This kind of meetings can be used to share knowledge, to try to solve problems, to analyze risks or to share any experiences with other colleagues. Take a look here: the Agile Coach Camp 2012 un-conference, is completely arranged following the open space philosofy.

Here are my reflections about the past event in 2011 and, obviously, I’ll be there also this year (within a week……can’t wait).

 User Groups

Even if a company does not have the possibilty to create the knowledge sharing spaces above reported, it must try to invite the team members to join the agile user groups already existing in their city. It’s much more easy, if the company directly contacts the external groups asking for the meeting dates and arranging an evening with them.

Conferences

The last, but not the least, method is to let the guys attend to some conferences. This has the double positive effect to let them learn from professionals and create a team building effect. A moment in which the team members can confront each others.

Agile, as you know, is a matter of practicing, collaboration and confrontation. It’s paramount to create a process that helps to refresh and reinforce constantly the knowledge and the practices.

In my opinion, a company should not be afraid to spend some money to create these “spaces“: these are investments, to be looked as great opportunity to let the entire company grow and becoming an organic learning machine.

A SCRUM lesson delivered using….SCRUM

Last week I had the pleasure to teach Agile and SCRUM. The class was quite challenging because the attendees were all PMP certified, with a deep experience in managing ITC projects. The class was also quite heterogeneous because of the different types of projects they manage and because of the different expertises.

In a class like that, teaching agile could be tricky because the experience and the approach of the attendees is such that topics like Planning, estimating, risk management are paramount and you will be challenged for sure when explaining how agile embodies those topics.

This is the reason why in courses like that one, I make huge use of games, exercises and confrontation sessions (a little bit of coaching never hurts) in order to facilitate the learning process of the participants letting them to consolidate the knowledge just aquired.

Knowledge is only a rumor until it’s in the muscle (Papua New Guinea proverb)

One another trick I use when teaching SCRUM is to arrange the lesson using SCRUM itself.

First of all, I arrange a fantastic taskboard with three columns: Backlog, Running, Done.

The backlog column contains the topics I’m going to cover, as post-its. In every post-it I write the name of the topic and on the left or right corner I write also an estimation in story points.
This estimation is a blend of these factors: number of slides covering the topic, importance of the topic, difficulty of the topic and finally how much space I should left, to let the attendees to reason, talk, discuss, confront about that.

Then arrives the calculation of the total story points I muyst deliver in that session, summarizing the points of each topic.

Good, now it’s time to draw the burndown chart.

I decided that the duration of my hypotethical day is one hour.
The burndown chart is a standard one: on the Y axis I report the total story points just calculated; the X axis, however, is divided into the N days available (the number of hours available for that teaching session).

The preparation is finished, now it’s time to work, explaining the contents of the lesson.
Every time I start a new topic, the relative post-it is moved from the Backlog column to the Running column. On the other way round every time a topic is completed it goes from the Running to the Done column.

Every hour I check the status of the work delivered (topics covered), how much work is again in the backlog, the time remaining and I say to myself and to the class what we are going to do in next hour and if we are on track or not. Think of this as what a team does every morning conducting the SCRUM Daily Meeting.
Then, the burndown chart is updated with the story points left.

I found this approach very usefull.
Visualizing what topics are still in the backlog, helps you to remain focused and to decide to slow down or accelerate.
Visualizing the burndown chart reinforces what just said in the point above.

The class sees how many topic must still be covered (taskboard), it sees what this does mean in relation with the time available (burndown chart).
This actually, allow the class to automatically regulate the way the attendees ask for questions, the need of any break, the way how they discuss: they obviously want to cover all the topics, maximizing the value and reducing any waste of time.

I think, however, that the most important point here is to let the class see how SCRUM works.

This helps the attendees in the process of digesting the SCRUM knowledge, transforming it from a only rumor in their brain into an abilities they can train and use soon.

What I hear, I forget.
What I see, I remember.
What I do, I understand.
(Confucio)

Leaving the comfort zone

Learn, practice, verify and correct: a parallelism between sport and project management, letting us help by the PDCA cycle of Deming.

The week just passed was very intensive.
With two other experienced project managers we taught in two different sessions of basic Project Management for an international bank.
The courses structure was very intensive: high level of involvement of the participants, short breaks, many workshops and exercises and, last but not least, the official language was English (participants were from different European countries and only for some of them English was their mother tongue).

During those days a great number of topics, concepts, processes, methods, tools, approaches, rules were covered and the participants remained astonished and in some cases discouraged because of the huge number of things to learn.
One of my colleagues, to motivate them, remembered when they learned to drive a car and how hard was it, even if now they are able to drive, listen to music, talk to the phone, together.

Effectively the first time I tried to drive was a mess: the steering wheel, the throttle, the clutch, the breaks. My first tentatives were completely disasters.

It seems that it is so, because our brain hardly manages different things in one shot: actually only about 5 things and, sometimes, it is even worst because it depends about the complexity of each one.
And so, how it was possible to learn to drive?
Well, it is possible because our brain merges together different movements and actions (pushing the clutch and engaging the first gear or accelerating and releasing the clutch) into one single chunk of knowledge and after many tries and refinements, it send this “chunk” or program, to the unconscious mind. Cool, isn’t it??!?

The same happens for every thing we want to learn, we have to study it, understand it and practice it many times and….the magic happens!
My opinion is that it’s “only” a matter of willingness, faith, persistence and courage.

Learning is primarily a matter of overcoming the boundaries and the perimeters of the status quo, leaving our comfort zone: this is the reason why we must be courageous.
Secondarily, is a matter of persistence (patience) because once we have chosen to change, before any improvements will appear, some water will have to pass under the bridge.
This last statements drives us to the next pillar of the learning process: the faith. Yes we must believe that such a change will happen, even more in the most critical moments.

Let me give you another example. This one is related to the sport (I love it!).
Let’s assume you want to run you first half-marathon. Today, you are already a runner, but you never run much more that sixteen kilometers and your average time is 6 minutes per kilometer.
Your pace is a “sustainable” and slow one and you kept that pace since the very beginning of your runner career, you already tried to achieve better results by running in the way you know, but you never got them.

Probably the main reason is that you never tried to vary your training, experimenting something new. You reached your “comfort zone” (running sixteen kilometers at a sustainable pace) and your body established its status quo.
Now it’s time to shock the system putting into the pipeline some fresh air.
To activate the learning process (sport training is also a learning process) is necessary to push us out of the routine, out of our comfort zone, creating new challenges and accepting them.

Coming back to the sport example, to see real improvements is fundamental to increase the anaerobic threshold: the threshold beyond which our body start producing more lactic acid than what it is able to dispose of.
To do that, we must leave our “sustainable pace”, the “same old way” of doing things, the current status quo and  we need to practice more and more and to vary our training introducing some changes.
We should start, for example, paying attention to our posture, the movements we do when we are running: feet, legs, arms and so on.  This is the base, the starting point:  our running style is paramount. Unnecessary movements bring to inefficiency, a correct posture means effectiveness that help us to run faster and run longer.
But it is not only a matter of “theory” it is a matter of improving performance by pushing up the anaerobic thresholds doing, for example, flat and uphill repetitions, fartlek sessions, aerobic power reinforcement sessions.
Yes I know, this is very tiring, but I can assure that the results will arrive soon.

This kind of work, helps you to achieve your objective, raising your performance and establishing a brand new and better personal status quo.

Improving our project management skills is something similar.
First of all we need the basis, the theory: we must study, understanding the basic concepts, creating relations between them, comparing the different techniques and trying to imagine the impact on our working environment.
Then, is time to decide about which area first necessitate to be practiced and improved: estimating? Planning? Communication? Risks? It is a matter of prioritization (do you remember Pareto and the 80/20 rule? See a previous post).
Yet, we must choose which practices, methods or techniques (do you remember the different running sessions?) put in place.

Finally: start practicing!

Continue even if small improvements, drive towards great results (do you know the kaizen word?)