Agile project management methodologies, such as Scrum and Kanban, have already been in everyday use in systems development for years. A massive number of articles and books have been written on the subject. Everyone who is in contact with the IT business in any way knows what Agile is. Or do they really? That question often pops into mind in the everyday life of agile projects – and even more frequently when writing project quotes.
And for that question, I am writing this article – to make the purchasing process easier for the customer and make the service easier to provide.
As a digital service provider, it is always a tad unnerving to bring the other party’s abilities into a conversation. I do not intend to claim that the service provider would be right but merely to shine a light on some relevant observations from everyday life. And learning from these observations can genuinely profit both the provider and the buyer. Sure, ‘win-win’ is an overused buzzword, but it is still a wholly possible outcome. All parties benefit when everyone feels like they’re winning from the get-go. That is all the more likely, the more aligned the customer’s and the provider’s view on the project model is.
In this article, I’ll cover the following topics:
- Agile vs. the waterfall model
- Common pitfalls of Agile from a product owner’s point-of-view
- Specifying what is a successful project & the MVP principle
- Importance of interaction, collaboration and partnership in Agile
Agile vs. Waterfall – or something in between?
The truth is, Agile projects are not always that agile. Sometimes the problems may begin to form as early as in the purchasing process. At least one reasonable reason for this could be that while there is plenty of information on Agile in general, very little has been written on purchasing Agile projects.
In traditional project management methods (such as the waterfall model), the three triangle-forming variables are scope, cost, and schedule, with quality in the middle. In the waterfall model, the scope is the only fixed variable at the beginning of the project. Or actually, in practice, all the three variables of the triangle tend to be fixed, but the scope is the most rigid. It is thus crucial to understand that in Agile, the triangle is flipped upside down, so where other parts can be fixed, the scope is anything but fixable.
There is always a predetermined goal in traditional project models, and to reach it, both the time and budget resources bend.
However, in Agile projects, the time and budget resources are set in stone, but the goal may be reformed if needed.
It is not enough to grasp this idea merely on a general level. In practice, an Agile project team is expected to be not only agile but also flexible and adaptable. Usually, at the same time, the team is also expected to comply with a fixed scope. That results in the team being severely limited in latitude, thus having no real flexibility to speak of. Even if scope can yield a bit in this situation, the team is hampered to an extent where it possibly can’t remain flexible.
Personally, I am a firm supporter of the ‘Agile triangle’ within Agile, where each tip of the triangle is entirely different from those in a traditional model. In the Agile triangle, the first two variables are value and quality. The third tip of the triangle, constraints, is then reserved for the three traditional variables: scope, budget, schedule. This way, the focus within the project is on providing the most value for the business, which is what every project is all about. Similarly, the traditional variables can be examined as one variable. Also, quality is often not brought up in project-related discussions. In this approach, the desired quality of the work is something that has to be consciously decided before the execution phase.
Agility stems from flexibility. A project cannot be truly agile if there is no flexibility in its variables (quality, budget and scope). On the other hand, if the budget and the project’s scope are fixed, then either or both, quality and schedule need to give way. Let’s use a metaphor: would anyone buy a new car with a set price and features, knowing that its quality is compromised? Then when the car rolls off the assembly line, it does have the paid features, but the car just keeps breaking down. Or that there is a car of higher quality available – but only a few years down the line. Unfortunately, in the IT world, people still buy these figurative cars.
In quote requests, it is sometimes apparent that the buyer wants to eat their cake and have it too. They set a price and scope for the project, so only the quality and schedule remain flexible. That is not agile but instead follows the traditional waterfall model. Advancing a project in sprints or sections is not anywhere near enough to make it agile.
The true ability to go agile extends beyond the project team
The most important person to the success of an agile project is the buyer’s product owner. Teaching agile to the product owner is part of Wunder’s delivery model. Without the training, it would be next to impossible to work together. As a result, the product owners get the support they need, and even less-experienced product owners can quickly grasp their role in the project.
So, where does the Agile’s heel lurk then?
Among other things, the following situations can cause problems:
- The product owner is not allowed to allocate enough time for the project.
- The organization has not mandated the project owner to make decisions in the fast-paced project, and the organization or its part does not make fast enough decisions
- Decision-making is tied to contracts that have been made as a result of a less-than-optimal purchasing process
- An unreasonable amount of time is spent on interpreting contracts and dwelling on the guarantees of a fixed delivery instead of focusing all resources on achieving the best possible result and generating value for the business
Defining success and minimum viable product: Understanding the rules of agile
How to then get the benefits of agile without stumbling into the problems? To answer the question, we first need to specify what success means. When evaluating a finished project, we should take into account the basic variables of agile. It’s not realistic to say that all the variables are of equal importance and need to be realized in full. Why, though? Purely because the agile delivery model is based on prioritizing: There are things more important than others in an agile project. When the project advances, an important matter might arise, and prioritizing is again needed. Prioritizing is what makes a project agile.
In relation to Agile, the principle of a minimum viable product (MVP) is often discussed. Regarding a single given feature or a requirement, MVP means defining the bare minimum level of what they have to be in order to work. The MVP principle enables the project team to produce all the desired features for a given product, but at their minimum level only. If you happen to be considering whether the agile project model might work well for your organization, understanding prioritization and MVP gives you pretty good keys for succeeding in purchasing the project.
Be willing to interact and collaborate – and do it with the right partner
The first principle of the Agile Manifesto stresses the importance of interaction. That also applies to agile projects. Effective collaboration is the foundation for a well-functioning project team. And like we all know, effective interaction is based on trust. In all successful agile projects, the customer and provider trust each other.
Trust should also extend beyond the project team in both organizations. If this is not acknowledged in the customer organization from the start, the project’s duration is often too short of a time to change the situation. Changing the attitude of an entire organization is usually not very agile, and trust is built, if it even is built, as a result of much longer collaboration.
Effective collaboration means partnership – and not necessarily measured in time but in thought. One sign of effective collaboration is that in a project team, the boundaries between the roles of the service provider and customer melt away, and the team truly becomes a unified entity. The team works towards a shared goal supporting each other with respect. Even if the partnership only lasts for the time it takes to complete the project; it is still a partnership.
Often it is understood that the collaboration continues even after the project is delivered because services require continuous development. This further emphasizes the meaning of a partnership. Switching service providers is always possible but is never as profitable compared to making the effort to find a suitable partner in the first place.
Your organization is probably able to carry out an agile project if:
- It understands and commits to the basic principles of an agile delivery model (flexible variables: budget, scope, quality, schedule)
- It can appoint a product owner for the project who has:
- an understanding of the organization’s business
- enough resources for the project as the agile delivery model requires a lot of attention from the product owner
- the trust and mandate of the organization to make decisions
- It recognizes the meaning of a trustworthy delivery partner over the given requirements
Let’s innovate, find solutions and succeed together
We would love to discuss the project models best suitable for your needs, so don’t hesitate to contact us!