While Agile has been a hot topic across industries for a while now, for some organizations Agile transformation might still be a problematic issue. Does every company need Agile? Is Scrum the only possible solution for those that have adopted it and is there any alternative to large teams working on complex projects? Paweł Bejger, Operations Director at Goyello asked Andy Brandt, CEO Code Sprinters, to throw some light on the topic.
***
Paweł Bejger: What I have noticed is the prevailing opinion that Agile is best suited for IT companies. I think one of the reasons for this is the unpredictability and instability of the final product definition in comparison with products in other branches.
Andy Brandt: I wouldn’t make such a clear cut and say that Agile is just for IT. Agile is a great solution for any kind of problem where there is a vast array of possibilities and you have to fairly quickly navigate them towards one that would be satisfying – what we would call the “complex domain”. As for domains like for instance constructing cars or a putting up buildings, or any other physical structure – those are very hard to change afterwards, whereas issues like the way your website is structured or your product is labeled, all of that is to a certain point fairly easy to change. Admittedly, you can quickly prototype cars. You can 3D print models and even build an actual working car. But once the design is solidified and you start producing it on an assembly line, you cannot easily change it.
With software, we are always dealing with a unique product that we can reshape and reshape at will. That is why Agile is very much suited for software work. But it can also be used for other domains. It is worth noticing that if you look at the history of thinking about management in general, then we will learn that Agile has its roots in new product development in times when those products had nothing to do with computers.
When I look back into the 70’s, I notice that back then the waterfall approach was much more possible because everything was much more stable. Also, the type of software that was built then, for instance business automation processes for large companies, were rather stable and they were not interconnected the way they are now. Besides, very few users actually interacted with it. Once you analyzed and implemented it, not much was going to change. That’s why it could have worked in this kind of environment.
Also, there are two trends that are shaping our world nowadays: one of them is increasing complexity and the other is increasing pace of change. Much more has changed within last year that within last five years. Overall, the complexity of the world increases and an interesting question to ponder is whether this can continue indefinitely or whether there are any limits.
PB: According to what you have just said Agile is going to have more and more influence on the industry, on all industries in fact. The world changes dynamically, the complexity increases, which implies that Agile may be much more needed in the future than now.
AB: It is really hard to make predictions. I don’t know what will happen in the future and I’d rather talk about IT in which I have some expertise as opposed to manufacturing or civil engineering. In our industry I don’t think we are going to go back to waterfall and it seems Agile is going to become the standard approach in the next decade or so.
PB: Quite often companies try to introduce Agile but they fail to achieve it. I believe it is mostly because they simply miss the point. Instead of introducing the spirit and mindset of Agile they introduce a set of formal rules and procedures and ask others to follow them. Do you think there are different reasons for the fact that some companies fail to introduce Agile?
AB: Normally, I would start answering this question by asking how do you know if a company succeeded to introduce Agile?
PB: Good question, indeed. Well, we can say that every company has its KPIs but it’s not always about it. It is more about the feeling that what we achieved now with Agile is more than we would achieve without it. So for instance the product we delivered is more adequate to end users’ needs and they feel more satisfied. Whereas in the past, when we didn’t use Agile, we could have delivered it on time and within budget, but still no one used it.
AB: I doubt the motives behind many Agile adoptions. I personally think that many companies have adopted Agile just because it is popular now and there is a feeling in the market that you have to have it. There is no deeper understanding as to what purpose introducing these methods serves.
The question I usually ask when talking to a company interested in an “Agile implementation” is: “How will you know you have succeeded?” It is absolutely crucial to ask about this, because otherwise you don’t know whether implementing SCRUM, hanging a Kanban board on your wall, inviting a consultant or sending your staff to a SCRUM course is doing you any good. So, it would be a good idea to measure it somehow. In the end, in our socio-economical system a very good measure is whether you are profitable or not. Or whether you are selling more or not. The problem is that these are affected by other factors as well. Also, there is a certain time between introducing practices and seeing results. Therefore some other metrics have to be found, but in any case there should be a clear understanding as to why we want to use Agile going beyond it being now perceived as the industry standard.
So, understanding why you do it – that’s one thing. Another is that people want to “implement” Agile. As a matter of fact there is no such thing as “implementation of Agile”. When you “implement” something you assume there is an end point at which you can say that the implementation process is completed. Agile is a process of continuous improvement. We cannot say we are done with it, that’s enough, we won’t improve any futher. . So that’s the question of motives and understanding. You are right about the fact that most companies pretend they are Agile while in fact they didn’t really try to improve their performance. They just wanted to look “nice” and give their employees a feeling og working in a modern company. But often there is no deeper understanding that Agile is a way of improving the business, be more profitable and successful.
The other part of it is that we focus on processes and tools, we focus on so the called “soft stuff”, on people, on making them happy. It’s not a bad thing, but somewhere behind it there must be good technology. Your teams must be able to write good code, use sound architecture and modern tools. These technical aspects of Agile are frequently missed. So, in other words, we implement SCRUM, we have SCRUM Masters, we have Kanban boards but we still don’t use modern repositories, we don’t integrate every day and we don’t have automatic tests – are we Agile? That’s an issue every company should consider.
PB: So, to summarize: first, we have to answer the question “Why do we need Agile?” The «Why», although crucial, is often missing and that’s what should drive the change. That’s the first problem companies encounter. The second is that people think “Ok, let’s implement Agile and let’s have it done in three months”. That’s impossible, as working in Agile is a neverending story. You cannot implement it once and for all. It’s a step-by-step process. Some steps take longer, for some we can decide that they can be further improved in the future, but it should be clear for everybody that you will never reach perfection.
AB: Yes, exactly. And on top of that I would also say that is a really hard. The process of Agile transformation is difficult, it takes a lot of time and it often fails. Sometimes it is so much easier to build a new organisation than to change the existing one. That is why one of the ways of introducing Agile into an oragnisation is building a new department, a team into which people are transfered one by one. Such a team is able to develop its own working culture and has a chance of replacing the mother ship at some point. Sometimes this may be a more viable scenario than trying to change the whole existing organisation.
One other point is that sometimes Agile is not intruduced by IT departments but by the business. It is a good scenario because there usually is someone with the decision making power who pushes, removes obstacles. Unfortunately, usually they “the business” perceives Agile as something that will be contained to IT and that their way of work will not have to change. Obviously, you can apply it like this, but the benefits will not be as significant as they could have been if business also adopted at least the philosophy of Agile if not some of its practices.
PB: In case of some companies it might seem to be truly impossible to introduce Agile, especially when talking about big corporates like banks or insurance companies. I tend to agree that it is hard but for sure not impossible. The key to success is to involve all the “layers” of the company in the process and make everybody understand, feel and accept it.
AB: I agree. At the same time companies can also benefit from Agile being implemented by their IT departments, albeit those would be less significant as we already discussed. At the same time it is not always possible nor even desirable to use Agile everywhere.
Insurance companies are a good example of that. They have lots of internal systems some of which are very complex and some very old. All those systems have to be changed and adapted to new requirements, new regulations – and new systems being introduced. This being a complex environment Agile can definitely help. At the same time I am not sure using Agile in insurance sales is even a good idea.
There is theconcept of SCRUM studio developed by Scrum’s creators, Ken Schwaber & Jeff Sutherland. It is essentially when only a part of an organization implements SCRUM, but does it very well. It then serves other departments and functions by developing software that they need. That’s a good, viable pattern.
An example of this concept applied is the Everest project, probably one of the biggest Agile projects in Poland. It was built as a separate organization within the PZU insurance group. It was a separate unit, with separate culture, working in a very Agile way, especially when you consider their background. I think other companies can really follow that example.
PB: So sometimes it’s worth identifying which parts of your company really need the Agile approach and which of them will really benefit from it.
AB: That’s right.
PB: When talking about Agile people usually think about SCRUM, which is just one of its implementations. They tend to forget that there are other Agile methods like XP, Lean, Kanban or Crystal Clear. I know from my own experience that there are many projects or phases of the project where for instance Kanban is much more useful.
AB: Indeed, Agile practitioners should be aware that there are other choices apart from SCRUM within Agile. SCRUM is a management framework that helps structure the team and its work, but it doesn’t cover everything – it doesn’t address the technical part for example. SCRUM is popular because it is very simple. It is a minimal set of basic practices you need to be Agile, to work in an incrementally and iteratively and use the empirical approach. Other methods, like XP or Crystal Clear are not really that different from SCRUM. So choosing any of them instead of SCRUM wouldn’t be worthwhile.
You should go for SCRUM if you build products that undergo significant functional change, when intensely adding new functionalities and ideas into the product. It might not be that useful for maintenance scenarios because SCRUMs assumes you have more or less stable sprints. And if there is a bug that needs to be fixed immediately you cannot say it has to wait until the end of the sprint and then you will have a look at it. In such cases the Lean/Kanban approach is much more suitable. At the same time there are teams successfully developing products with Lean/Kanban so it is again not as clear a cut as some would have wished.
PB: Some people claim that Agile works only up to a certain project size and above it it’s better to use more formal methodologies like PRINCE2. I can’t agree because I think Agile works even better with large projects, but you need to learn how to scale it. Do you agree?
AB: In my opinion, the first question to ask is: “What makes a project big?“ Is it big because many people work on it? Or is it big because we expect big profits out of it?
PB: Usually a definition of a large project is dependent of the amount of people taking part in it. The more people in the project the more managerial effort is needed. It is often hard to control all the team members and make sure you are not losing their potential.
AB: So the next question to ask would be: “Do we really need big projects?“ Why do we need large teams in the first place? We assume that to build large, complex systems we need many people. We assume we have to design them as one entity whereas that’s not the case. A workable architecture of a large systems can evolve from small components, each of them solving one problem and being interchangeable with others. A real-life example is the Internet – it has never been designed as a whole. Every time a problem emerged someone came up with a protocol to solve that problem and a very complex, global system slowly emerged.
I could go deeper into why it is the case, but the more complex the problem is the more you need empiricism to drive your efforts to solve it. Otherwise chances are you will invest time and money in something that doesn’t work. Agile splits complexity into small, manageable chunks – sprints or iterations worth of work – that get solved and added to the resulting system as working pieces. That way complex solutions emerge without the need for detailed upfront design – and without the need for tightly coordinated large teams.
PB: What’s the future of Agile in your opinion?
AB: The complexity of the world around us increases, so I expect Agile to become the standard way of working in IT and possibly also other industries.
***
Andy Brandt – Founder, CEO and Agile Roshi at Code Sprinters. He has over 20 years’ experience in the e-commerce, telecommunication and software development industries, providing leadership and direction. As a mentor, he helps people grow. As a manager, he helps businesses become successful.
Paweł Bejger – Operations Director of Goyello and .NET Architect. An Agile evangelist, always searching for the most efficient ways of solving problems to satisfy both the development team and the client. As a certified Scrum Master, he is a true advocate of Scrum.