Dsc 9747
Łukasz Węgrzyn, Paweł Kot

When two Agile experts get together, the result is a wealth of knowledge and insight. Take a look at what Lukasz Wegrzyn of Maruta Wachta and ITMAGINATION’s Chief Enterprise Architect Pawel Kot have to say about Agile’s strengths, limitations, and future on the Polish market. 

Agile methods have been revolutionizing the IT sector for over two decades now. They make it easier to create software, they enhance the overall quality of projects, and they quicken the pace of launch. It’s clear why they lie at the heart of client cooperation for many IT providers. However, it’s important to question whether the Agile mindset applies to all cases.

Let’s start by asking a simple question. Are the rudiments of Agile Software Development still valid today?

Paweł Kot: There is only one real answer to this question. Today, when I read the tenets of the manifesto, I still agree with every sentence. However, theory and practice often diverge. We still need to learn a lot. But there is some good news – Poles are extremely open to Agile.

Where does this openness come from? Why do Poles take this approach so willingly?

Łukasz Węgrzyn: Poland is a rapidly changing business environment, which happens to be exactly where Agile continues to work well. In the past, IT project implementation required a long-lasting elaboration of key assumptions, and creating software often took years. There were projects that failed to achieve their intended goals, because (for example) client expectations changed or new solutions appeared that made existing ones obsolete. Research and experience shows that by going Agile, we can react faster. We are less prone to mistakes, and we can guarantee better business results, especially in growing sectors of the economy.

Nevertheless, for many companies “Agile” seems to be a bit of a “catch-all.” To what extent is being an Agile organization merely a trend, and to what extent is it a practical need in Polish businesses?

Paweł Kot: The words “agile” and “agility” have been tossed around frequently. We are dealing with a certain trendiness combined with a very dangerous view that Agile implies a lack of planning or a free-for-all. In fact, it is the exact opposite – agility needs to be understood as a method of reacting to an ever-changing environment, to act in conditions epitomized by residual knowledge, and to deal with situations in which we do not know what the shape of the result is going to be. Having said that, we still need to move about within a certain framework – we have a specific goal ahead of us, and we must attain it. In Agile, planning is crucial. Chaotic actions devoid of a clear end do not take us anywhere.

Łukasz Węgrzyn: At this point, it’s worth adding that we still fall prey to several myths related to agility, despite the popularity of the concept. I think that the most dangerous one stems from a misunderstanding of the concept itself. I have seen many situations where companies had no clear idea for their business – they wanted to do something but didn’t know what to do or how to do it. The managers said “Let’s get to work with this Agile approach!” This is a recipe for disaster.

Why is that?

Łukasz Węgrzyn: Agile is not only a methodology, it’s a mindset focused on completing a project and managing change. Contrary to the captivating simplicity of its tenets, it is extremely demanding. If we do not keep this in mind, we can easily get burned.

Paweł Kot: Here, the relationship between a company and its provider is of key importance. If there is no trust, no communication, and no sincere cooperation, the end result can be damaged relationships, to say the least. Sometimes it even ends up in court, because the company had unrealistic expectations or the provider promised far too much.

Łukasz Węgrzyn: In court you can lose up to three and a half years of your time even if the court rules in your favor. In the current approach to implementing projects, when we draw up a conventional agreement, we tend to focus exclusively on three areas – liquidated damages, liability, and settlements. There is no time to think about the project itself from the business and implementation side. In such a model, everything is “stiff” and prearranged, especially the price. It’s very difficult to break free from these stiff categories where everything is written down, anticipated, and subject to an assessment that does not tolerate deviations.

Paweł Kot: For me, projects with a stiff price based on an agreement are mostly born out of a pure desire to shift risk and responsibility onto others. If there is a project, there has to be an agreement specifying the price and the liquidated damages. It’s difficult to break free from this vicious circle.

Would you say that Agile recommends prudence, then?

Paweł Kot: Not exactly. I think I would rather say that trust is of key importance here.

Łukasz Węgrzyn: That trust has to be mutual. On one hand, providers may expect a partner relationship. On the other hand, a company has the right to expect quick results, since this is what it is paying for. Nothing builds trust more effectively than a quality solution delivered on time. Clearly, it will not be a project tailored to the needs of a new ERP system, but rather something smaller – something to play with, show at a board meeting, or test with selected clients. These days, that kind of dynamism is a key advantage.

There is another dimension – the trust inside the organization that wants to take advantage of Agile methods.

Łukasz Węgrzyn: That’s right. We are all watching Amazon’s success – if not with envy then certainly with great interest. However, one thing that’s often left out is the fact that people obsessed with products (as Jeff Bezos himself puts it) are behind that success. They do whatever it takes to develop their products. This would be impossible if they did not have the right conditions. The organization guarantees them the chance to put their passion into a product while enjoying the full trust of the company’s leaders – even if it means that a project fails from time to time.

Paweł Kot: You're absolutely right. An Agile approach is not possible where hierarchies dominate. Agile is above all a revolution in the way people think.

Łukasz Węgrzyn: A revolution in the way people think doesn't just happen overnight. Having said that, agility is worth every effort, as for many businesses it could be as impactful as the Copernican Revolution. At the end of the day though, we need to ask ourselves a simple question – why are we doing this? It’s not necessarily about changing the world, but rather about helping our business maintain or even improve our position in such a tough and competitive market. This is why leaders play such a pivotal role – their trust in their people, their motivation, and their communication skills are all critical.

How important is discipline in all this?

Łukasz Węgrzyn: It is essential. Not only in the implementation of a given project, but above all as a certain way of thinking about achieving goals. We often lack this awareness of discipline, which implies that people take a disheartened attitude to Agile.

Paweł Kot: That’s right. Agile projects require a high level of internal discipline. It’s needed to make sure we don’t let go at moments of key importance, and to make sure we’re fully aware of the time passing by. One of the most frequent traps is the idea that because we do not have any requirements, we can do the project the Agile way. That is a 100% guarantee of failure. When it comes to an Agile project, you need to know exactly what it is you want.

Finally, let me ask you about the role of the product owner in Agile projects.

Paweł Kot: They need to be a superhero that knows everything and can do everything, but on the other hand they need to stay firmly set in the business reality of the company. In practice, maintaining such contact with reality is very hard.

Łukasz Węgrzyn: The product owner provides the IT staff with information about the current needs of the business, while setting the challenges and motivating them. Earlier we mentioned Amazon, and how its people are obsessed with products. I think this is also one of the qualities of top product owners. It’s once again all about trust – it’s not enough to appoint someone to be a product owner, you must guarantee them enough financial resources and availability to implement a project efficiently. In other words, you need to trust the person, which brings us to what we said earlier – Agile begins with trust.