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!…