#4 :: The Four Laws of Simplicity and How to Apply Them to a Team Retrospective

A few months ago i’ve read an interesting post from Leo Babauta (zen habits)  where he described a simply method that could be used as a guide to simplify any area of our life! The steps he mentioned were:

collect everything in one place
choose the essential
eliminate the rest
organize the remaining stuff neatly and nicely

Inspired by that simple method and the way it could be used, form things related to our daily routine up to our own life, i was thinking that this method could help teams as well to simplify their working life!

Working with teams for a few years and considering the changes “agile” has brought to our organization, it was obvious that there were many things each new team should  handle! New responsibilities, new expectations, new processes were just a few areas that they should take care!

My experience has shown that it is impossible to handle all that stuff at once, even if sometimes there is some pressure to have everything in place as from the beginning! You need to focus on those items that return the most value back to your team and your organization and then work on the rest!

Confucious once said that

Life is really simple, but we insist on making it complicated

Based on that belief, my hypothesis was that “agile could be really simple, if we do not insist on making it complicated”! To experiment with my hypothesis i’ve used the “Four Laws of Simplicity” during a team’s retrospective. The steps are described below.


In that phase each team member thought about everything that was related to our way of working. From practices, processes, methods, agreements, responsibilities, expectations e.t.c. There was nothing right or wrong! All notes were gathered in one box that was finally turned upside down! We continued with grouping of the common items and create a few more general themes where possible. As an example a few items are listed below

solution testing, testing on target, US preparation, US selection-sprint planning, demos, stand-up, retros, taks splitting, code quality, e2e teams, collaboration, communication, commitment, feedback, openness, initiatives, self-improvement, adapt to changes e.t.c


We then chose the “essential” items! The items that could return the most value to the team or items that could have long term benefits. We discussed on notes and themes, and we used dot-voting as a technique to reach consensus and to prioritize our pool of items!


Team decided that there was no need to eliminate any item! Every item had its own value, so everything was kept for future reference.


As mentioned above dot-voting helped the whole process  to come up with a prioritized list of items. We further agreed that there was no need to work directly on the most voted items! For that reason we added two more parameters in our decision to prioritize the list of identified items. The value that will return a specific item and the effort required! The outcome of this exercise was the creation of a “prioritized” improvement backlog including items that the team would like to keep, “tweak” and further explore!

As an example, the team decided to work on “code quality”. Worth to mention that all team members were really satisfied of the quality they produce but they were willing to further challenge their “local optimum”! A couple of actions they came up: re-activate improvement list (add items related to legacy code improvement & bring them to architecture meetings) and introduce the concept of “re-factoring US” as soon as an EPIC had been implemented.


based on the feedback i received, team really enjoyed that method! we spend almost two fully productive hours!

In my opinion team managed to express and visualize their personal thinking related to their work, reach consensus and focus on those items that could help them to get improved and could return the most value back to them and their operations! It was a start that requires effort and discipline to grow a mindset of little constant improvements!

What i would change based on the feedback i’ve received…i would introduce an estimated technique to estimate the “value” of the chosen items! it might help teams to understand the “value” of estimation as well!…and why not invite team’s group leaders/line management and PdOs to express their own thinking and contribute from their sides on the improvement board!…


inspirational reading

4 Laws of Simplicity and How to Apply Them to Life


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

I Manage Products


Assess your Agility - BETA

A framework to evaluate and improve your organization's agility

Lean Adaptive Leadership

Transforming technology organisations using lean and adaptive principles.

Agile, Lean, Kanban, and System Thinking

Agile, Lean, Kanban, and System Thinking

Control Your Chaos

That Scrum Girl on everything Scrum, Agile and Lean

The Product Owner Framework - BETA

Evaluate your skills and identify areas for growth

Digital Business Transformation

Inviting you to explore the world of Digital Business

Agile For Startups

Tools and Techniques for Tech - Startups .

Escape The Local Optimum

jump out of any local optimums by iterating, evaluating, accepting, memorising and restarting

Software Process and Measurement

Software Process Improvement and Measurement - Oh My!

Dave Nicolette

Effective software development and delivery

Arialdo Martini

Random notes about software

Agile By Culture

Doing Agile means being Agile


Thoughts on software, code, philosophy and games

InnerActive Leadership

Partnering with you to find insights that lead to results!

Agile, Data, APIs, startups and more

Everything I find out about Agile, Data, Big Data, Data Science, APIs and of course Startups.

quantum shifting

think bigger, go further

Benjamin Mitchell's Blog

Helping IT teams & their managers deliver great software solutions

Diary of a ScrumMaster

Finding a path to a new way of working

An Ethical Island

How to Teach Without a Lecture and other fun

Mike Cohn's Blog - Succeeding With Agile

jump out of any local optimums by iterating, evaluating, accepting, memorising and restarting

Jim Highsmith

jump out of any local optimums by iterating, evaluating, accepting, memorising and restarting


jump out of any local optimums by iterating, evaluating, accepting, memorising and restarting

%d bloggers like this: