The Easter-egg challenge

Step out of your comfort zone of technical discussions, data analysis and user story writing, and step into the world of easter egg painting. Together with the Product Owners, Product managers and Technical team leads, we focussed today on something different, that in the end, influences everything we do and stand for.

A challenge, inspired by this article, that on first sight looks fun and irrelevant, represents in many ways how teams operate, and how that is impacting their productivity. While painting eggs, cutting them out, checking the quality of the delivered product seems extremely easy, the reality shows that even supposedly easy tasks can become difficult and hectic when the participant’s mindset is not right.

The challenge is simple:

• Groups of 4 or 5 individuals per team
• A bunch of papers with unpainted easter eggs on them
• Several boxes of crayons and a some scissors
• Requirements from the business (preferably difficult to understand)

During the challenge the teams will be instructed to deliver the painted eggs according to the pre-defined requirements, on time, on quality and on budget (let’s just imagine there was a budget). The team will get 2 attempts in which 2 different delivery approaches will be used, where the first is based on Waterfall, and the second simulates a more Agile approach.

While the core learnings of the challenge can be found in that an Agile mindset helps you improve productivity (spoiler alert!), the challenge also shows the participants other relevant daily work problems that, if not responded to well, can seriously impact your product delivery.

3,2,1, GO!

Start planning your work, appoint who paints, who has the best scissoring skills and who is responsible for Quality Assurance. The teams have 3 minutes to decide who does what. Simulating the first phase of development using a waterfall approach, in which you would write all requirements, and create the documentation for the entire project.

Then it’s time to start painting, which is a 6 minute job. No iterations, just start doing your job, and deliver the project all at once after the time passes. After all, all requirements are known, and the planning has been created to complete the task in time, on quality and on budget. When after 3 minutes business requirements are suddenly changed — let’s say the government has just banned the color blue — you can observe the team getting stressed out. As a result we find many eggs thrown in the garbage bin, and the team starts all over again.

As there is no time for evaluation during the project, the teams finish with only a few eggs completed. A bit disappointed about the sudden requirement change, the teams somehow aren’t quite satisfied. Nor is the Business, as the delivered quantity is far below budgeted, and the Sales teams will have some difficult calls to make. The remaining 3 minutes of the challenge are mostly used for discussing what went wrong, pointing most fingers towards the business.

Let’s iterate!

The teams get a second chance, but are now expected to iterate. In a more agile environment, teams are used to deliver smaller chunks of work in small iterations allowing them to reflect, adapt and improve each iteration. The teams are given the same tools, but now they are free to do the work they think is required to get the job done. No fixed roles, just like a real agile development team.

Where in the first round the team was given 3 min to prepare, 6 min to work, and 3 min to evaluate, the teams now get 3 rounds of respective 1,2 and 1 minutes to get the job done in 3 iterations, using the same 12 minutes. Giving the team less initial time do the planning, results in a bit of chaos. But it’s controlled. The team knows what they are doing, and get a bit of work done in the first sprint. There are products delivered according to the specifications, and after the 2 minutes of painting, the team takes 1 minute to evaluate the product increment and the team’s processes during the worlds shortest Sprint Retrospective.

2 more iterations follow in which the requirements change as well— The government also suddenly requires an additional quality label to be added to the product — This time, the teams are able to respond properly, and discuss the requirement change in either the retrospective or during the next sprint planning. Despite the sudden change, the teams are able to deliver more eggs, and realized that working in iterations provides them quite some benefits that they took for granted or never knew existed.

• Responding to change effectively can only be achieved by occasionally taking the time to evaluate your processes
• Requirements can change, and its better to plan for that than to hope it won’t happen
• Delivering every now and then is more satisfying for the team than having 1 big delivery.
• Productivity goes up if you take time to evaluate your team’s performance and processes

The hidden challenge

while the changing business requirements were the obvious problem, it was not the only one. When starting to work while the requirements are not 100% clear, the team and delivery gets seriously impacted when you find yourself implementing something in a different way than the stakeholders were expecting. Talking to your stakeholders (That would be us in this case) could clear out missing or unclear requirements. Using the planning phase to groom all requirements, ensuring they are clear for all team members, will result in a better productivity, and a higher product quality.

surprisingly, not everybody took the opportunity to talk to the stakeholders while the 3 min planning session was happening, resulting in some of the eggs getting rejected, simply because they did not meet the pre-defined (slightly unclear) requirements, set by the business stakeholders.

And the winner is?

Let’s not discuss the actual numbers of eggs that were delivered and approved for shipment to the clients. The most important finding is that using an agile delivery method resulted in up to 7 times better productivity for some of the teams. While all teams delivered beautiful eggs, the team’s motivation, productivity and quality significantly improved.

Working in a more Agile way — and more importantly, with an agile mindset — enabled the team to respond to change, optimize the process and improve productivity. And in the end the motivation went up. The team completed the workshop with a good feeling, understanding the benefits of an Agile mindset, and hopefully being able to help their teams to become better in what they do every day!

A big thanks to Radosław Scheller and Christian Kemsies for leading/assisting this fun challenge!