What problems are we actually solving with Agile?

While flying to Munich, watching a video about ‘Finding the right solutions as a product manager through Agile’, it came to my mind the number of different problems that we think we’re solving using Agile! Agile, the most popular software development management framework so far, which came to the scene as the glossary of some curious minds that experienced many problems with the traditional ‘Waterfall’ method. I just was wondering, why at the first place we had problems with the traditional model? And does Agile really solve those? I’ll try to answer both questions from a mixed people/business/process perspective.

What problems we had before Agile?

I’ll list major 3 problems as I see it:

• High cost of change. 

• No innovation-friendly environments. 

• Illusion of control. 

Before we start, some hypotheses that we need to agree on:

• Software projects are a special type of projects that differs from other types of traditional projects (i.e. Constructions, Infrastructure, etc…).
• Software teams need innovation to drive value and create products that matter and can achieve customers attention.
• Internet made things bigger, harder, and more complicated. Providing more options for the customers and more space for the competition between products. The competitive environment implies many changes that the product needs to fulfill quickly and also in more innovative approach. 

High cost of change:

The software industry is relatively new, and by the amount of investments we made in such industry, it could evolve extremely fast! And it’s a going-on evolution, software industry now is different than 5 years before, and of course totally changed over the past 20 years.

A main reason of change is the amount of data we managed to store and process, with everything being digitalized, we became able to store more and more data (A really Big Data), and this caused a whole new practices and methods of developing software.

In the old days, software projects had relatively static path, we quite know what we want to achieve before ahead, so, plans were made, teams were formed, and let’s get to work! Working in a very long iterations (e.g. 6 month - 2 years) was an industry thought about approaching software projects. Because, at the end of the day, they’re like any type of projects, right? No, it’s not quite straightforward.

Software projects are intangible, and hence, they only exist in the stakeholders minds. And that’s one of the reasons why it wasn’t a huge success to approach them like a traditional type of projects.


So, we noticed that after 6 months of continuos work, the results weren’t so great, the stakeholders weren’t very happy, and on a wider scale, most of the projects failed to deliver on time and budget! And it was very expensive for example to change some functionality that was implemented because it wasn’t what we expected! So, you know, a lot of mess here and there. And the industry noticed that the cost of change is very high! So, a solution must have existed to handle the growing needs, and the changing climate of market, customers, and stakeholders!

Agile came to the scene 

Agile then came to the scene with a new mindset of approaching the software projects, instead of investing heavily and assuming that we know what exactly to implement, why not making our patches shorter and our architecture more flexible to adapt changes over both short and long term? (working software over product specs.)

Let’s go to the market, do some research, have a vague idea about the long term goals, and focus on the short term outcomes, and then, let’s measure, was it a success? No? Okay, let’s review our intial thoughts and identify why that wasn’t a success, is it the market? The customers? Or the communication? And then let’s make our next short patch more optimal, and so on. It’s about continuos improvement (of course this was a base to what we know today in software development as CI.)

Not innovation friendly

So, in a fast growing digital world, ideas got consumed quickly. Maybe we don’t even recognise the amount of competency that we’ve reached to push new ideas into the market! It’s just crazy how hard the competency in the digital world is!

So, what’s your oxygen as a digital service provider? Yes! Innovation, you need to push new (valuable) ideas that your customers will really find useful and interesting. Before Agile, the work flow wasn’t so friendly, you have to do all the work beforehand, and take a seat back and watch the results 6 months later. The reality is, things began to change quickly! It can be a huge difference what you think market is now and 6 months later. You have to be flexible to adapt the changes.

Agile came to the scene 

Agile came with a solution to this very point, which is, you know? Don’t assume you know how things will work so long ahead! Get yourself a vision, but be flexible to change, do it in small iterations, so that you can always preserve and validate. You have to create a culture of experimentation, you’re a scientist, the market is your lab, and innovation is your tool belt!

Illusion of Control

Software specs documents were a very common tool that projects and providers use to communicate business drivers into more technical specs that can be achieved. This business-technical bridge has one issue that Agile came to solve, it assumes knowing all about what the user want! It creates an illusion of control that stakeholders may think they have over how and why the users are using their products/services.

This illusion of control actually isn’t very real -maybe because it’s illusion?- because humans are very hard to be predicted. Humans are different, they share some common desires and interests sometimes, and that’s how UX designers make it sometimes easier for someone to get something, but still, you don’t completely understand what motivates them to continue using your product or service.

That’s why, although being delivered successfully, most of the software projects die because there’s no market need. Sadly!

Agile came to the scene 

That’s why, in a more Agile Way of thinking, you shouldn’t assume that you understand the customer completely, of course you understand some of the pain points -that’s why you have a product at the first place- but you always need to be customer centric. Always ask the customer! He knows better why he’s using the product, and you may be surprised that there are some drives that you didn’t even think about!

Conclusion

Agile is a way of continuous improvement in a world of uncertainty. It tends to manage the innovation process without being a restrict or a gate. Everyone can use it differently, but the main thing would remain to organise your innovation process in the large-scale products/services.