95%
Meeting time
90%
estimation
80%
Lead time
70%
Bugs
How turning work into play turned the ship around.
Read how a team building a prop-tech startup turned around the fast failing project in as little as 3 months. Adding play took them from being stressed and working throughout the night, most nights, to relaxed and ahead of schedule.
The end result?
Higher quality software that better met user needs and a big saving in design and development cost for the customer.
The journey
From a stressed and overworked to a relaxed and hyper-productive team in 3 months.
get direction
Establish a baseline and orient yourself in terms of where you are in relation to the goal. Main outcomes:
set goals
Agree on priorities and get buy-in from all the stakeholders. Main outcomes:
calibrate
Time to "chase the bottleneck", which involved spending time with individuals to gain an in-depth understanding of the challenges holding them back. Outcomes included:
play
The final phase added a more playful way of verification and validation. Work was on track, the team was relaxed, and there was time to play. Main outcomes:
What was the problem?
When I joined a team approximately two weeks before the planned soft launch of a web application for a property technology startup rewarding tenants for good behavior there was nothing concrete to show after nearly a year of development. With time and funding running out fast, drastic change were needed.
With small, continuous and intentional changes, and an inclusive approach to decision making, we embarked on a journey to reduce organizational- and technical debt, ultimately turning work into play to boost productivity and collaboration.
Hypothesese
The main hypothesis was that if meeting time can be reduced to 15 minutes, team communication would improve. This proved to be true with the quality of the work as well as the speed of delivery improving as the meeting time decreased.
Another hypothesis was that quality increases when teams are cross-functional and included in design, development, and testing, with the law of two feet allowing anyone to join or leave a meeting when they feel they're not contributing or learning. The quality of the product and the underlying architecture radically increased as cross-functional roles were included in the process.
"Your contribution turned the ship in the right direction."
- Development Lead
Deciding where to start
When one embarks on an adventure to conquer a mountain peak, the first step is to get a map of the territory and study it. Our first step, similarly, was to visualize the work and do a reality check, explicitly highlighting boundaries, relationships, responsibilities, and statusy.
A contextual systems map with key process flows were physically put up on a wall for everyone to see and a large database entity relationship diagram - the heart and soul of any system - was printed out and added right next to the developers to enable conversations to clarify unknowns. Sketching out the rest of the architecture on a wall enabled us to have a complete map of the territory we're dealing with, showing what's in our control and where the integration points lie.
Gaps and duplicate work due to misunderstandings were systematically eliminated and optimistic status reports of what's planned and in progress was replaced with a more pessimistic, but realistic actual status. Either it was working software a user can interact with via a front-end, or it wasn't done. No buts, no justifications, no excuses.
What is the priority?
With many balls in the air at any moment and everything seemingly as important as the next, the next step was to agree on a realistic goal to prioritize. Taking an outcomes based perspective, we agreed to prioritize a full-circle basic transation for only the most used case - a normal tenant renting from an owner via an agent with a standard lease agreement. No snags, no early cancellations, no direct renting from the owner.
While all the other features and use cases were equally important, we zoomed into the simplest end-to-end workflow first, logically working through the features from start to finish until the entire workflow was completed.
Make micro changes
People mostly resist change for one of two reasons. Firstly because they weren't included in the decision making process. Secondly because it requires etxra effort by already overworked and stressed people.
But what if you made the changes so small that no-one noticed?
The next phase of the process was to continuously make micro changes towards a desired outcome. For example, weekly progress meetings started off at close to an hour and a half, with the goal of having it a maximum of 15 minutes. Each progress meeting the aim was to finish just 5 minutes earlier than the previous one until finally we achieved our goal.
The importance of face-to-face communication
Once the meeting length was more manageable we introduced daily stand-ups and placed emphasis on reporting to each other rather than me as project lead. I merely facilitated the meetings to ensure everyone was working on the top priority items, is unblocked, and are talking to each other, instilling a self-managed culture with the goal of making my role obsolete.
Other key changes were the facilitation of face-to-face meetings with third party system owners to resolve issues and bugs and standardizing a daily check-in with the designers to give early feedback on design-related questions.
Whole-team validation
To ensure collaboration and buy-in from the entire team, cross-functional role-playing validation workshops were introduced. These workshops were key to agree on release readiness and improved the motivation for the team to resolve outstanding bugs.
"What really makes Kate stand out is the way she brings everyone together."
- Senior Development
What's holding you back?
While we were building the end-to-end workflow we embarked on the bulk of the hard work, streamlining processes and tools to support and enable rather than impede and slow down. Tools were cleaned up to get rid of confusing, duplicate, or missing data. The teams agreed on a single source of truth as well as a process to obtain missing assets and requirements, reducing the need to update assets in at least three different locations each time there was a change.
Another key focus area at this stage of the transformational journey was to identify individual team member's strengths and weaknesses and ensure each person was focused on what they're best skilled to do, and had the necessary support to unblock them when they were stuck.
Ready to go!
Finally, after what felt like forever, we were ready to launch with near-zero bugs, This was a good time to look back over the past three months to see what we've achieved. Collaborative style, I interviewed each team member to collect their lessons learned and compiled a report that served as snapshot of progress as well as library of lessons learned to be used as input into the next iteration.
Of, course, all work and no play made Jack a dull boy. From the start we prioritized relationships and ensured we spent time together after hours (or during office hours) relaxing and getting to know each other. One developer faciliated daily exercises outside, while Fridays we enjoyed a beer or glass of wine with the occassional weekend outing. We also included time for a well deserved end-of-the-year party and holiday to rest.
Ready to take the first step?
Book a free, no obligation discovery call to start the conversation.
Start the conversationLet's play!
Fill out the form to take the first step towards a stress-free team.