The Agile Mind-set.
To many people Agile is just another approach to project management, another set of methodologies which means applying different processes to achieve the results. And it is that too, but it is much more than that!
Before even talking about Agile methodologies we need to understand and accept the idea that Agile is first and foremost, a mind-set. It is a way of thinking about the work that you do and challenge many of the things you do. And more importantly, always trying to see if there’s a better way of doing things. Agile is a way of achieving results that is based not so much on what plans or processes are directing you to do but more on what is the right thing to do. To put it simply, Agile is adding value through your personal contribution and ideas beyond what people already expect you to do. It might seem like plain common sense to act based on your core values but as many of those who have implemented Agile can tell you, it is not that easy. It is not easy because we have to deal with existing processes – and they have to be respected – hierarchies, customers who might not fully understand this way of working not to mention that the whole system of values could be corrupted.
Luckily, there’s a solution to this. In the Agile world people regard the Agile Manifesto (www.agilemanifesto.org) as the most important document when you are at the beginning of your Agile journey. What is does is to lay it out for you as simple as possible what are the values you should share when you are doing Agile. And because the common sense seems to be the theme here, the manifesto reiterates simple concepts like valuing people, helping your customers and delivering something of value that could benefit your end customers. This set of values and principles that you find in the manifesto is so fundamental that, in many people’s experience, when Agile implementations fail, they don’t fail because of a poorly implemented methodology but because people break the values in the manifesto.
Slicing your product
One of the benefits of doing Agile is that you are delivering your product faster and ensure you are delivering the right product. You do that by slicing your product and delivering a slice of that product with every iteration. We call this iterative and incremental.
Being able to slice your product and deliver it in thin slices has two major benefits:
Your customers are getting some functionalities – hopefully the most valuable – quite quickly and they don’t have to wait until to end of the project when they get the whole product. They will get the whole product in the end of course, but in slices delivered after each iteration. It might not be the whole product you’ll get after each iteration – and it is not supposed to be – but for sure it’s better than nothing. Not to mention that if you really manage to slice it into independent pieces, your slices could deliver value by themselves. So, every few weeks you’ll get something!
Your customers can provide some valuable feedback early enough so you can still act on it. So, what kind of feedback could they possibly provide? First, they can say they don’t like what they see. It’s never nice to learn you are not building the right product but if that is the case, you would want to know it as soon as possible. With many other approaches to project management, you usually learn that at the end of the project when it’s too late to change something. In Agile, we call this “fail fast”. If you were to fail you would want to fail fast and cheaply. The other benefit of having your customer validate the product is that they might get more ideas of new functionalities that they may want in the product and maybe they were not obvious at the beginning of the project. A famous acronym in Agile is IKIWISI (“I’ll know it when I’ll see it”) which means customers react much better when they are shown something. If you want, you can look at this as a customer co-creation of the product.
Limit your inventory
This is probably less obvious at first sight but it is one of the cornerstones of being agile. It simply means we chose to focus on fewer things rather than on high volumes. We could just say focus but very often we have to deal with so many things in parallel that it is hard to concentrate and focus. When a Scrum team plans a Sprint, they limit the inventory of work they will focus on to just one Sprint – a few weeks. They do keep in mind the overall product but they commit to a small piece of functionality and focus on getting it done. When a Scrum team performs a Daily Stand-up, the talk about what they did the day before, what they plan to do in the next day and what’s blocking them. So again, a very limited inventory. What is the benefit of operating with a limited inventory? First, you will finish faster which means you are delivering something. Imagine you have to work on a piece of functionality that takes 10 days. If you split that in 10 pieces you might actually deliver something every day. The smaller piece might not be fully functional by itself, but you can show progress. Operating with big inventories has a few problems. You will spread your attention on multiple items and you will not be able to focus. You might end up working a lot but not necessarily delivering something at the end of the day. Working with big inventories requires also a lot of extra work which is not necessarily valuable for you customers, things like more meetings to sync, more emails or documents to write and read, increased and often more complicated communications and collaboration.
Achieve flow
Another thing which is not widely known about Agile is that people who are doing Agile know that are part of a flow. They understand that by themselves, as individuals, they cannot achieve much. If I were to pick an example, I would pick a software developer. This developer might think that he or she can work independently and build code or software features. But in the same time the developer could also realise that he or she needs somebody to prepare the specification – possibly a business analyst – somebody to do some design – a designer maybe – or somebody to build the architecture and the databases. And this is only what happens before the developer actually does some work. Equally you can apply the same thinking to what happens when the software developer finished the work. Those functionalities will have to be tested, integrated, deployed, maintained, etc.
In Agile, we understand we are adding value only if we deliver something valuable to the end customer. That means we need to see the whole flow, understand who does what and constantly think about ways to improve this flow by making it faster and faster. To continue with the previous example, our software developer will be more concerned about how the end product gets to the end customer rather than how he or she can do more work individually. Our developer might realise that in addition to writing code, he or she can provide a lot of help and support to the colleagues involved in other parts of this flow. In the end, you are as valuable as the result you are producing.
Embrace Kaizen
The Japanese word “Kaizen” has become more a philosophy than a simple word. It means focus on continuous improvement all the time. Instead of big initiatives and dramatic transformations, we try to change something small every day and become better and better. In every Agile methodology, we talk about how we can build better products and how we can be more efficient, which normally translates into better and cheaper products.
Just to illustrate, let’s pick Scrum, one of the most famous Agile frameworks. At the end of each Sprint, the team will do a Sprint Review and a Sprint Retrospective. These two ceremonies – yes, that’s how they’re called! – are the Kaizen moment.
The Sprint Review is the moment when we look and the product we built in the Sprint and try to see if there’s a way to improve it. And to do that, we do a demonstration in front of real end customers. We are showing them the product hoping that they will get inspired and give us more ideas about what new features we can add to the product. So, with this we are trying to improve the product.
The Sprint Retrospective on the other hand, aims at improving the processes. The team gets together and tries to identify things that can be done differently, tools that can make them more productive, processes which could be optimised, time that can be saved. Implementing these ideas normally leads to better processes, more results per Sprint, so a more efficient team.
In the end, the Kaizen philosophy is quite clear and simple. It doesn’t really matter what you do and how you do it, just give yourself some time to reflect and improve it. That’s why we say that in Agile the only relevant competition is yourself a Sprint ago. If people truly embrace the Agile values they will do this naturally with no pressure from the outside. They understand that by improving the product they are building and the processes they are using, they have a tremendous added value which makes them reliable partners for their customers. In conclusion, doing Agile is not really that hard. But it requires a good understanding of a few things like the ones we’ve covered here.
Once these concepts are clear, accepted and shared, doing Agile becomes just a formality. Or just plain common sense!