What is agile development? 4 principles that lead to success

What is agile development to me? I have been pondering this question since I recently read an article on why agile product development doesn’t work. In it, the author describes how horrible working “agile” was for him. All the examples mentioned, however, are not related to agile but they are the symptoms of a poorly implemented/run Scrum team. 

20 years after the concept of agile development was formulated, it is still often thought that Scrum = Agile. It is this misunderstanding that caused my desire to try and formulate what agile development actually means for me. 

Upfront, two things to mention that are clear to me. 

One, successful teams have been working agile without ever having heard of agile development. The agile manifesto was written in 2001. Before and after that, successful teams have naturally been applying agile principles. 

Two, agile is not a method. Agile development centers around principles and a mindset.

Email address:

Leave this field empty if you're human:

Agile development is about mindset and principles

Agile is not Scrum, Lean, Kanban, DevOps, Extreme Programming, or any other agile method used in modern product development. Don´t get me wrong, all of these frameworks have a reason for being. I am working as a Scrum Product Owner (PO). We are successful and I thoroughly enjoy using this method. Scrum is one way (of many) to manifest and formalize agile principles. It is not equal to Agile. 

Agile development is a mindset centered on principles. The agile manifesto itself actually includes twelve underlying principles. I want to expand on these and offer my thoughts on four features of agile development that stand out to me:

1. Getting direct feedback fast and often
2. Regular review and adoption of processes
3. A cross functional team with full responsibility
4. Making the work visible

To me, these four are of paramount importance to having a successful team. 

Getting direct feedback fast and often

In the more traditional development approach you would have a sequence of steps that are done subsequently one after the other. Something along the lines of requirements→ design → development of the entire system→ testing → maintenance. Only after the requirements for the entire product are defined is the design process started, only after this is fully completed, is the development started, and so on. This works perfectly fine in many situations (even today). You run into problems with this approach when the requirements are volatile.

In a volatile environment – which is more prevalent today than it ever was – requirements may be unclear or they may change during the development process. In an extreme case, what was initially planned is then no longer needed. 

Using the traditional approach you will find out that this is the case after the development and testing is complete, after you roll out the finished product to customers. This can be months or years after you started the development. Months or years, just to find out that what you built isn’t needed.

This is the reason for the iterative approach in Agile development. At its core this means that the team ships a working product increment that satisfies a subset of the requirements as fast as possible. It can then observe how it is accepted and how users interact. Getting this feedback as directly as possible from customers and users is then used to decide on how to proceed. 

This is why Scrum advocates sprints that are only a few weeks long and end with a review. It is the formalization of this approach to deliver fast and get feedback quickly and often. The tricky part is creating the product increments that can be completed in a few days/weeks and still satisfy some need. Slicing requirements horizontally is the key skill to make this work.

Regular review and adaptation of processes

Agile development is all about reflecting on how the team is working and changing what does not fit the current situation. There is not much more to say about that. The team needs to figure out what works for them. 

There is not one size fits all solution. Every situation is different. Thus, it is important to pragmatically adapt methods and frameworks to the situation instead of dogmatically applying them. 

The less knowledge and experience is present within the team the more it will need to rely on strictly applying frameworks like Scrum. The more mature the team becomes the more they will and should adapt it to their needs. Anecdotally, many seem to start out with Scrum – maybe because it has clear rules – and end up going with a mix of Scrum and Kanban.

A cross functional team with full responsibility

It is very hard to be agile without having a team that has the full end-to-end (e2e) responsibility of what it is building. I realize that having a team with full e2e responsibility is rare and, depending on the business, difficult or impossible to achieve. Nevertheless, it is the most effective set up and the target state to strive for. 

The reasons for this are straightforward. Agile is about adapting to changing requirements. In case the team has e2e responsibility, this is easily done. The team can simply change their plan based on gathered feedback and implement it. 

In case the team doesn’t have e2e responsibility, they will need to align with other teams, which may have other priorities at that moment. Instead of easily changing the plan and delivering on that changed plan within a few weeks, it might take those weeks to align on the new plan and delivery will be within months.  

To be an e2e team you need cross functional team members. The team needs to be able to deal with the entire stack. You may need the competencies of data engineers, data analysts, backend and frontend developers, and designers in one team. It doesn’t have to be one person for each of these competencies. 

I am a big fan of the Pareto principle and the internet offers a lot of help. Therefore, I strongly believe that a motivated, competent team member can build 80% solutions in domains that are not his or her expertise. Much can be learned. I can certainly attest that it is possible for a Product Owner with no frontend experience to build an 80% website. 😉   

Making work visible

This is not included in the original manifesto but still so important and always present in successful (agile) teams: making the work visible. The standard of doing this is by using a board. Generally the tasks or user stories currently worked on and the status they are currently in are depicted.

Making the work visible is so crucial because, at the very least, it enables you to identify bottlenecks or blockers and allows you to react. It helps to explain to stakeholders why certain things cannot be done right now. Visualizing the work in progress is powerful and easy to implement. It is a feature of agile development that can (almost) always be applied outside of software as well.

Lastly, visualizing the work alleviates the burden from the individual to set up and maintain a system for managing their work. Since the board generally already includes a process for tasks to go through it is (most of the time) clear what needs to be done next. Seeing all the tickets means tasks are less likely forgotten. As such, making the work visible is essentially a basic system for self-management. (This is in general a topic that is criminally undervalued in my opinion!) 

It is not one size fits all

There is a lot more to agile development. To me, however, the four principles expanded on above are the most important in distinguishing this mindset from other, more traditional product development. These principles help guide me in my daily product development work. 

The good thing is that they do not prescribe the details of how to develop the product. They leave some flexibility in application. I am generally not a fan of dogmatically applying any sort of framework. You have to understand the situation you are in, try different approaches, and figure out what works in the given circumstance. For me, this is at the heart of agile product development.

In many situations in and outside of work it helps to keep an open or – dare I say – an agile mind.

Coverimage by Freepik