How to make Agile Candy

A step-by-step guide on bringing agile ways of working to a candy company in South East Asia

I was part of a consulting engagement to bring Agile ways of working to a candy manufacturer in South East Asia — It was my first time working in the candy industry and my first gig since I moved to this part of the world just a few months ago. So so exciting.

In this article I discuss the beginning of a client’s journey towards adopting Agile product development. It might be useful for Agile coaches, Scrum Masters or anyone curious to know about bringing Agile to a context not driven by software delivery.

The Challenge

A young candy making manufacturer approached us with the goal of implementing Agile ways of working in their product development team.

Bringing new candy products to the ASEAN market at a steady and predictable pace had been a pain in the neck for quite some time.

In an effort to take control, some product managers designed their own home-grown processes, but they did not manage to implement them. They tried to make Waterfall happen too, but it seemed to slow things down even more.

On this last attempt, our client was determined to give Agile a try — Scrum in particular. A lot goes on your mind when someone says they want Scrum that forthrightly. The situation called for a deeper understanding of how candy was made.

Our Approach: The Double Candy

We would have not been in our right minds if we just came in, implemented Scrum and left. Designing a good solution was non-linear and iterative. Trying to make sense of it all in retrospect, the approach was something like this.

1. Discover

After a number of stakeholder interviews, meetings and observing where the work happens, we started to build a picture of the scenario at hand:

The atmosphere overall was fantastic. People were open, motivated, curious and willing to learn. The organization was receptive to new methodologies and there was little fear of change.

The company strategy zeroed in on entering new markets aggressively and launching as many new products as possible. So far, the first part of their strategy was coming to fruition — The company was growing aggressively and their revenues looked excellent for a new contender who had only been in the market for 4 years.

This was a great accomplishment for a small organization of around 100 people with an average age of 28 years old. The majority of the employees were gross of these were factory operators and field salesmen. As an organization in startup mode, it was easy to notice challenges that usually come with fast growth.

On the organisational side, we observed a combination of broadly-defined roles with people who were rather new to their jobs. Some Product Managers had less than 6 months of experience and never held a similar role in the past. Product Developers were ideating, prototyping, ensuring quality and even helping out with production issues. Employee turnover was also relatively high which constantly eroded institutional knowledge.

All teams were set up around functions, and product management was enclosed in a function within a function. Work tended to be ‘thrown over the fence’ and there were no clear process owners.

Now we had a sound line of thought that explained why previous efforts to control product development did not work as : In this scenario, it is challenging to have roles that are 100% dedicated to standardising processes and creating communication mechanisms that cut across functions. The organization designed forced work to happen through informal networks and very few things were formalised.

These dynamics were also reflected in the financials. Elevated admin and raw material costs pointed out sources of inefficiency that affected profitability.

Most of the measuring efforts were put on macro lagging indicators ( Revenue and gross product portfolio margin ). Not a bad thing in itself, but the product development cycle was quite long (9–16 months) and it took months to get feedback from the market. There was no formalised measurement of leading indicators.

2. Define the Scope

After having a better feel for the business and the organization, our next goal was to create shared understanding of how product development actually happened, and what were the key pain points that needed to be solved for.

High level process view of product development and marketing

1. Idea

Everything starts with an idea incepted by someone in the organization. Product managers came up with ideas. But product developers in the Knowledge Creation team also came up with ideas. And senior execs too. There was no standardised approach to validation that involved customers from the very beginning. After that, the work would split into a Product Development flow and Marketing flow. The latter, which mostly involved package design and obtaining a label from the government, was left out of scope at this point in time.

2. Benchmarking

The Product developers ( picture people wearing lab coats) would check to see if this concept could be done with flavors that have already been developed and tested. If not, developers would need to source new flavors from flavor houses — This piece of the process is iterative in itself ( if you source a flavor and you don’t like it or it does not comply with market regulations, you are back to sourcing ) and can take quite some time.

Sourcing flavors is a key pain point for for Product Developers — That’s why they try to keep flavor libraries or do proactive flavor crafting to mitigate the impact of this dependency.

3. Kitchen Testing and Internal Test

Once the right flavors are in place, it’s time for product devs to go into kitchen testing. They start developing small prototypes and try it out with a product managers until there is consensus that the target flavor seems ‘good enough’.

4. Focus Group Test

The next step is getting a stronger level of evidence: will real people outside of the company like this candy? Focus groups are organized with testers in line with the target consumer profile.

5. Market Survey Test

If the Focus Group Test is positive, we have a bigger question: will a big quantity of real consumers like this candy? Product samples are tested by hundreds of people — This is the final litmus test to see if the candy is ready to enter the market.

5. Scale Up Test

Just like in software development, candy development and candy production are two different worlds. A delicious recipe developed with care and love in the kitchen could taste very differently once it is mass produced. It is crucial to conduct scale-up tests (imagine testing on a pre-production environment) to see if the product is likely to remain the same.

How difficult is it to get the product to market? It might take between 10 and 50 prototypes to get the product right, and you still need a government stamp and the commitment from the flavour houses to supply you on time.

As you can see, candy-making is very different from software development. You can’t really make small ‘slices’ of value. You can’t push changes to production everyday. You can’t roll your own flavour technology if you are not convinced by what the market is offering you. Your most simple MVP will have to go through a lengthy, sometimes tortuous process before you can test it in front of a real paying consumer. Most of the work happens sequentially and there are plenty of blocking dependencies.

Exposing the candy development process to the organization was an aha moment for many people. Even though the teams were relatively small, they had absolutely no visibility of how work came to their desks.

This discussion also helped us scope the ways of working. Marketing, packaging and production were left out of scope for now — clearing all those sections of the process was overly ambitious for the scope and goals of this work. time we had available. The focus would then be on ideation, product development and prototyping. As a team, we could be considered successful if we achieved the following:

• Getting More Recipes Ready to Market — The company did not have a systematic approach to get from product idea to Market. While things somehow happened and the company was performing successfully, a noticeable loss of speed could be observed due to lack of discipline and rhythm. Becoming faster would mean having more product recipes ready to be branded, marketed and launched.
• Role Clarity — Product decisions tended to either stagnate or escalate due to diffusion of responsibility. When fire-fighting the opposite would happen — it was usual for employees to ‘jump in’ into areas that were not their own. Product Managers did not know what was their realm of decision-making.
• Foster Learning — Teams kept falling into the same pits and organisational learning did not seem to be occurring. While production had solid monitoring practices in place, there was no way to trace mistakes in product development. This had led to serious production issues in the past.
• Predictable Cadence of Work — There was no single point for monitoring, steering and driving product development. External dependencies, raw materials unavailability or unreliable suppliers would create weeks of delays.

3. Designing the Ways of Working

Sadly nowadays, many Agile implementations take a black-box approach. Agile frameworks are applied as an additional layer of roles and processes that can be laid on top of any business and team.

We preferred to take a deeper understanding of our client. The sequential nature of candy making and the organisational diagnosis called for using Kanban if we went by the book (start with visualising work, and iterate from there). After due consideration we ended up co-creating a tailored framework based on Scrum. Here’s why:

• Scrum gives you role clarity — This is one of the things that the organization needed the most. Employees needed clarity on what was expected from them and someone needed to steer the process proactively.
• Some sense of cause and effect was needed — Even if Scrum would provide no improvement at all, it would allow teams to track work plans, traceback mistakes and act on impediments as soon as possible.
• Organisational learning needed a push — There was no established forum where teams could share feedback or discuss process improvements. Introducing retrospectives could help overcome this.
• We had advocates already — The client was excited about Scrum and some other key stakeholders were on-board with the framework. We could use this excitement to drive adoption and change.

Tailoring Scrum

Scrum is a powerful lightweight framework, but it was designed with software development in mind. We needed to make a few adjustments to fit the needs of the candy making.

• Product Owners would need to take care of several products at the same time. And each product could be either be a single product or product family — imagine a brand with different flavours . The Product Owner would not only manage work, but also deliver some of the tasks (i.e. market research, hypothesis testing or marketing tasks).
• The Developer team would be composed of a pool of Product Developers that would take all development tasks for any all products under development. The developer team would need to combine both fixed and fluid team members that could jump into a sprint on demand. For example, an idea in early stage would need specialists from legal to join a sprint. A late-stage idea might need production specialists to help out.
• The Developer team also includes a Lead Developer. This role takes care of coaching and developing product developers and evolving the field of expertise. At the same time, this role played the critical role of ensuring supply of raw materials and keeping oversight of the overall capacity of the development team.
• In this setup, one Scrum Master works with all Product Owners and the Developer team.

Overview of the custom Agile framework

We also had to embed the Scrum process into the overall company context. Having structure and cadence is great, but how to make sure an idea is ready for the Product Owners to take on? How to collect, refine and prioritise product ideas? How do we keep products aligned with business strategy?

To enable the above two additional roles were designed on the upstream side of the framework:

• Business Sponsor: The General Manager of the Company. Provides a strategic frame for the company, sets revenue and profit targets for the overall product portfolio.
• Product Guardian: In charge of leading the Product Owners, this role nurtures and mentors them. The Product Guardian also ensures that there is a consistent approach to Product Strategy takes care of business development — staying in touch with wholesalers and retailer chains across countries.

The Business Sponsor and the Product Guardian set an overall vision for the business and manage the idea pipeline via a Quarterly Business Review. This goal of this ceremony is to prioritise, discard and move ideas through the pipeline. Through such mechanism we could ensure two key things:

• A more robust approach to ideation and validation
• Overall strategy being considered when prioritising ideas
• Ensure that ideas are pulled into development, instead of having them pushed.

4. Building Capabilities

We ran a multi-day event where everyone affected by the new ways of working could learn more about what Agile meant and practice the new ways of working. We embedded the following principles in the design of the sessions.

Mindset over Process — It was top of mind for us to get people into thinking Agile instead of simply being agile without understanding the why and the value it could bring to their everyday work.

We spent a day covering Agile values and principles. We took time to demystify buzzwords and doing experiential games that were easy to connect to their work environment. This helped people connect the dots and discuss the elephants in the room.

Provide a Safety Net — As coaches, our goal was to prepare the teams to start practicing the new ways of working right after the training event. Bringing a fair amount of new roles, artefacts and meetings meant a lot of change. We were very focused on making everyone feel as safe as possible by providing all playbooks and having plenty of time to clarify roles.

Having this in our design was beneficial in a number of ways: first, it allowed people to vent out fears and skills gaps. It also allowed us to gain an even better understanding of their business model, and modify their ceremonies and artefacts accordingly.

Agile Dojo — Our program was heavy on tackling real cases and doing role-playing exercises. At the beginning we provided a bit more guidance — Once the we saw progress we gave the team space to experiment, fail gracefully and learn from experience.

This was a key element for success. The concept of an Agile Dojo provides a safe space where people can play around with real work, test the tools and make mistakes without real consequences. This was also crucial for participants to take real value from the program and transform ideas into experience.

The team voiced their need to measure success and have a source of truth for measuring performance. We embedded sessions where the teams could design metrics at a product, process and team level — To ensure ownership, the input of the session was focused on describing what makes good metrics and then have the teams and the stakeholders decide what makes most sense for them.

5. Making it Stick

Getting started with a new way of working is hard for any organization, and a candy making factory is no exception. Before leaving, we gave the team a head-start by helping them sort out all the logistics involved in the framework (agreeing when to start, when to do Backlog Grooming, Sprint Planning etc.) We are in this phase at the moment, and we are trying to helping by :

• Providing Giving hotline support
• Providing feedback on artefacts
• Observing ceremonies and debriefing with the Scrum Master
• Upskilling Product Owners and Scrum Master

Learning and Take Aways

• Appreciate Cultural Differences — When you engage with a new organisation, you bring your own worldview on management, team behaviour and culture. It is important to approach differences in understanding with respect, humility and curiosity.
• Keep the whole system in mind. The scope of the work would optimize the local state of product development process, which would be likely to create a bottleneck in production in the future. We engaged part of the production team in our sessions and designed metrics that would help in flagging flow problems.
• Involve everyone affected. Chances of success increase exponentially when you allow everyone to have a say in the design of new ways of working. For instance, we invited the whole team to design the roles of the Business Sponsor, the Product Guardian and the Lead Developer. This allowed for healthy debate to happen and small tensions could be resolved.
• Skills matter more than processes. There was a big gap in Product Management expertise, which probably explained the lack of ownership. Even after bringing new ways of working, Product Owners still had a long way ahead of them. We wanted to make sure that the new framework was already geared towards bridging this gap.
• Be mindful of the nature of the work. Battle-tested tools in Agile (user stories, INVEST criteria, estimation) needed to be rethought when you cannot make small independent slices of value and most of the work happens sequentially.
• Be a role model — We started everyday with standups, managed a kanban board with the work that needed to be done and closed with retrospectives. We worked hard to adapt to change as coaches and invited senior leadership to take feedback from employees. Role modelling effectively brought credibility to the intervention.
• Shake, then stabilise. For an organization in flux with low level of communication, some well-orchestrated change was needed. It is important though to then establish a baseline and move forward in small steps from there before applying big changes again.
• Coach from the back of the room. Implementing a new way of working is much more about letting individuals explore, try things out and practice than providing instructions for people to execute. As coaches, we believe it is counterproductive to present yourself as a ‘subject matter expert’ who can dictate what is right and wrong.

Thanks for reading this far! Feel free to contact me if you have any questions or comments.