Why Training is not Enough

By: Brian Bozzuto
2/27/10 9:49 pm UTC
Topic: Agile Adoption | Agile Coaching | agile transformation
Like many other Agile practitioners, I have seen too many cases where an organization wants to adopt Agile, but believes that all they need is a little training. Of course, the most extreme would be when a group believes they can send one person off to become a Certified ScrumMaster and then they can simply train everyone else. While this intuitively sounds foolish, and many people could begin to articulate the shortcomings of this mental model, I’ve struggled to present a clear and succinct view of what exactly why this model doesn’t work. Although I recently came across a very good model that captures what I tacitly knew already. I hope this is valuable to the rest of you out there trying to make the case for coaching.

Thomas Crane, in his book “The Heart of Coaching” identified a model from an article in the November 1979 issue of the “Training and Development Journal”. Sadly, I could not find the original article, but I’ve adapted the diagram to communicate the model. If we think about change on two levels, we see that there are changes in behavior and ultimately changes in results. These two dimensions remain roughly proportional in a static system, as your behaviors impact your results. Things get really interesting once you try to change behaviors. We frequently see this done by sending people or a team to training. Indeed, the “Certified ScrumMaster” classes, are often this point of entry. Now we see that behavior changes, but once someone goes to apply this new behavior, the results are actually worse than when they were using the old behaviors. Many people are familiar with the idea of the “j-curve”, as we use a new practice for the first time, we’re actually quite clumsy and our outcomes are not as good as if we were using an old technique. For those of you who ski, when you first learn to parallel ski, it’s actually much harder to get down the mountain. In fact, when you ski an expert trail, you probably find yourself reverting back to the snow plow. It may be a less refined technique, but you’re effective with it. This is exactly what we see when people first learn and apply Agile practices.

What we observe is that while one’s behavior change at first, they are immediately put back in their prior environment and begin to revert. Perhaps not everyone went to training or the boss doesn’t really care about Agile. As Weinberg observed, the cucumber eventually gets pickled. What’s really interesting as that at the same time, our poor change champion is not performing at a lower level as they try to use new practices. Thus, the “new” stuff actually feels worse than the “old” stuff they were trying to fix. We know some of this is a learning curve, but the observed behavior is that as one reverts back to the prior standard, results are actually getting better. Thus, one can settle at a level with slightly better behaviors and slightly better results, feeling like this is the proper place to be. David Douglas and Robin Dymand talk about a situation they call “we suck less” and I think this nicely summarizes how people can fall into that trap.


Training with Coaching

So how do we help people maintain, or even improve, their behaviors after a training class? Well it must be reinforced, and this is where coaching comes in. Having committed time and energy to learning a new way of doing things, people need ongoing support as they begin to apply them. No matter how good your training class, it will never be a substitute for the messy reality of the world in which we must all operate. Also, we need to remember that there are very real pressures that have driven us to our prior behaviors. We need to begin to apply counter pressures so that we don’t revert back to old habits. This second diagram shows the two dimensions, but now the team receives coaching after they complete training. The coaching helps reinforce practices so that they don’t abandon their behaviors as they move through the adoption curve. As results get demonstrably better, this can create a virtuous cycle where coaching can eventually ramp down and the team becomes self-sufficient, continuing to improve it’s own performance without any external support.

Like many things, this probably introduces more questions than it answers. How long is the right amount of time for coaching? What if the coach is hands on, or the team is supplemented with other experts to get through the adoption j-curve? Are there other ways to change the environment such that teams feel positive pressure to maintain behavior besides through a coach? These all probably merit further discussion, but let me leave it here for now. So I am curious, what are you experiences with rolling out Agile, or any type of change, initiatives? Is this model consistent with your experience?

The Great Atheist and the Sprint Spirit

Click Here!

The first time I met Sam, who interviewed me in order to implement Scrum in his 200-developers company, he began with the declaration: "I know, scrum is all about iterations, we are already working in short iterations, maybe too short iterations, of one week"! First of all I answered him that Scrum is NOT all about short iterations, but about teams. One month later I audited the company. The results did not describe a regular company working in iterations; definitely not. But each single person I talked with began with the fact that they were working in short iterations, and in fact that each one in the company suffered from these short iterations. One month later I began to escort this company.  Very quickly, the situation there, concerning iterations remembered me the tale of "The Great Atheist" I was told years ago by R. Leon Askenazi (also known as Manitou).

During the era of the enlightenment movement in central Europe during 19^th century second half; a young student wanted to go to learn directly from the guru, The Great Atheist. He was told that we will be able to find him in Spadovska, a needle-head point village on the map. Resolute to meet him, our young student travelled to Spadovska. Going down of the diligence, he asked a local habitant where he could find The Great Atheist. The autochthon answered that obviously he can be found in the synagogue. The student asked the native if he was sure, after all he was speaking about the Great Atheist, and a synagogue is certainly not a proper place for such a genius; but he was answered with such an absolute conviction that actually he WILL find him in the synagogue, this little building at the end of the grand-rue. Much astonished, our student enters the synagogue, and sees only an old bearded man plied on a pile of old books learning with assiduity the holly texts. He asks him "tell me old man, where can I find the Great Atheist?"; "and why are you looking for him young man?" asks the old man; "I came from very far to learn directly from his lightened mouth" say the young student. "If so, please hear that I AM the Great Atheist! ". Much astonished, our student "you are the Great Atheist. Unbelievable! I imagined you a bit different. Will you teach me?" "Why shall I teach you?" asked the Great Atheist. " "Because I'm your most fervent pupil. I'm totally atheist!" " Wait", continued the Great Atheist, "do you know kabala? Do you know Talmud "Of course not, I'm atheist"! ?" "do you know your bible? Commentaries?" "Of course not, didn't I told you, I am a fierce atheist!"

"YOU FOOL, YOU ARE NOT AN ATHEIST!" ,said the Great Atheist, "YOU ARE IGNORANT!"

This is the anecdote I came back to Sam with a week later. "YOU ARE NOT HAVING SHORT ITERATIONS" I told him, "YOU ARE HAVING SHORT WEEKLY RELEASES! And this is killing you slowly but surely".

There is a critical difference between a sprint and a release, which is the main reason why, each time I begin to work with a new company I enforce distinction between sprints and releases. A sprint is mainly a window of time; within it a team completes working deliverable software. This time window balances between the overhead of iteration (planning, retrospective and review) and the value of frequent feedback which allows us to inspect and adapt. Generally speaking sprint will be minimal, and according to Scrum guidelines, will move between two to four weeks. Producing deliverable doesn't say that you will actually deliver. A release, in opposition, uses a tool called "iterations" or "sprints" in order to progress toward large bunch of features to go live. Because of the "to go live" issue, the overhead of such a release is much bigger than the overhead of a sprint. You have to run integration tests, regression tests, follow release procedures, documentation, operations issues, etc… Weekly releases means, as far as my experience shows it, lowered quality level and increased bug issues, causing frequent costly hotfixes and patching, and avoiding the teams to work properly on their development tasks. Short releases increase the pressure on the teams, they feel always either after a release or before a release, but never in full development stage. This causes teams to work late in the night and during week-ends, they feel squeezed, exhausted. The teams feel like the management don't let them do proper designed and coded work, and only pushes them to "go live". Team motivation can decrease severely. Usually in short releases, teams has no much play room in their capacity, development is prolonged until one day before the release in the good case, and mostly bugs will still be fixed the morning and the release "go live" by the evening.   Team attention decreases, they know that there is no way to release properly, they don’t unitest properly, quality sinks, and the next releases counts many bugs to be immediately fix in addition to the new features the teams have to release. The situation can only become worst and worst; this is what I design as the "Quality Spiral" (which I'll speak about in a further article).

This state of fact is avoided when working on longer releases, leaving time for integration sprints, proper QA testing and V&V, and full synchronization with external function groups (like support, operation, IT…).

While working on longer releases, of at least one month, we will still run on short weekly or bi-weekly sprints, leaving room for teams to complete their work and QA to ensure good quality. This is the answer to those pretending that long release means loss on control over the development process. This is right if you still confuse release and sprint. But long release ensure quality , and the short sprints the release is made of, ensures high visibility and best management of the development.

On the other hand, long releases means increased amount of new features to be delivered, thus means more communication channels to be managed between more groups in the company. This synchronization issue may become a critical bottleneck. Just think about several teams not necessarily running synchronized sprints. This asynchronic system has to be properly managed. I'll propose a solution in a further article.

 

Scrum Turtles - What turtles and market trading have to do with Scrum

Every Scrum practitioner (certified or not) knows that while Scrum principles are easy to learn and to understand, they are often tricky to manage. The ScrumMaster finds himself at the nexus of the development effort. All around him revolves almost every single function in the organization (with the possible exception of the janitor). The ScrumMaster has to control and manage the fears and concerns of the customer, the Product Owner, the QA manager, his own boss, the VP of marketing & sales, and, last but not the least, his teams. In essence, he is the lamentation wall for a global village. This stress is always present—I know; I have experienced it over and over again. To succeed in this environment, the ScrumMaster needs powerful tools that can help him regain control and manage the constant stress.

Luckily, coaching provides us with just such a toolbox. The ten tools in the coaching toolbox (this may sound familiar) are easy to learn and to understand, but are often tricky to apply. None are a silver bullet. I'll describe each of the ten tools in detail in future articles, and will also show how you can leverage them to manage delicate situations. In this article, however, I'll present a much more general approach for being a successful ScrumMaster. This approach is one that we all know—one that is pure common sense and that we apply to our coding but not necessarily to our project/team management.

Back in the early 1980s, a seventeen-year-old boy named Richard Dennis stepped onto the floor of the Chicago Mercantile Exchange, the biggest commodities trading floor in the world. A few years later, this same young boy was one of the most famous traders of this exchange and became known as "the prince of the pit." Dennis believed that successful trading was an activity that could be learned, rather than an innate ability. “We're going to raise traders just like they raise turtles in Singapore,” Dennis said. Few believed he could do it. To prove them wrong, he published an advertisement searching for traders to be trained. Though thousands answered, Dennis hired only twenty three of them. He dubbed them his turtles. What began as a bet, turned out to be one of the most amazing experiences in Wall Street.  Dennis gave his turtles two weeks of training. Four years later, each of the turtles had produced 30 million dollars and had averaged an 80 percent profit. Some had as much as 100 million dollars in profits to show for their four years of trading. All this after only two weeks of training! What turtle-raising techniques had Dennis employed to produce such amazing results?

Sit down with me a while. We’ll have a drink and ponder the way of the turtle.

Dennis relied on five principles to raise his trading turtles:

1. Keep it simple. Dennis built some simple rules that his turtles would have to follow. (Sound familiar?)
2. Too much data is a lethal weapon. Dennis minimized the amount of data the turtles would have to process.
3. Have a clear plan. Define your goals clearly and determine what steps will get you there. Anything that doesn’t take you there is negligible. Yes. Anything, no matter what the losses, that doesn’t take you toward a goal is in the way. (This is the crux of “result thinking,” for those of you who are of the coaching persuasion.)
4. Manage the risks properly. Without proper risk management (or money management in Dennis’ case), you are the walking dead.
5. Never try to foresee the future. You must have a general idea of where you are heading, be able to react to the reality of the market, and have the discipline to react only to what you actually see.

Whew! You now have all five principles. Let’s take a quick break. Take your time and reread the way of the turtle. You can have another drink if you need one; I’ll take a diet cola. When you’re ready to go on, keep reading.

Whether you are introducing Scrum in your company or you are a seasoned ScrumMaster, these guidelines apply to you. To manage stress, follow the way of the turtle. You need to teach each function of the company, including the customer, to work in a Scrum-ish way; but to achieve your goals, you will have to raise your turtle. Let’s turn those turtle-raising principles into Scrum-specific guidelines.

Keep it simple. The rules have to be minimalist and simple. Remember: people like simple rules, or thumb rules. Not only are they easier to follow, but it is also easier to detect any infraction. When you have only a few rules, you can rationalize your insistence that they be followed to the letter. The only intent of these rules is to allow you to do your job properly by enforcing effective, creative, and committed work from all functions of the company. These rules are also very important within the team. The team must have a limited bunch of rules on how to code, how to document, and how to test. These rules must facilitate the developers’ work, rather than hinder it. A good rule set allows developers to think less about how and more about what. In other words, good rules should free developers to concentrate on code development.

Too much data is a lethal weapon. Make use of a dashboard to give a global vision of the entire process in the more concise manner. Restrict yourself to the minimum documentation and data when you present to customers or executive managers. Believe me, they will thank you for it. Making conscious choices about simplifying data not only builds transparency, it also builds focus. Give the team a global picture verbally, and transmit focused and concise written material to support that picture. Think about it: each piece of written data has to be controlled and updated. Why waste the time? Standards like FDA or AAA require a minimal amount of written documents. You may be surprised by how concise these documents can be while still conforming to these standards.

Have a clear plan. It seems evident but, in fact, not every function sees the plan clearly. This is partly because the goals of each function are not necessarily the same. The first tool of coaching is result thinking. It looks much easier than it is in the real life. While I’ll cover this I more detail in a future article, for the moment, let’s just say that a clear plan helps to coordinate the entire effort of the organization. It helps to manage difficult situations and conflict by focusing on the common goal. It helps to determine which action items to undertake: those that are bringing the company closer to the stated goal. The plan gives a common frame for everyone to work within. It helps to manage difficult times by reassuring everyone that any losses incurred are only lost to realize some other action that fits the overall plan, so that by the end we will be much more profitable.

Manage the risks properly. Don't put your head in the sand. It doesn't help. In the same manner that Scrum embraces change, Scrum also embraces risks. Identifying them clearly can help to either prevent them or take corrective actions in time. How much effort are you assigning to risk analysis and risk management? If you are like most, not enough. This action starts at the top. Executive managers have to be involved and committed. They have to identify their risks in front of each function in the organization; usually, they need a coach to achieve this. And then from there the risks have to trickle down until they reach the developers, who have to know their own risks. Each single function has to identify and manage on-the-fly the risks in front of each function. This is really hard the first time you do it, and in general you need the help of a coach, but as you learn to do it, it becomes more and more natural. Knowing all the risks makes you more proactive. You can see more clearly the situation you are heading towards, and are able to take corrective action according to the plan. In the end, you make fewer mistakes.

Never try to foresee the future. This is what Scrum is all about. You can never know exactly what will happen, and you cannot possibly be ready with solutions up your sleeve for every impediment that might occur. Do you have a plan? Good. Do you know where you are heading? Double-good. Don’t even try to prepare responses to the “pacmans” that lurk around the corner. You will have enough work on your plate when they do happen. Do, however, be observant and aware of what is happening around you. And as you identify a change, embrace it or kill it; it's up to you. Just like the trading turtles, you can follow a plan, but you cannot go against the market.

And I’ll add a sixth guideline—one to see you through. The sixth principle is to have faith in your skills, belief in your capabilities, and trust in your way.

Be Scrum smart!

You can find an interview of Curtis Faith, one of the original turtle traders at Curtis Faith on YouTube.