Log in to watch

Log in or create a free account to watch this video.

Log in
Virtual US 2022
Share
Download slides

Experimenting with Agility and Flow at Waters Corp

Waters Corporation (NYSE:WAT), is a global leader in analytical instruments and software with a global annual revenue of $2.5B. Waters Corp has pioneered chromatography, mass spectrometry, and thermal analysis innovations serving the life, materials, food, and health sciences for more than 60 years. With more than 7,800 employees worldwide, Waters operates directly in more than 35 countries, including 14 manufacturing facilities, and with products available in more than 100 countries.



This story presents the challenges, successes, and failures we experienced in applying the Scientific Method in a Scientific Organization to improve culture, agility, and flow toward delivering better value in our LCMS products with greater predictability and confidence.



Within Waters Informatics we had already been on an Agile Transformation (capital A, capital T) for nearly a decade, but the expected improvements were not forthcoming nor evident.



From top down the view was of wanton indiscipline and from bottom up the view was of time-and-scope boxed bureaucracy. A culture of fear, lack of psychological safety and mistrust kept things in a perennial state.



For my part, I had just attained the role of Director of LCMS Product Owners and it quickly became evident to me that I had no idea how to do nor how to be successful in this new role. The picture was grim – something new was needed.

Chapters

Full transcript

The complete talk, organized by section.

Kieran Neeson

I would like to share with you our journey of experimenting with agility and flow at Waters.

Before we get started, let me tell you a little bit about Waters' history and what it is that Waters does. Waters was founded by Jim Waters in the 1950s. Jim believed in delivering benefit, and the benefit is always in the eyes of the receiver.

In 1972, Jim was approached by a chief postdoc from a Harvard lab who was working with Dr. Robert Woodward. Dr. Woodward was a Nobel Prize-winning chemist. They were synthesizing a relatively large compound with 92 different atoms in it, and they had run into a problem. They had introduced a group to the compound, and now they needed to separate that from the rest. They approached Jim, and Jim agreed to take on this problem.

In two days, Jim returned to Dr. Woodward with a separation of his compound. Jim had delivered benefit by solving Dr. Woodward's problem. Solving problems continues to be a key principle at Waters today.

Waters software and systems ensure the safety of the medicines we take, the purity of the water we drink and the food that we eat, and the quality and durability of the products that we use every day. Together with our customers, we unlock the potential of science to leave this world better than we found it. We deliver scientific insights to improve human health and well-being.

My name is Kieran Neeson. I am a director of informatics at Waters. I have been with Waters for 22 years. Over that time, I have observed that delivering benefit through our systems and solutions is difficult.

About a decade ago, we undertook another transformation to try to improve how we might better deliver benefit. We started agile teams. We created new roles and new ceremonies. The expectation was that pretty soon improvement would be obvious and evident, but it was not.

The key problem seemed to be our inability to deliver with confidence and predictability, and there were two perceptions to this problem.

From the top down, the perception was one of indiscipline. The teams were not aligned, they were not talking to each other, and engineering teams needed to estimate better. Another complexity was that the product we were working on was replacing the legacy product and was intended to be the product upon which all future benefits would be delivered. So there was immense pressure.

From the bottom up, the view was one of time-box and scope-box bureaucracy. Teams were unwilling to speak the truth, even when things like delivery plans were completely inaccurate and not going to happen. Morale was low. There was a culture of fear, a lack of safety, and mistrust, and that kept things in a perennial state.

At the end of 2019, just as the pandemic was beginning to emerge, we had a chance encounter with Matt Turner from Sooner Safer Happier, who was on site working with some scrum masters and engineering teams.

Matt was working with the teams and the people on the teams, the people who were doing the work at the information. He was walking the floor, doing the gemba, to use his own term. He was wearing out the shoe leather. Pretty soon, bubbles of curiosity and learning started to emerge, people curious about what Matt was doing.

After a while, those bubbles would come together, and we began to embark on a journey of discovery and learning, exploring how we might improve our agility and our flow, our ability to deliver benefit, and even be happier doing it.

In 2020, the experiments would begin.

From my end, I had just undertaken the role of director of LCMS product owners. My role was to bring that team together and get them aligned. When I spoke with the team, they communicated to me that they felt disempowered, that they did not have authority and autonomy for their own products, and that they felt decisions were being made for them.

The expectation of my role was to be a chief PO, to do exactly that: to take the authority and the autonomy away from them and make those product decisions. If we were going to come together, we needed something different.

We had been introduced to the book Turn the Ship Around! by submarine captain David Marquet. That story tells us about the intent-based model, which flips things upside down from traditional norms and gives control and decision-making authority and power to those with the information. We thought this was something that would work for us, so we were willing to experiment.

In intent-based leadership, the model is based on two pillars: competence and clarity. We subtly changed this to suit our own unique context, and we focused on safety and clarity. We needed a psychologically safe environment where POs could make decisions without fear of repercussion or penalty. My part was to try to attain the strategic clarity that they needed to make better decisions. That is what we would try.

Our second experiment would expand beyond our own PO team to other parts of the organization, trying to break down those silos, those other parts of the organization that had variety and could help with our clarity.

We were inspired by Team of Teams from General Stanley McChrystal, and we started to reach out to other groups like product management, marketing, CX, UX, field, and service.

Pretty soon, we created a shared environment which had multiple groups coming together informally to share learning and experiences, share information, and optimize and increase information flow. There were groups across three different geographies and across all sorts of different roles, and it started to grow quite quickly.

We tried to get a measure of what the overall experience was from people in the team of teams, and this word cloud that you see was overwhelmingly positive.

In the middle of 2020, a significant event would occur with a new CEO at the top of the company. This is worth pointing out now because it has a significant impact later on.

A third experiment would continue our own clarity and alignment. We needed new ways to prioritize and make work visible, and try to get alignment around what is the next most important work to do.

We experimented with economic prioritization and digital whiteboards like Mural. We effectively created obeya rooms where we could get people together, and sometimes they would form and have meaningful conversations around these visuals. Our language started to subtly change as well, and we started to see reference to things like flow, outcomes, and constraints.

In 2021, our focus would shift away from outputs towards outcomes. Traditionally, delivery had been driven by big lists of requirements, big lists of features. We wanted to move that focus away from those things towards outcomes: what is it we are trying to achieve, for whom, and how will we measure that? We used OKRs to achieve this alignment. We used the structure to describe what the outcome is, who it is for, and how we might measure it.

In the middle of 2021, language from the top began to change. There was greater demand now on empiricism and data-informed decisions, and there was constant drive to show your working out, to show your homework, to use a scientific term, to defend your thesis.

This aligned very well with the language and the things we needed from the bottom up, which was detail on value, and why one piece of value is more valuable than the next, so that we could prioritize better.

Sometimes there would be resistance to these requests around measurement, values, and numbers, which came with its own sense of irony. We would point out that we are a scientific company, indeed a specialty measurement company, so we should be comfortable with data-informed empiricism and measurable things to help us make better decisions.

As such, our conversations around value would change. We started to see templates emerge around value props and value outcomes, and how the metrics might tell us when that value has been achieved. Economic prioritization continued to play a role, and we started to talk about things in terms of cost of delay rather than the cost of doing.

At the end of 2021, we had some success. The product we had been working on was delivered in Q4 as intended, and the outcome we wanted to achieve, which was the first customer order, was indeed attained. This set a precedent for us and was very pleasing for everybody working on Waters Connect and everybody who had worked on Waters Connect previously.

In 2022, we continued our own experimentation and new techniques to prioritize. We played with economic calculators and planning poker, and combining the two, to help show stakeholders that they are often very misaligned in terms of what they think is the next most valuable thing to do. This helped us then get an agreed and aligned prioritization, when stakeholders could see the discrepancies between how they saw the priority order against their other stakeholders.

A seventh experiment saw us link OKRs with North Stars. We had been training and working with OKRs, but we found them difficult, and we were trying to do them bottom up. North Stars helped us attain some more strategic clarity and input measures, needles that we might try to influence to achieve those things. This helped us narrow the focus and helped the conversation for the OKRs. That helped us find better words and measures.

Our eighth experiment, which is ongoing, looks to get better credibility and improve predictability and confidence in our plans using our own delivery data. We focused on things like cycle time, lead time, and throughput, and used approaches like Monte Carlo forecasting, which uses those data to help us make better estimates, better forecasts, and better communicate the level of risk that might come with those forecasts.

A lovely moment we had this year was when Waters Connect, the product we had been working on, was recognized in the Biotech Breakthrough Awards, where it won analytic solution of the year. This was a great moment for everyone working on Waters Connect and everyone who had previously worked on Waters Connect in the run-up to this year.

Things that we mucked up, but we learned from and intend to go again: none of the things that we pointed out here happened successfully the first time round. No experiment has ever been successful the first time around. Things like OKRs and North Stars, we keep going. We will keep messing these things up, but we keep learning, and as long as we are learning, there is no such thing as a failed experiment.

There are things that we want to introduce as well. Wardley Maps: we have been aware of these but have not really got to grips with each yet, and we think these can really help because strategic clarity is a continual problem. Dynamic prioritization: we have played with this, and I think we will continue to play with this, and there are a lot of lessons learned here.

Team Topologies: we have started talking about things like platform as a product, and we have really just got started, so we want to explore this in greater depth and detail.

Outcome canvases: we have played with OKRs and North Stars and value prop templates, etc. Outcome canvases look like they might be something that can bring all of this together, so we feel that this might have some value for us moving out this year.

That brings me to a close. Thank you for listening. If you are on the Slack channel live, then I look forward to seeing you in a few moments.