How did Agile "land" in your organization?

The word "Agile" is one of the buzz words that some time ago was spoken by everyone and in all circumstances. Many organizations "implemented" Agile and expected spectacular results that ... did not come. The great hype about this methodology is becoming more and more common, and we increasingly see that the topic is a little deeper than we thought and a bit more complicated.

How is it with Agile then? Works or not?

Yes! Properly used, it works very well. It's like a road roller - it will be the best tool for leveling the road, but you will try to swim with it ... you will sink.

Does this mean that we use Agile incorrectly?

There are many factors that favor the use of Agile methodology. There are also many environments and projects in which Agile will not help. Agile is a bit more than a methodology and goes much deeper in the way the company operates than we think.

How do we implement Agile?

Agile "implementation" often requires a change in the mindset of a significant part of the organization, which is neither easy nor quick. Therefore, usually after the initial success and a series of IT training, the organization claims that the implementation has already have been completed, even though only the first step towards agility has been done. Often, after a period of initial euphoria, there is a time of first disappointment with agility and wondering if it works properly.

Agile on the side of software suppliers

Nowadays, on the wave of a general trend, every software supplier declares that its organization is Agile. Unfortunately, in the vast majority we can come across one of several cases:

• The organization only claims to use the Agile methodology while the whole team works as usual. The customer pays for a specific amount of resources while the supplier juggles resources between projects. To find out about it, It is enough to ask for the name list of developers assigned to us with emails and telephones, and then check from time to time how often they answer questions to find out that they are now not on the subject of our project.
• The organization is divided into small teams that have kanban boards and does daily morning stand-up meetings. It's a little better here than in the previous case, but often, apart from these two elements, nothing else happens. The team often fails to deliver what has been declared in the sprint, and the project manager creatively explains to the client that this is what agility is all about and then gradually transfers the unfinished tasks to the next sprint. Over time, the supplier's PM builds large time buffers to show that his team is getting in time, but the effectiveness of such an organization is very low.
• The organization is divided into small teams that are dedicated and tailored to projects. The basic principles of Agile are followed, and tasks from each sprint are implemented in time. The problem begins to appear when we want to release a product because it turns out that quality does not quite meet our expectations, which means that SCRUM at the level of the team itself works, but at the level of project management it does not quite work.

Often, suppliers also use the word Agile as an excuse for poor management of the project itself. "Since the client pays for each day of the sprint team, he can also pay for the day of delay." Let's keep in mind that agility does not release anyone from delivering the agreed sprint scope on time.

Agile on the client's organization side

Agile "implementation" usually starts with the IT department. Project managers and engineers learn that instead of working on a requirements document, they will now be working on user stories. A tool supporting task management is being implemented, and a whiteboard with yellow stickers appear in the room. Everyone organizes daily stand-up meetings. We have enthusiasm for a while. After several months, however, it turns out that:

• Projects implemented in Agile tend to drag on forever
• Business owners behave like children in a candy store - every few minutes they are at a different shelf and want everything
• PM is pushing more and more functionalities into every sprint because the dates are running out
• After a few months from the start, it turns out that the project is not delivering the expected functionality and additional resources are needed to complete it

Why is this happening?

In a standard approach, IT is responsible for final user satisfaction. In other words - If the finished product does not suit the users - this is an IT problem. So IT has analysts, who describe what exactly is to be done. It is done at the beginning of the project, through a series of workshops with a business client and business users. The disadvantage of this solution is that it is often impossible to do it accurately enough or business conditions change over time (often also business owners changes). Sometimes, users do not know precisely what they want until they see the finished product, then it turns out that "a few" additional functionalities are still missing.

Agile meets the problems described above and reverses the situation slightly. IT is only a service provider and contractor, and a significant part of the analysis is carried out by the business. IT still helps, but the involvement of the business side is significantly higher.

And here the problems begin, because it turns out that Agile has not been fully "implemented" in business and the business side is not aware of the benefits, risks, and potential problems associated with Agile. In particular:

• The business side is not fully aware that the burden of analysis rests on it and most importantly prioritizing of what will be done through the project
• Since never before, no one asked the business side how an application should be made, and now suddenly business side can decide, it begins to decide, and generates many changes focusing mostly on non-essential additions instead of the most important elements of the new product
• Because the conditions around the business change frequently, the backlog changes often, and thus the direction of application development is altered. In moments of panic, the business owner pushes another "critical" functionality into the current sprint or even adds new features during the sprint.
• Sometimes the business prerequisites necessary to perform IT tasks in a sprint are not ready before the sprint starts and the project team gets them only a few days before the end of the sprint.
• A business owner without experience or proper training is not able to correctly set the priority list for tasks, allowing to deliver a working project on time by focusing on the essential elements only.
• The organization as a whole is not yet ready for agile projects and does not give the business owner sufficient autonomy. As a result, having no other choice, the business owner is under pressure and adopts more and more insignificant changes coming from project stakeholders.

It is clear that the business side has a difficult position here. In the case of Agile, all these activities require much more time from the business than with the traditional approach. The role of the business owner is much more important here. An organization that wants to act agile must be prepared to delegate 100% of the business owners time to the project, instead of adding the project as an additional element to current tasks.

It is one of the fundamental problems that arise in organizations that are starting to use agile methodologies because it requires changing the approach and communication of business with IT and acquiring the necessary competencies on the business side. What's more, it is often necessary to make further changes in the organization, such as developing project management competences on the business side.

If we go further and want to provide software on a continuous basis - using DevOps, Continues Integration and Continues delivery, allowing for even greater agility, the organization must change even more (this time more on the IT side). Thus, Agile initiates a whole series of far-reaching changes in the organization, which implementers are often not aware of at the beginning of the journey towards Agile.

If for some reason we stop our walk to agility halfway, we will not be able to take advantage of its benefits even though we will bear its costs. That is why Agile is more of a business philosophy that ultimately covers a significant part of the organization and goes far beyond IT. Well implemented Agile can significantly accelerate the implementation of some IT solutions. It should also be clearly emphasized that the delivery of some projects will still be more effective using standard methodologies.