Too often people believe in magic. And, considering the amount and size of unreal expectations, the land of magic is called projects. It's when we realize that magic doesn't exist that we turn to terms like “over budget,” “behind schedule,” or “unsuitable methodology.” You know what they say; “a tool is just as good as the people using it.” Let talk about tools! Especially, let's talk about our approach when it comes to learning to use a new one.
Agile tools, techniques, practices, and methodologies have gained tremendous ground lately and are now considered as serious tools by some very serious companies. However, a big number of organisations discover it doesn't work for them, or in most cases pay a very high price to make it work. It is interesting when you think about it; with all the project management knowledge out there, implementing agile is one project that still challenges most of the adventurers.
When asked about the history of agile, most people mention the last few years, which is exactly when agility started to preoccupy people's minds. Some go as far as 2001 and quote the Agile Manifesto. Those who have been through an extensive training might even mention 1986. But the real origins of agile come as a shock to many, and not because it's old (since the 1950s), but because all this time should have given us more examples of successful implementations. And it doesn't! Or maybe we are not looking in the right place.
Most likely, we wouldn't even talk about agile today if it weren't for all those extremely fast changes that we have been seeing for years now. Think smartphones, cars, and movies, and that should give you the right picture. Things have changed, and traditional techniques used to manage projects seem not to work anymore. There are a few things that are worth mentioning to explain why. One would be the assumption that if we spend some time thinking about the future, it will cause the future to be predictable. Building plans will not cause the future to stop surprising us. It will only cause rigidity and a false sense of control. That's why the main focus should be on the planning, and not on the plans. Plans are just an indication as to how the future might look, and you should be prepared to change them because the future might look brighter then you planed for—and it would be a shame not to take advantage of that. Another very important aspect of becoming more agile would be the role people play in everyday projects. Too often we are reduced to merely process operators with no clue about the output or the value of our own work. We know we are working hard, and we have crystal clear information (reports!) about our performance, but we don't have the most basic understanding of the meaning of our work. What are the benefits we are creating? Are there any? Is there a greater good? These are some of the things agile tries to solve. In fact, these should be the things you should try to solve using agile because, by itself, agile doesn't solve anything.
Too often, we are not committed enough. And not to any particular methodology, but to a set of objectives that should drive the implementation of a methodology. Commitment plays a very important role because it implies also that to do something new (a new way of working), you have to give up on something old (an old way of working). Multiple stakeholders, conflicting interests, and ever-changing priorities will affect the commitment and will reposition the implementation of agile as just another initiative among many others. It takes a lot of commitment because it will be hard. And commitment is what gets you through the tough times.
It is also a matter of resources. You don't become agile by sending your project teams to a two-day seminar. The organisation will need to align a set of resources that usually include existing knowledge, managers, projects, and customers. The rule is simple here: big objectives, big resources. Reasonable objectives, reasonable resources! And, because you want to have an agile approach when implementing agile, reasonable objectives are always recommended. Otherwise, people will be upset or frustrated because after two sprints, they still won't be able to measure the velocity properly.
To summarize, the main prerequisites to be doing agile are a lot of commitment, a good degree of realism when setting the objectives, decent resources, and…time! Yes, time, because there is no other way to do this except by actually doing it. It is not about doing it right or wrong; it is about doing it and always improving the way you do it, which takes time.
The Need for Models
Like everything that is new and unknown, agile needs models, lessons, and experts. Not just so you make it work, but to merely induce the idea that it could work. Otherwise, like anything new that threatens the status quo, it could be regarded with reservation or even condescendence. Before even searching for success stories, success itself needs to be defined. There are numerous situations when one person's success is another person's failure. And, as sad it may be, it is because, in most cases, we are not equipped with the right tools to assess the success or the failure of an agile implementation initiative. Is it all right for people to think outside of the box and suggest ideas, or is it a risk of scope creep? Is freedom a motivator or an excuse not to respect the plan? Does this sound difficult? It is! This is because at different stages, success may have different definitions. That's why we easily label any situation a failure when the reality doesn't meet the expectations. But then, is it against expectations that we need to measure the results or against a well-thought plan? Today, most of the organisations that implement agile don't have a plan. They just do it and hope that it will miraculously boost productivity and creativity. When you don't have a reference, anything can be successful or a failure.
Looking back, it seems that those who had a plan on how to become more agile—and that also includes realistic expectations—managed to get some results. Those who did it without a plan usually complain about all the blockers and the barriers as an excuse why it didn't work for them. Wait a minute. Did I just say, “plan”? I thought this was supposed to be agile? No plans, no documentation, right? What if the very first project you try agile on would the precisely the project of becoming more agile? A real project with milestones, objectives, and resources. With a plan! Then, probably, when we look back and try to assess our success or failure, we would have something more relevant to measure against.
There are a lot of strategies designed to improve the chances of a transition to agile, and they are all good. In fact, it's never been about the strategy, but rather about the implementation of that strategy. One of the best-known models (“strategy” would be too pretentious) is a very old Japanese model that has the merit of focusing on incrementally mastering a technique or skill. This model, called ShuHaRi, is today one of the elements that, willingly or not, guides any deployment of an agile methodology.
What Is ShuHaRi?
The concept of ShuHaRi comes from the Japanese Noh theatre, and it is a model used to illustrate the path an apprentice needs to take from the moment he or she expresses the interest to learn about something until that person becomes a master. Although the concept originated from the world of theatre, it became famous in martial arts. In fact, many people still believe today that this is a martial arts technique. Because it accurately describes the evolution in skills and practice when implementing an agile methodology, it is one of the most used models to plan and execute the transition to a new way of working. Interestingly enough, the model is so famous in the agile world that some believe this is an agile technique borrowed by other fields, like martial arts.
The model doesn't claim it is original—many competency improvement models follow the same approach—but it has the advantage to be easy to understand and simple to use. It basically says that in any learning process, we go through a few stages. First, we are an apprentice. This is the Shu level. We don't know anything and everything seems hard and scary. It takes hard work, patience, and a good plan or teacher to follow. After a while, we start to understand more, and we are deliberately searching for more information, including varying the sources, interpretations, and approaches. We are detaching from our initial thinking and discover the world around us. This second level is known as Ha. After much study and exploration, we are reaching the third level, Ri. This is where the learning process turns to our own work and inner thinking. The learning here is based on reflection, meditation, and continuous improvement and discovery. Here, you are a master.
How does this model apply to agile? Well, first you read an article about agile and you think this is something your organisation could use. Hire a coach or trainer, go through all the trainings, learn the vocabulary, understand the new roles and processes, and you start to do it, confident that this will dramatically change the way you work. Pretty soon, you realise that some things are more difficult in real life then the theory from the classroom. Customers suddenly aren't available any time, managers keep asking for more reports, people want details about the work they're supposed to do, and the list can go on forever. What did they tell you in the training to do? Change! Change the way you work so it fits the new methodology. But that is hard! Very hard! Next to impossible! So what do you do? Change the methodology! It is much easier to change the methodology to fit your way of working then it is to change you to fit the methodology. You tailor the methodology, or you say you are using a hybrid. And hybrid sounds scientific enough to make you and others believe that this is a real methodology. This is the Shu level when, no matter how hard it is, you must respect the rules, processes, and indications as they are explained to you by your master (also known as agile coach). Sadly enough, most of the agile implementations fail at this level. And this is the lowest level of learning agile.
However, if you struggle and don't give up, one day the sun will shine and the first results will become visible. Not much, but just enough to give you some hope and strength to continue. This boost of enthusiasm will give you the energy required to go further. You ask other people, are constantly looking for more information and examples, and you are listening to other masters (or practitioners) about how they use it. You are multiplying the sources, and that gets you to the second level, Ha.
The first two levels are about learning from the others. Your practice is considered as still learning, so you are looking outside for examples. However, in time, after a lot of practice, you discover that you are as good as they are, and that there is not much you can learn from them. Soon you realise that most of the learning will come from your own doing. This is the third level, which puts you in the master's seat. This doesn't mean you neglect the others, but your own experience is much more meaningful and full of learning than any other cases you can see around. A master is concerned with his own work and his own improvement. Your work, although not perfect—by now you know it will never be—can be used as a case study by others who find themselves at the beginning of the road.
“Shu” Is Easy! Doing It Is Hard!
You start this with a lot of enthusiasm and hope, especially if you had a good trainer. The biggest problem here is trying to change the world. In one day! One very important aspect of agile is that it is based on continuous, incremental improvement—known as Kaizen—which basically means you cannot change anything dramatically. You can only improve. Most likely, things around you will not change because you've been in an agile training; they'll continue to be as “anti-agile” as they were before. What is always recommended at this stage is to build a plan. Nothing fancy, just setting some objectives (don't forget about the “achievable” part) and a few actions that would get you there. As simple as it sounds, most organisations don't do it. Particularly in agile, there are some things that are achievable in three months, some which require more time, and some that will take a lot of time. Setting the wrong expectations can be very damaging for the whole initiative.
This is probably the most painful moment for a team and for the organisation itself, because many things around not only don't seem very agile, but they seem impossible to change. You hear people saying things like, “this will never work in our company,” or, “our managers will never approve that,” which means they compare the reality with that ideal model that was presented to them during the training. Agile is not a destination, so there is no model to be comparing yourself to. It is a journey that constantly moves from good to better and from better to even better. If there is something you want to use as reference, that would be you in the past.
This is the moment where you should follow the master. In fact, this is what Shu actually means: follow! Not necessarily the master, but rather the way it is supposed to be done. Work with somebody with more experience and build a list of things you want to achieve in a few months, and then work as hard as you can to get to those results.
Here are some things that could be added to that list:
- Becoming more aware of the results of our own work (are we creating something that customers appreciate and value, or is it just things they have to use because they have no other choice?)
- Move closer to your customers (meet with them, try to understand them and how they spend their money)
- Spend some time thinking about the work you do and how it can be improved
- Evangelise agile to your colleagues and stakeholders
These are not simple things. They seem simple, but organisational processes, history, culture, time, and management will make sure you don't do these. Hence, the reasonable objectives list. You can always do something about these things that will make you a little more agile. Like any change, it will be hard and difficult to implement. Consequently, it will not have a lot of supporters. Everybody wants to be agile, but not at the expense of his or her own comfort, which is why securing a sponsor has never been more critical.
“Ha,” You're Almost There!
As hard as it may seem, some people and organisations do survive the Shu period. Early results will give you the courage to look outside at how others are doing it and with what results. You may even compare yourself with them. The Ha level is about breaking away. Knowing other ways of doing it, other practices, other interpretations. This will contribute to a better understanding of what agile is, how it can be used, and what results it can bring. If the first level was about trying to do it right, this level is about understanding the limitations of the way you are doing it.
Here, agile practitioners are learning from each other. It is a moment of openness because you open up to other experiences, and that will allow you to have a different understanding of the way you do things. Sometimes, just by observing the others, you can understand much more about you and your performance. To do it right, you need a certain level of maturity and practice that usually comes after months of experience. However, at this stage you can consider yourself a practitioner with a good enough understanding of how agile works.
So where can you look for examples? By now, you should already have some interesting examples inside your own company. Your own colleagues could share some of their experiences. If that's not the case, look for examples from other companies within your industry. You think because they are your competition they won't share? Guess again! Everybody wants to share and to give back to the community. If they don't want to share, don't worry; most likely, it wasn't worth sharing anyways! Conferences, books, communities of practice, webinars, and local communities are just a few examples of how much information is available out there.
The beauty of agile is that it is the same. But because it is based on a set of values and principles rather then on firm processes, there is quite a range of different interpretations that people give the same thing. These very different results create a huge knowledge base about how these methods can be used and potential new ways to improve your own results.
“Ri,” You're Further Than Ever…
The third level is the true mastery of agile. You are now an expert and most of your learning comes from your own work. This time, the learning is based not on doing (like at the first level, Shu), not on observing others (like at the second level, Ha) but on your own reflections. It is based on thinking, the ultimate form of learning.
Remember when we said it was about the journey and not the destination? This is when you start to feel it. At all previous steps, you have the feeling that you are getting one step closer to your destination. Here, at the Ri level, you understand that the more you know, the more you know you don't know. Practitioners who are at this level understand that there is much more to learn because you have to constantly improve. And since this is continuous improvement, it will always be based on something else. That something else, always different, is what will concern them the most. Every time you look back at things you've done in the past, it will be with regret that you didn't to them better because now, you, after reflecting on them, would do them differently.
This is why it's hard to come up with a maturity model when using agile methodologies. Because of this continuous improvement focus, you can never say you are at the top. You are never at the top; you are always just on your way to the top!
Where Am I?
This model is not a methodology with clear steps you have to take to be more agile; agile is not about recipes, steps, or processes. It is about working hard, doing what you're supposed to do, and always trying move to the next level. And that is a very personal and intimate journey.
By comparing any agile book with how you are doing it, you can easily assess the level of the ShuHaRi model you are at. Or even easier, if you are not sure, probably you are at the Shu level. But that is almost irrelevant. The fundamental questions are: where do I want to be, and what am I currently doing to get there?
