When we enter the keyword ‘project management’ in Google search, we receive 4,420,000,000 search results. That’s undoubtedly enormous amount of knowledge, techniques, and methodologies. And while many of them have weird-sounding acronyms like Scrum, XP, SDLC, they basically come down to two methodologies – Agile vs. Waterfall. A lot has already been written about both approaches, and both have their supporters and opponents. What is important here is why the agile approach emerged in the project management world since the traditional one based on a planning project in advance seemed to be doing well and has already had a wealth of experience gathered since the 1960s and passed on in standards and canons of knowledge?

lEARNING tHROUGH eXPERIENCE

Why has Agile and not Waterfall become one of the most popular methodologies for a software development projects? We can partially find the answer in Albert Einstein’s words:

“Insanity is doing the same thing over and over again and expecting different results.”

These words remind us about the remarkable power of logical reasoning and the simple principles underlying empiricism, according to which “experience is the only source of knowledge.”

We can relate these famous quotes to project management and the change we cope with during each new initiative. Does achieving the expected results not depend on the number of trials and errors? Is experience not a basis for further development? Individuals, as well as organizations, often forget about this practical approach. We often find out about the project results quite late – when the final effects of our work are already in the clients’ hands.

In the agile approach, we do not assume the final results very precisely, but we use the goal, vision and observe the reality. We adapt to the changes, gather valuable experience, but we also make mistakes from which we learn. We don’t want to repeat the same things over and over again and expect different results because we know it’s not possible.
We use the collected experiences to improve our work and create value-added products. 

world OF SPAM AND THE red quEEN

Volatility, Uncertainty, Complexity, and Ambiguity characterize today’s reality. In the 1980s, the US military formulated the acronym VUCA to describe the world of war, when soldiers have set goals but cannot plan in the long term because they cannot predict what will happen. All they can do is observe the current situation and react accordingly. A few years ago, this term was also adapted to business because it perfectly reflects the business environment.

Based on the description of the VUCA world, the Polish authors of the book “Zwinnologia –  innowacyjne podejście do zarządzania zmianą” (eng. Agility – an innovative approach to change management), Rubin, Grabowski, Naumiuk define the reality that surrounds us as the world of SPAM, which is fast-changing, fluid, complex, and turbid. In such a world, we cannot plan and predict much.
On the other hand, according to the hypothesis of the Red Queen which name comes from Red Queen figure from “Alice in Wonderland,” who says to Alice, “… it takes all the running you can do, to keep in the same place. If you want to get somewhere else, you must run at least twice as fast as that!”.

Leigh van Valens formulated this hypothesis to describe the natural environment and evolution, but it can also apply to the business. Business is changing, and the market abhors a vacuum, and we will either change and adapt with it or start to pull back. And what happens to organizations that don’t change? According to Jack Welch – recognized manager, long-term director of the GE concern: “If the rate of change on the outside exceeds the rate of change on the inside, the end is near.”

Adapting is not easy because the world of SPAM and the Red Queen theory is fluid and very complex. It’s the world in which we have to run to be in the same place, and stopping isn’t even possible.

Vacu prime/will

The answer to the VUCA/ SPAM world is the world of VUCA Prime (in the book “Zwinnologia…” described as the Will). It’s a world in which we don’t want to make detailed, long-term plans because we know everything is changing fast. The answer for the fast-changeability is creating a vision of what we want to achieve. The response to fluency is explaining and constantly adapting to changing reality.

Once, creating the company strategy for five, ten, or fifteen years used to be very popular. Today, the problem is to plan a one-year strategy because it’s hard to predict the future conditions of the business environment. To somehow answer how we want to function and carry out our tasks, we must have something that we use every day, and it is primarily Vision, Explanation, Lightness, and Adaptation. 

Project vs. Product

The world of SPAM and the Red Queen, building the WILL and using experience to achieve the expected results leads to the question – how to approach the projects if we cannot plan the future? How to learn from experience when uncertainty looks into project plans? How to plan work in such a complex environment?

According to the PMBOK Guide, “A project is a temporary endeavor undertaken to create a unique product, service, or result.” Product is something that’s already on the market and serves to satisfy human needs and desires. The project is a temporary undertaking regarding implementing tasks that we are sure to deliver. The product is something that will serve for a long time. Project is part of the product, one of the stages of its development.

Projects carried out over several years, the result of which appears at the very end, in today’s world of SPAM and the Red Queen, may not make sense. Investors want to see results here and now. Consumers’ needs are changing fast, so preparing a product and refining it to perfection for several years may not make sense because users will be in a different place in two years and may need completely different solutions.

Waterfall vs. Agile ProJect

To show the difference between the Agile and Waterfall approach, I will use the example of building online product sales. Let’s assume that I want to sell sauerkraut online. I have been pickling myself for many years, and I know it is not easy to pickle whole cabbage, although the recipe is simple.

My newly established startup has an ambitious plan to teach the whole world to pickle cabbage. Full of enthusiasm, I am starting an innovative project today.

I can choose two ways to implement my plan:

• The first one based on a traditional approach. I spend much money building an online store. I employ a team of developers, testers, and designers; we create infrastructure and other necessary elements for the online shop to operate globally. All this with a perfectly planned project with the proper milestones and a budget. After about a year of preparation, it’s time for a launch. I invest in advertising, and I wait for the results.
  
  
• The second one based on an agile approach: I start with little resources. At the very beginning, I check with potential customers whether they want to buy sauerkraut online; I write to my friends and post on social media groups. After about a month, I already know I have to offer something more: appropriate packaging and other accessories apart from sauerkraut to get the first customers. I have not invested any money until then, but I already know what potential customers expect and how to adapt my offer further. After completing the following steps, which took me two weeks, I already have my first paying customers. Real Start small-fail fast, learning from experience.
  

However, a small-fail fast start will not work in every case. We need to keep in mind that while there are many methodologies and frameworks to help us decide which project approach to choose, there is no such thing as a “right” methodology, ideal for use in each particular project.

Besides, there are no clear answers in the world of SPAM and the Red Queen. What is left is the vision and learning from experience.

Agata Małysz
Scrum Master at Sigma IT Poland