Being agile is the de facto standard in development today. If you ask development teams or tech companies if they are agile and using agile methodologies, in 99% of cases, you will get the answer – yes, we are doing agile. But if you dig deeper, you usually notice that they are focused on the procedures, ceremonies, and other less important things. They have forgotten the core principles of agile: being able to respond to changes and being obsessed with adding value for their customers.
If the velocity of the market is faster than the velocity of your company, you are dead.
Let’s step back for a second and focus on the key aspects of agile. What does being truly agile mean? It means how you respond to changes and how quickly you can change direction and implement feedback into your products, companies, and businesses. Speed is the essence, now more than ever. A few years ago, we lived in a time of lockdowns where every business needed to change and adjust to the new normal. All businesses, no matter how long they had existed, faced the risk of disappearing if they were unable to adjust. For some, this was impossible, but for most, it was a problem of not being agile enough in their processes, getting stuck with procedures, and slow responses to market needs.
199 companies from the S&P 500 mentioned AI in their first-quarter reports for this year – a historical remark for a new technology
The rise of AI is an even bigger challenge. You might not be aware of this or may be ignoring it, but AI is changing our entire industry at an unprecedented rate. In fact, 199 companies from the S&P 500 mentioned AI in their first-quarter reports for this year – a historical milestone for a new technology.
AI is changing every aspect of our lives, making many things possible and faster. If you are not adjusting and using it daily, you risk falling behind. Just a few years ago, you needed a team and several months to build a simple MVP to test your idea. Today, an average person with an AI assistant can create a simple MVP and a marketing plan in a matter of days. While the quality may not be the same, the value gained from the speed and ability to test ideas in the market far outpaces the perfect MVPs that tech teams build in months instead of weeks.
Even Darwin, a hundred years ago, explained agile in a simple way: you need to adapt to survive. Darwin’s theory underscores the importance of adaptability, iterative improvement, responsiveness, collaboration, and surviving competitive pressures—all of which are central to agile development.
You don’t need expensive consultants in their expensive suits; you need common sense!
It’s funny how agile has ended up being an expensive game of consultants. Think about it: you have people going around telling you how to build software. Most of them lack real-world experience and merely evangelize methods and books they’ve read while earning substantial money for it. This is why we end up with retrospectives where serious engineering teams are required to play games like “Three Little Pigs,” which measure energy levels, or my favorite—the “Kinder Surprise Retro” game, where you need to explain how a Kinder Surprise toy represents you in the current sprint. WTF?
”I’m sick of it. I can’t wait for the day when everyone realises how much of a fad-diet, religious-cult-inspired, money-making exercise it is for a group of consultants. I can’t wait for people to wake up to the fact that the only good parts of Agile are just basic common sense and don’t need a ‘manifesto’ or evangelists to support them.”
-the rant of Luke Halliwell some fifteen years ago
I fully agree with Luke and feel his pain. However, I do slightly disagree on one point: I think it is good that the Agile Manifesto was written. It is valuable to have it documented and to reflect on its principles. But the more you think about it, you realize that everything in it is common sense—focus on adding value for your customers, be able to respond to changes and prioritize working software over useless procedures. But the rest of Luke’s rant? I sign it 100%.
Have you noticed the rise of AI consultants training people to write ChatGPT prompts? Do you know you can ask ChatGPT to write them? I’m just asking.
Top-down vs. bottom-up! Stop being a heroic command giver, and start being a humble gardener.
One of the reasons we widely accept consulting services is because the management of mid and large companies can delegate responsibilities to them. The story typically goes like this: management realizes they need to change something, for example, becoming more agile (whatever that means to them). The next step is hiring consulting teams, paying them a lot of money, and then delegating everything top-down, ordering people to be agile from this point on. But you don’t build a house from the top down, right? The biggest problem here is that management delegates part of the responsibility while continuing to act as before, with no changes in their processes or mindset. You cannot implement agile as an order; you need to embed it as a core value of your company.
If you are an agency forcing your delivery/development teams to be agile but still selling your projects in non-agile ways, how can you call your company agile? How can you expect this to even work? Management needs to understand that agile is not a set of procedures and tools; it is a philosophy that must be embedded in the backbone of the company and implemented from the bottom up. If development teams are working in an agile way, the sales teams should adjust and sell in that way. Management needs to adjust and lead the company in the same way, sharing the same core values and obsession with adding value to the customers and company as the development teams. They should be on the same page and pursue the same goals. Listen to your people and use common sense more than expensive consultants with one-size-fits-all patterns, as there is no silver bullet solution.
Just a quick disclaimer: I don’t think you should avoid hiring consultants or providing training for your team. Just be mindful of who you are hiring and what they are selling to your team. Ensure they have some proper experience and are not just some crazy evangelists. Additionally, if you are part of top management, be involved and start implementing the same principles yourself.
Source: What is agile?
There is no plan; the plan is everything! The customer is king!
In the times we are living in, there is no concrete plan for the next three years. There is only the market and your customer. When I say there is no plan, I mean there is no fixed plan for what the next priority is, as priorities can change daily or weekly. Of course, you will have goals and plans for what you want to achieve in the next few months, years, and decades, but these must be adaptable. You need constant feedback from your data and your customers.
In today’s competitive markets, customers have many choices and alternatives for any product. They expect instant, frictionless, and intimate responsiveness at scale. If you are not delivering this, someone else will, and your customers will go to the competition. It is literally a listen, adjust, deliver, or die situation. This is common sense; you also act this way with products you use, so don’t be surprised by your customers’ expectations.
Remember the top-down problem with management? Usually, feedback from customers comes from the bottom up. If management does not accept this feedback and treats “the customer is king” as just a phrase, you can see why such an organization cannot be called agile.
When I said there is no plan, I meant the plan is everything. This is your backlog. At any point in time, your backlog needs to be updated with the highest priorities. Every single thing, including priority, can be changed at any point with a focus on adding value for the customers. If you achieve this, you have taken a great step toward calling yourself an agile organization.
Your product owner is a superhero!
The book “The age of agile” by Steve Denning illustrates how smart companies are transforming the way work gets done in the modern world using agile. If we sum up the book, we see that agile operates under three laws:
1. The Law of the Small Team
Big and difficult problems should be disaggregated into small batches and performed by small cross-functional teams working iteratively in short cycles and in a state of flow, with fast feedback from customers and end users.
The Law of the Small Team from “The Age of Agile” emphasizes the effectiveness of small, cross-functional teams that work in short, iterative cycles. These teams have the autonomy to make decisions and quickly adapt to changes, promoting innovation and faster delivery of value to customers. Small teams foster closer collaboration, better communication, and increased accountability, leading to higher productivity and more effective problem-solving.
2. The Law of the Customer
An obsession with delivering value to customers as the be-all and end-all of the organization.“
The Law of the Customer highlights the importance of prioritizing customer needs and feedback in the development process. Organizations should focus on delivering continuous value to customers through iterative improvements and close engagement. By actively listening to customers and rapidly responding to their evolving needs, businesses can build stronger relationships, increase customer satisfaction, and drive long-term success. This customer-centric approach ensures that the products and services offered are aligned with what customers truly want and need.
3. The Law of the Network
A continuing effort to obliterate bureaucracy and top-down hierarchy so that the firm operates as an interacting network of teams, all focused on working together to deliver increasing value to customers.“
The Law of the Network stresses the importance of fostering a network of empowered teams within an organization. Instead of rigid hierarchies, companies should create flexible, decentralized networks that encourage collaboration and information sharing across all levels. This networked structure enables faster decision-making, greater innovation, and a more adaptive and resilient organization. By leveraging the collective intelligence and capabilities of the entire network, companies can respond more effectively to changes in the market and continuously improve their performance.
Source: How to build a strategy in agile environment
As you can see, all of these three laws from “The Age of Agile” focus on a simpler organization with bigger output/value for the customers. Again, common sense. But in practice, not everyone is aware of this. This should be accepted by all people involved in the project, including investors and stakeholders. For example, if you have an investor who has put money into your project, they are expecting some returns in the future (don’t tell anyone, but this is how the world works). I will tell you one more secret: even if you are a consulting/development agency, your client’s customers are kings – you need to listen to them as they are paying money to your client/stakeholder, which they are using to pay you. Again, common sense, but usually this is not how it works and not how stakeholders understand it.
To be obsessed with your customers, you need a superhero on your team. While superheroes may not be real, we have heroes in the form of Product Owners. When developing a product, the Product Owner needs to be fully in charge. What does this mean? It means that the Product Owner must have full control over the product, backlog, plans, and more. They need to be in touch with customers and, more importantly, have the courage and ability to say no to stakeholders, CEOs, bosses, etc. I know this is almost impossible, but this is what we need for great products: great people with more freedom and responsibility. Most importantly, the Product Owner is responsible for the product. They are the connection between stakeholders, the development team, the marketing team, the sales team, and the customer, and they need to perform at the highest level.
A Product Owner is not a Project Manager.
Often, these roles are conflated or assigned to the same person. This is completely wrong. I read a good comparison on LinkedIn, so I will use it here.
A Project Manager is like a band that comes to play for 3 hours and will get paid for it. The Project Manager prepares the list of songs that fit the budget and 3-hour session. The Project Manager ensures that everything goes well and stops the band after 3 hours.
A Product Owner, on the other hand, starts watching the crowd as soon as the band begins to play. The Product Owner’s only focus is to keep the crowd dancing as long as possible and to ensure they have fun. If a set of songs or a genre is not working, the Product Owner adjusts and changes, implementing feedback.
You see the difference here: the Project Manager is in an execution role, while the Product Owner needs to know their “crowd.” They need to find what fits their “crowd” and make them “happy and cheerful.” It is not an executional role; it is a key role. To do this, the Product Owner must take a significant role in understanding the business and all roles within it. If you want to know more, read Ana’s blog post.
You can be agile (even) if you are using a waterfall.
First, let’s clarify something – there is no “right way” or “best way” to build software. There are guidelines that can help increase your chances of success, but the reality is that around 70% of projects fail. The only way to build good software is by adapting theory to fit the needs of the customer, budget, codebase, team, tools, and organization.
Even within the same organization, different teams can perform differently using the same procedures and workflows. In the end, do you really think your customers (kings) care what methodology you are using to deliver value to them? Do they care about the technology stack you are using? No, and no. They only care about their need at the moment. If they want to send a picture via chat, they want to do it quickly and now – that is the only thing they care about.
The only way to build good software is by adopting theory to fit the need of the customer, budget, codebase, team, tools and organisation.
Usually, I hear, “we need Scrum to be agile.” This is nonsense on so many levels. First, if you implement Scrum without an agile mindset, you will get stuck in countless meetings and ceremonies, and your teams will soon be frustrated, complaining that they don’t have time to work and are doing too many meetings (sounds familiar?). Scrum is the most popular framework, and when you start learning about agile methodologies, you will often end up trying Scrum. You will hire trainers, and consultants, read books, and try to do everything by the book and the rules of Scrum, but it will probably not work. The problem is not that Scrum isn’t working; the problem is that you didn’t implement agile in your core values and focused too much on the Scrum procedures.
Remember, Scrum is a framework. And what do we do with frameworks? We adjust them to our needs. Yes, we make compromises to fit the team and project we have, aiming to build the best possible product. Hopefully, you will not end up playing “funny” games with adults who just need to provide feedback on what was good, what was bad, and how to improve. In the end, you can invent your own methodology and call it “deliverscumic.” If it allows you to deliver value, quickly respond to changes, and keep your customers happy, then from my point of view, you are doing agile well.
Some projects need to be waterfall. Let’s move from IT for a second and consider another example: building a house. If you are building a house, you know that this is one of the most agile projects you will ever work on, but it must follow a waterfall approach. First, you need to find the land, then buy it, do the legal work, and get all the necessary permissions. Next, you create the entire project and blueprints (wireframes 😊). Once this is complete, you can start building, then choose your furniture and buy everything. It is clearly a waterfall process, but each of these phases requires significant agility.
This can be a multi-year project where changes in market prices can affect the entire investment, necessitating quick adjustments. When construction begins, unexpected problems often arise, requiring immediate decisions on how to fix them. Don’t tell me you need a good architect who can predict everything—there is no single architect in the world, whether in building or in software, who can predict and solve all problems upfront. You see where I am going: this is a clear waterfall project, but each phase within it is chaotic and requires agility.
Deliver MVP to the market asap!
Back to IT projects and products: if you are starting a new project (like building a new house) and don’t have any data or feedback from customers, it makes sense to implement a waterfall approach at the beginning. Initially, you need to make some assumptions about the market, conduct discovery workshops, and define the product idea. This phase is also an opportunity to conduct customer interviews, gather feedback, and begin incorporating agility. The result of the discovery workshop might be that your product is not needed in the market, and that’s perfectly okay—you’ve saved a lot of money on development. On the other hand, if there is a market fit, the result should be a clear roadmap to the MVP.
An MVP should not be a sloppy project that barely works and is rushed into production to meet deadlines. Developing an MVP forces teams to focus on the core value proposition of the product. By identifying and delivering the most critical features first, teams ensure that the product addresses the primary problem it is intended to solve. This focus can lead to a more coherent and user-centric product.
By getting a working product into the hands of users quickly, teams can gather valuable feedback and learn about user needs and preferences. This feedback loop helps in making informed decisions and prioritizing future development—allowing teams to get feedback, adapt, and add value for the customers.
Agile development emphasizes adaptability and responsiveness to change. An MVP aligns with this principle by allowing teams to iterate and improve the product based on real-world usage and feedback. This iterative approach ensures that the product evolves in a direction that is aligned with user needs and market conditions.
An MVP is important in agile development because it enables rapid learning, reduces risk, ensures cost efficiency, accelerates time to market, promotes flexibility, engages stakeholders, and focuses on delivering core value. These benefits align with the agile principles of iterative development, responsiveness to change, and delivering value to customers. Once you release your MVP to production and start gathering feedback and data, that is likely the exact point where a waterfall approach no longer makes sense.
There is no one-size-fits-all approach for companies
As there is no single company, project, or situation that is the same, even if two different teams work on the same project with the same methodology, the outcome can be different. Based on our experiences, we know that some things work better and some things work less effectively in certain situations.
For example, if you have a fixed budget, fixed deadline, and fixed scope, it makes no sense to try to do agile. This is a project (if such a project even exists) where everything should be written in stone, and no changes should be made. In such cases, agile is not the appropriate approach.
Based on our experiences, different project methodologies should be applied depending on the situation. You will not use Scrum for a simple MVP. Typically, if you are building a new project, you might start with a waterfall approach but transition to Scrum or something more agile as soon as things become complicated and plans start changing more frequently. Additionally, if you are taking over a project that is in total chaos, Kanban will likely give you better and quicker results compared to Scrum.
The same applies to your business; there is no simple solution or silver bullet that will transform your business into an agile company. You need to work on this every day, with a focus on adding value by listening to your customers and their feedback. It is crucial to involve your project team in the acquisition phase as early as possible (law of the network). This will allow you to detect low-effort features with great value for the customers, providing some easy wins for you.
Be agile with agile, and don’t be a slave to any framework or methodology!
Breaking the rules and experimenting with new approaches is also an important part of being agile. Don’t be constrained by the book rules, as they usually will not work exactly as written but can provide some good ideas. Start with new ideas, do retrospectives often, and try to fix what is not working for you. In a few cycles, you will adjust the framework and process to fit your needs and create something that works for you. This is crucial: you need to figure out what works for you and your project, enabling you to adjust to requirements and changes easily.
Be agile with agile, and don’t be a slave to any framework or methodology!
