Simplicity — the art of maximizing the amount of work not done — is essential.

8 min readSep 21, 2023

[ Agile Manifesto — Principle 10 ]

Hey fellow Agilistas, with this article we dive into the heart of the 10th principle of the Agile Manifesto with you: “Simplicity — the art of maximizing the amount of work not done — is essential.”

(Some teams seem to misinterpret that and maximize the amount of work “not done” — we’ll talk about this phenomenon and how to avoid it another time.)

The art of simplicity isn’t about taking shortcuts but about finding the most efficient path to delivering value.

Why does it matter?

This approach reduces unnecessary complexity, which can lead to delays, increased development costs, and potential defects. Complex solutions that introduce unnecessary features or convoluted code can lead to inefficiencies. They may require more time and effort to develop, test, and maintain. Moreover, complex systems are often harder to understand, increasing the risk of errors and making it challenging for new team members to onboard. And you probably end up piling up technical debt “et voilà!” — you are pretty much stalled.

When you think beyond team boundaries, think of what an unnecessary complex solution or product means for the support organization and your end users. Not only will the product be hard to support and train to end users but in case of urgently needed fixes — how fast and efficient will you be to deliver them to your end users? Seems everybody is frustrated.

But it doesn’t have to be this way! Simplicity enhances maintainability, making it easier to adapt to changing requirements and fix issues when they arise.

We’ll explore this principle from different role perspectives: how does this apply to a Product Owner, a Scrum Master or the Developers?

So grab your favorite beverage, get comfy, and let’s simplify things together. ☕

The Product Owner’s Perspective

Imagine you’re a Product Owner — the bridge between your stakeholders and your Agile team. Simplicity is your guiding star.

Continuous Product Backlog Refinement: Keep your Product Backlog tidy and declutter it regularly. Think of it as Marie Kondo-ing your product backlog — keep only what sparks joy for your customers. Eliminate items that no longer provide value or are no longer aligned with the project’s goals. This ongoing process of refinement keeps the Backlog lean and focused.
Prioritization for Value: Simplicity encourages you to prioritize features that provide the most value to the end-users. By focusing on what truly matters, you can ensure that every Sprint delivers meaningful results.
Lean Software Development: In Lean principles, the elimination of waste is a key focus. By prioritizing features that genuinely benefit users, you’re effectively reducing unnecessary work.

“A user story is a promise for a conversation.” — Alistair Cockburn.

User Stories: With Alistair Cockburn’s quote in mind, make sure there is enough room for conversation with the Developers. When creating user stories keep them concise and straightforward. Avoid unnecessary details and complexities, focusing on delivering the core value to the end-users. A user story is not a comprehensive specification, but opens space for elegant solutions and innovation.
Acceptance Criteria: Ensure that the acceptance criteria for user stories are clear and to the point. This prevents ambiguity as well as the unnecessary addition of features that don’t align with the user’s needs.
Avoiding Scope Creep: In Agile, scope changes are inevitable. However, simplicity acts as a shield against scope creep. It compels you to say “no” to non-essential features, helping to maintain a clear vision and avoid project bloat. Do not overwhelm yourself and your Developers with 500+ Product Backlog Items. Is there a swamp at the bottom of your Product Backlog where items are left to degrade?
User Feedback: When collecting user feedback, as a Product Owner you should aim for simplicity in the feedback-gathering process. Avoid overly complicated surveys or forms and focus on gathering actionable insights that are easy for users to provide.

The Scrum Master’s Perspective

Looking at the world as Scrum Master, what does this principle mean to you?

Lyssa Adkins writes in her book “Coaching Agile Teams”:

“A Scrum Master should facilitate by creating a ‘container’ for the team to fill up with their ideas and innovations. The container, often a set of agenda questions or some other lightweight (and flexible) structure, gives the team just enough of a frame to stay on their purpose and promotes an environment for richer interaction, a place where fantastic ideas can be heard. The coach creates the container; the team creates the content.”

Simplify people’s ability to interact: In this context, I want to highlight the “lightweight and flexible structure” to you. Keep it simple. Being an Agile Coach, I often find myself putting a ton of effort into (very!) nice-looking Miro boards when preparing retrospectives or workshops. In retrospect, this effort could have gone into more meaningful work. Oftentimes, an instant Lean Coffee (haha, love that) will do the trick just as well.
K.I.S.S. principle: Encourage your team members to adhere to the KISS (Keep It Simple, Stupid) principle. Avoid overcomplicating processes or meetings. Simplicity keeps everyone focused on the task at hand.

Real-life example: I had a team that -with best intentions- drafted a PO-review process that would allow for the PO to give feedback on user stories as soon as they were done. They ended up with a three additional columns on their Scrum board (ready for PO, in review by PO, accepted by PO) and a document describing on who is responsible for notifying the PO in case a user story is ready, who is responsible if the first responsible person is not available (e.g. on sick-leave), how many days before the Sprint Review they are willing to wait for feedback from the PO (yes, there was a formula involved), who will substitute for the PO in case of absences, etc.

What happened was that they had to consult their document to determine who is going to do the next step. Not long after, the team decided to forget about their elaborate process and simply take any new information about a user story to the Daily Scrum.

(I know what you are thinking, but back then they felt they needed it).

As a more advanced Scrum Master, you might also already work with the organization to become more agile. Think of other teams in the organization your team interacts with, e.g. the Support team, Marketing, Documentation etc. Have you over-bloated processes to interact with them? What do you really need/expect/wish from each other? Find it out and come up with a sufficient solution — not the “we-have-thought-of-100-edge-cases-as-well”-process. YAGNI — you ain’t going to need it.

Bonus: your team and the other team(s) will get to know and develop empathy for each other which will make all your lifes easier.

The Developers’ Point of View

Developers, listen up!

No cutting corners: Simplicity isn’t about cutting corners but finding elegant solutions. It’s about crafting clean, maintainable code. Simplicity in software architecture and design translates into smoother development workflows and less rework, reducing waste.
Avoiding Over-Engineering: Make technical decisions that align with the current needs of the project. Avoid over-engineering by not building complex solutions for problems that have not yet arisen. Focus on what matters right now and do not build code because you expect it to be useful in the near or far future. This is a trap I have seen many developers fall into. And it’s a discussion in every other team I’ve been part of. In Sprint Planning, a Developer comes up with the idea to develop code that can handle more cases than the current one at the table. And though it’s more effort now, he claims it will pay off once the Product Owner decides to have the other cases implemented. I can see why you want to do this, but I would refrain from doing so, because: Any code that is written will have to be maintained. Code that is written but not used is waste.
Beware of Feature Creep: you can extend the previous example to build features that go beyond the initial basic functionality. Instead of building what would have been sufficient, features are ‘enriched’ with functionality and thus also with unnecessary complexity.

“The state of perfection is not when there is nothing more to add, but when there is nothing left to take away” — Antoine de Saint-Exupéry.

Code Refactoring: Continuously refactor code to eliminate unnecessary complexity and technical debt. This ensures that the codebase remains clean, maintainable, and straightforward, reducing the risk of introducing complications in the future. Complex solutions often lead to more significant challenges when issues arise. In contrast, simple (clean) code is easier to debug and fix, saving valuable development time.
Test-Driven Development (TDD): Follow TDD practices to develop only the necessary code required to pass tests. This approach promotes simplicity by preventing the addition of extraneous code and features that are not directly related to user requirements.
Sprint Goal: Use your (well defined) Sprint Goal as your guiding star to determine whether or not a task brings you towards the Sprint Goal or not. If not, why do you spend time on it?
The UI Development Angle: User Interface (UI) development plays a vital role in delivering a great user experience. Simplicity here means designing intuitive interfaces that users can navigate effortlessly. Steve Jobs once said, “It takes a lot of hard work to make something simple.” It’s about distilling complexity into user-friendly interfaces. Have you ever worked on an off-the-shelf software where there were tons of options and buttons that could be linked back to specific customer requests that most other customers would have no use for? I certainly did…

Summing It All Up

Simplicity is about maximizing value while minimizing waste.

Let’s remember these key takeaways:

Product Owners: Prioritize features that spark joy for users, aligning with Lean’s waste reduction principle.
Scrum Masters: Embrace simplicity in processes and meetings, keeping the team focused and encourage them to adhere to the K.I.S.S. principle throughout their work.
Developers: Craft clean, maintainable code and elegant solutions that reduce rework and avoid waste. Design intuitive interfaces that simplify user experiences and add value to your product.

Remember, the art of simplicity isn’t about taking shortcuts but about finding the most efficient path to delivering value. As we continue our Agile journey, let’s embrace simplicity as our trusted companion, guiding us toward excellence in software development. It allows teams to focus on what truly matters to users, avoid unnecessary work, reduce waste, and deliver high-quality software more quickly and effectively.

Simple solutions allow us to get to “done” sooner. This allows us to get feedback sooner. And this is what we’re after, right?