Reinventing Delivery with Aqua
Part 1: Introduction and Overview
Aqua is a meta-framework for aligning strategy and execution, created by Sam Zawadi. The following is an edited verbatim interview, transcribed from conversations between Sam and Tom Boswell in late 2023/early 2024.
Tom Boswell: Let’s start with the most logical first question, what is Aqua?
Sam Zawadi: I describe Aqua as a meta-framework, and what that means is that it’s something that solves systemic problems across organizations. And it’s essentially made of two things. It’s made of a part that addresses strategy and how to break down and prioritize strategy. And it addresses the execution part, which is how we get our work into an outcome-based format, in order to build teams around those outcomes, and then start to deliver. Aqua puts these two things together, together it’s a system of flow for managing strategy and execution. That’s the simple answer.
TB: I assume most readers would know what a framework is in this context, but let’s clarify what you mean by meta-framework
SZ: The way I use the term meta-framework is that it is a container which is non-descriptive, principal-based, and has a trajectory where if you start working within the confines and the guidelines of the framework, you will achieve more agility, more autonomy, more self-empowerment, etc. And all of the other good stuff that we like, such as the right kind of leadership style (over time).
If you put constraints around, and for example say, you have to work in two-week time boxes and you have certain meetings, then what you are doing is you are pushing people into a box, even though you might think that box might be liberating, we’re still pushing people into a box. They have to operate a certain way and you’re giving them a modus operandi.
With a meta-framework, you define trust points, and you define some key events, but they’re very light touch, the way people do things, the way they approach things is completely up to them, and of course they have guidance — that’s my job, to guide them.
TB: I’ve heard you describe Aqua as “not an Agile scaling framework”, what do you mean by that?
SZ: So take LeSS, or SAFe, or Nexus, they’re based around Scrum teams of some description, and they’re based around specific cadences. The teams come together to form a team of teams, and stuff comes in from the top, so to speak, and people deliver in cycles, and it’s predictable, and they would do this ad infinitum.
Aqua doesn’t actually care how you work. This is the thing, I say it’s from strategy to execution, and it stops at execution really. It says this is the best way to execute the work, but how you do it, how you deliver, whether you use Scrum, Kanban, or SAFe, it doesn’t matter, it is completely up to the organization. It has guidance on that, but it does not tell you what to do or how to do it, necessarily.
It’s also completely non-prescriptive. Whereas every Agile or scaling framework out there, is. They have specific roles, they have specific ways you should work, and specific events you should do. It’s all prescriptive, right? So Aqua essentially removes itself, so that’s why it’s a meta-framework. It removes itself from the doing, and it simply says, before we even think about the doing, we need to think about what we want, what problems we are solving in the organization, and therefore how we need to shape the work.
That is one of the most important things in any organization, based on my experience from almost day one to now, how you shape the work literally defines how you actually do the work. And that means you shape the work to be more outcome-based. In Aqua we strive for outcome-based work, OKRs. The more we can do that, the better we will be, the more apt we will be, and the more effective we will be at executing the work.
So that’s essentially the difference, it’s not a scaling framework. The closest description I find is a mental framework. By the way, another description is a VM, a Value Management Office.
TB: I like the description of shaping the work. Does Aqua do anything around shaping the organization or system?
SZ: Do you mean in terms of teams, and people, and stuff?
TB: I was thinking perhaps of management frameworks like Holacracy. Where you look at shaping the organization, in terms of interactions and decentralizing decision-making, and so on
SZ: So it’s not a restructure, and it doesn’t shape the organization in that way. What it does is it works with the executive or senior leadership team, which is the Helm part. What we do is we shape that part, and what I mean by shape, to be specific, is we give the exec teams or the leadership teams structure, a structure they didn’t have before.
And so what I found is the one part of Aqua that execs and leadership like the most is the Helm*, because it gives them what they didn’t have before, and pretty much unanimously what they know they need, regardless of where they are on the political spectrum.
So it gives them structure, it basically says, you need to come together and go through the Helm process, and then by doing that, we’ll become more of a team, we’ll be tighter, we’ll understand each other and what we’re each dealing with right now. We’ll understand everyone’s respective business areas and so on and so forth, and we’ll be aligned on where we’re heading.
*We discuss The Helm in more detail in part two
TB: Let’s talk quite broadly about the context in which Aqua was developed and how that influenced it. Was this happening in 2022?
SZ: Yes, early 2022, although just to be clear, the thinking about this and some of the early diagrams if you like with Aqua have been with me since lockdown. But 2022 was the time I got to do its first implementation.
TB: Again to that broad context, what are your thoughts around the current state of Agile?
SZ: My current view of the Agile landscape is that Agile is in a very precarious situation at the moment. Because I think there’s been a recognition that due to these economic times, the climate in which Aqua has been developed, I think business leaders are seeing Agile as something that they can’t really afford to keep investing in without actually seeing results. And just to be specific, the coaching element of Agile is an enablement function. What businesses and organizations want to see is delivery and results.
Coaching has been a luxury, especially for smaller startups, and I think rightly so. Coaching was overhyped, and it under delivered, that’s my observation. And as a result, you have a ton of Agile Coaches out there who don’t know much about delivery. So where I see the Agile industry now is going straight back into direct-to-value roles, to delivery roles. That means hands-on people, who are working in the teams responsible for doing the work.
So I think that’s been kind of a return, if you like, I think for a while the industry was wholly on the delivery path in terms of waterfall, then it kind of got distracted with all of the coaching and the fluffiness, and now it’s saying, well actually these are really trying times economically, we need to just focus more on delivery, getting things done, and getting stuff out the door.
That means all of this enablement stuff we’re investing in, that needs to be pushed to the side, and we will focus on delivering. The difference is now we have a better understanding as an industry of Agile delivery, as opposed to Waterfall. I think that’s where we are, and I have always said the best Agile people are people who blend these things, so you can be an Agile Project Manager, or a Program Manager, or whatever role, but part of your skill set is coaching, rather than coaching being a distinct role. I think that’s never been a good idea, that’s my opinion.
TB: How does Aqua fit in with this post-Covid, hybrid, asynchronous working environment that most of us are finding ourselves in?
SZ: Well, it’s kind of indifferent to it, and this is what I love about the Aqua system. It’s truly meta, in the sense that it doesn’t matter what your environment is. My current client (note: referred to throughout as client zero) is 99% working from home locations, or maybe one day a week in the office. Aqua doesn’t require a physical presence. I personally prefer physical presence in many of these events, but we’ve run Aqua events and we continue to run Aqua events completely virtually, and in mixed hybrid environments as well.
TB: There seems to be this idea that leaders are increasingly facing a really challenging VUCA landscape…
SZ: In terms of VUCA world and all that stuff, I mean, it’s life you know! The thing that I find helpful is, and I know this is maybe counterintuitive to some people in the industry, but I’ve actually stopped thinking about things like Complexity Theory, and it’s just life and change, and that’s just what it is. And you realize that you have to respond to it, and you have to keep trying to get ahead of it, but you’ve got some great principles and values to guide you, the Agile Manifesto, and Aqua stuff, and you deal with it. Things will always be changing, for example, if we look at what’s going on in the world now, things seem unpredictable and uncertain, and that causes us to feel the same. This is why the initial approach is so important, your mindset, the way you think about things, your framework for approaching the world, should be robust and allow for chaos as much as order to any reasonable degree of course. So the more meta you are, the more adaptable you are in terms of how you run your business better.
TB: So we’ve covered the wider context in which Aqua was developed. Let’s talk more about the local context and the organization where you’ve developed the core of Aqua. How would you describe their culture? I’m guessing they are not coming from a paradigm of command-and-control, Taylorism, rigid hierarchy, etc.
SZ: The culture is great, it’s quite modern, this very young kind of age group. It’s very diverse in terms of culture, but also in terms of ways of working, and thinking about problems and that kind of thing, there’s good brainstorming that always goes on there. Yeah, the culture is great, it’s modern, it’s adaptable, it’s not strict, they really encourage you to bring your own thing. It’s like a mosaic, bring your own colourful piece and plug it in, which adds to the picture. It’s that kind of place, which is really nice, there is a limit to all of this of course.
In terms of Taylorism, all that stuff… Amazingly they don’t really have a history of delivery formally. So they have a PMO in the UK, in the London-based office, which serves the business side more. And in Melbourne currently, they have their main delivery function, which includes IT, Digital, Architecture, and all that stuff. And the manufacturing and assembly itself is done elsewhere. So essentially, it is quite disparate in terms of what they do. But part of what Aqua is doing is unifying all of that, which is why exec leadership teams really like it, they realize oh, it’s going to bring up all of us together, great, we’ve been crying out for this for the last five years!
TB: Without being too specific, you’ve alluded to the fact they primarily produce physical consumer products, right? They are not in the business of providing IT solutions or digital services. How did that non-software context influence Aqua?
SZ: I was thinking about this, and to be honest it didn’t really shape Aqua directly, but it did help to give it its name. The reason why it’s called Aqua is because the client I work with produces essentially, water-based products. We wanted an image to symbolize flow, and they love to use Greek and Latin terms internally. So I thought okay, well let’s go with water and Aqua seemed really nice, and that kind of took off initially. Since then, I should probably say it’s not actually referred to there as Aqua, which is great, that’s the point. We have this meta-framework called Aqua, you get it, you understand it, and you begin to internalize it, and you begin to make it yours, you tailor it, you name it, you do whatever you want with it, but essentially it’s Aqua. So it doesn’t matter whether you’re a manufacturing company, whether it’s physical, electronic, or digital products.
TB: I think there’s another really interesting element to this, which is that Aqua is being used not just to develop their e-commerce platform or internal IT solutions, I get the impression it’s being used across a broader range of functions.
SZ: So the client has three functions which are essentially separate, completely separate, and they just kind of talked to each other when they needed to. Yes continuously, but not about the right things, not at the right times. Your typical divided organization, trying to get stuff done.
What Aqua did on that side of things, is it unified them, it put them back together, tied them together, and it said we not only need to work together, but we need to weigh what we’re each doing against each other in terms of our goals and objectives, and we need to deliver them as a team. That is a very hard thing to do in an organization that is traditionally very divided. They’ve been going since the 1980s, it’s a very old company, it’s got that heritage, but they still don’t understand modern delivery. And there is an extra complication, they’ve been acquired by a very large, even older company, a massive company, and they do things differently.
So Aqua essentially brings them together, it unifies and brings us together, and it starts to introduce this idea of flow.
TB: What were some of the problems or challenges you were looking to solve with Aqua?
SZ: Yeah, that’s a good question. Okay, so the first engagement started with me designing a leadership training course for this organization, and that was supposed to be it. I did my due diligence, found out what they needed, put the course together, led them through it, and then they asked, could you come and work with us and help us shape our leadership teams in this manner?
Of the key problems that manifested, the biggest one was prioritisation. On a big strategic level, they just didn’t know how to prioritize, and they were a very reactive organization, and to some extent, of course, they still are, because these things take time, but they were very reactive. Almost every single person within the leadership team said we need to solve the prioritization problem. So that was the biggest problem and there was no argument.
The second biggest problem, I would say, was people. There was a high attrition rate, every year there was attrition just after they got their bonuses. And it’s linked to this reactive kind of fiery culture because when you’re constantly reactive you’re overwhelmed. You’re serving about four different masters, and you’re trying to get all this stuff done, and you just don’t have the time to do it, and it’s just confusion, and it doesn’t make sense, and people are sick of that. And I like it when people take control of their own destiny and try to change things. And if nothing happens they say something like, “if this doesn’t change, I’m out”, because that sends a signal to the organization, and that signal is very strong at this client.
Another problem was too many cross-functional dependencies and so on, like in every organization, but dependencies run very deep in this organization.
Also, there was a lower breadth of skills within the organization. So because it was very divided they have very specific skills in specific areas, but what we really want is skills across areas. So we had this idea of a traveller, which took a few people who had wide skills, and they travelled across different parts of the organization, helping other teams out. But that’s just not sustainable as a concept because there’s not enough people like that.
They also didn’t have any experimentation, they wanted to experiment more with technology and digital.
They did Big Room Planning and they loved it, but it just wasn’t getting what they wanted. We were still working in a siloed team structure, with each domain reporting into different leaders, with different objectives. When we’d leave Big Room Planning, we’re all divided again, and we’re delivering the silos, and it just doesn’t work. Also, it takes so much time and energy doing it. It makes us feel that we’re making progress, but we’re not actually doing much after that, other than doing a good job and getting the same lesson. So Big Room Planning needed to dissolve.
And also there were low levels of flow. So picture the value streams, there were so many delays, with so many pauses, and things just weren’t moving fast, and they got stuck all the time.
Those are essentially the key things which we were trying to solve.
TB: So these feel like really relatable challenges that most of us see in our organization.
SZ: It solves broad challenges, that being said, some of these challenges are ones that most organizations will have, but some challenges they won’t have. But when I think back to pretty much everywhere I’ve worked, potential clients I speak to now, big enterprises, they all pretty much have something in common, they all think they’ve cracked the prioritization problem, but what happens is that they’re not thinking systemically. So they might solve a problem here, or think they have, but really it opens up three problems here. This is why Aqua covers strategy and execution, and it’s systemic which is really important.
Thinking about the bigger picture, it addresses all of these issues, systemically, and that means any specific issues and problems that come up we’ll be addressing with that systemic approach.
TB: I know you co-created a set of principles with client zero, are these specific to this client, or are they part of Aqua?
SZ: They are a core part of Aqua, definitely, but they’re not static. The way I came up with these principles was I worked with some of the leadership teams when I engaged with the client, but I came in with some of these principles, and then we ran workshops, and we made sure that they made sense to us. So although these are absolutely core to Aqua, for example: we need to steer the ship, fund the outcome, gather around outcomes, focus on progress over perfection, focus over fluctuate, demonstrate control, minimize coordination, and internalize capabilities; those are my words, so when I bring them into the organization we look at them and change the wording and the language to what suits them, but the principles are essentially the same.
TB: Before we wrap up this section I’d like to discuss subtraction, which you reference as being a design philosophy for Aqua. Could you talk a bit about that?
SZ: So I read this book ‘Subtract: The Untapped Science of Less’, by Leidy Klotz, and you know what’s funny about all of this, it’s the serendipity. So my philosophy when starting out when building this, or when I was really putting the meat on the bones of Aqua for client zero, was considering what they currently do now, and rather than try and improve that, which may not serve our purpose, rather than trying to add something new, or build more bricks on top of an already complex Jenga puzzle, because the more we build on it, the more likely it is to fall down. So rather than that, let’s try taking stuff away until we get to the point where we say “that’s enough” — let’s do a thought experiment. So I said to leadership, let’s remove items, let’s subtract, at least conceptually for now as a discussion, and let’s see what bricks we can remove to the point where we can still function. So we did that exercise, and what that meant was a lot of things were potentially able to be stopped or rethought. Big Room Planning was one of them, and probably the most controversial as well.
Another one was the idea of value streams, which again to some people is controversial. Another one was scaling and tribal scaling models, so rather than introducing more scaling, let’s just take it away because there is doubt that it is continuing to serve us. Agile jargon was another example, it definitely doesn’t help, as everyone has a different idea of what a story is for example, especially in the senior leadership team.
KPIs and outputs, they were very focused on outputs. Your typical team-level OKRs, and they were fixed on solutioning something and then giving it to the teams to do, so that changed.
Another big thing that changed was they had PMO prioritization, they have a very complex spreadsheet where they put all these numbers and it spat out an overall score, it was heavily financed biassed, and it just wasn’t representative.
So, we took away all of this conceptually, and then we started to reinvent these things. That’s why in the presentation, I sometimes call it, “Reinventing Delivery with Aqua”. Both, “from strategy to execution” and “reinventing delivery with Aqua” make sense as captions!
So, the idea really just comes down to simplicity and avoiding the superfluous. And that was the approach I took with Aqua. And that’s why it became a mental framework, and that’s why you don’t see this prescription in it, and that’s why you don’t use Agile jargon, instead, it asks what happens if you just take these things away.
Another reason, and I know it’s a long answer, is that if we keep going on with Big Room Planning for example, it’s going to keep us in the same paradigm that we’re already in. And what we’re really trying to do is sub-optimize, and that’s what it is, it’s sub-optimization. You have to get back to Systems Thinking and optimizing the whole — that’s what Aqua was made for, and if you want to do that, you’re gonna have to start rethinking some of these basic things and start optimizing from the top end, and as wide as possible.
TB: One last question, is subtraction similar to descaling in your mind? Or are those different things?
SZ: Okay so that’s a problem of definition, it depends on what we mean by descaling. Descaling was a polemic from LeSS to SAFe. Saying, “look at all this stuff you’ve built right? You just need to bring it back to simple stuff!”. Except that simple stuff is still scaling, just less of it. That’s how the word descaling got bandied around as far as I can remember.
Simply reducing, simplifying things, or subtracting is not descaling. Subtracting is literally taking things away to the point where the system still functions, and then rebuilding to solve systemic problems.
Coming soon:
Part Two — Strategy and the Helm
Part Three — Delivery and the Soirée
Part Four — Navigating Change
