Agile Business Transformation that drives Innovation and Culture

Is it more vital to scale agile than to change the agile culture? Hear from Isaac Sacolick, an Amazon best-selling author.

Evolution of Agile

When we started working on agile methodologies. 20 years ago, it meant very little to different people, it was relatively new. We understand Scrum and Kanban as two primary ways and methodologies to execute agile, loads of frameworks came out. And then we started thinking about multidisciplinary teams and what that really meant to the organisation. We put mindsets and culture and transformation at the top of it, you know, agile really grows because who doesn’t want to be agile, right, listening to customers and feedback, pivoting and adjusting your priorities, so that you can execute against goals that are always shifting in terms of what customers and employees need. What we understand today are things that need to evolve over time. So lots of different things probably come to your mind around agile. Now if you practice agile, this is probably a picture that comes to your mind when we talk about it. This is a basic picture of Scrum. And so what happens here is a multi-disciplinary team is put together their assigned goals. They operate in small units of time called sprints which are usually one to two to four weeks in length, and usually not more than that, at the beginning of a sprint, a product owner is setting a backlog. That backlog is then prioritised the team commits to how much work it can get done during that sprint, it holds a daily stand-up so that progress can be tracked, and blocks to their progress can be resolved. At the end of that sprint, two rituals occur, right we do a review or demo. So we show our product owner and our stakeholders exactly what we accomplished. And then the team holds a retrospective to figure out what went well and what can be improved on. And then the cycle repeats itself. So right that’s the first thing many people think when the word agile comes about, and they think about the scrum process. So organisations started adopting scrum as a methodology and then started to ask a question, how do we apply this to a growing number of teams? And so over the last decade or so, there’s been a number of frameworks that have come to organisations to help them with this. And so when we talk about multiple teams working together or on an initiative or project or programme, they came up with a tonne of terminology around this. It’s really important to have a large number of people adopt the process.

But when I think about culture change, when I think about driving transformation, when I think about a learning organisation, and I reflect on the fact that every organisation I’ve ever worked with is different. We have different goals, we have different missions, we operate in different geographies, we have different technology legacies, we value product management in some organisations we don’t and others are sales driven, and others, you know, learning is more important in some companies than others. So a lot of different factors go into thinking about your agile way of working. And so I want you to think beyond the framework and think about how you guide your company on a journey that starts with the basics and brings more people and more methodology along the way until you have your own unique way of working, built on the best practices. Thinking about the basics of agile culture, I really think about that team, that commitment, and that retrospective. In an organisation that’s usually built on cycles that are financially driven, we think about quarterly, and yearly planning, financial metrics and financial goals. But we know that what we’re going to come up with today is our priorities are going to evolve over the next several weeks months to years. All right, part of adjusting our priorities is our culture. Part of it is not necessarily failing fast. It’s learning, it’s experimenting, and it’s adapting. So that all goes into what I think are the key cultural components of an Agile transformation. The third thing I think about is driving innovation. Okay, so when I put the multidisciplinary team together, it’s because the answer to the solution that we’re seeking isn’t always straightforward. So how do we align Agile to be able to do this, and it gets into how we balance our team’s efforts, how much of our time is being applied to innovation, versus keeping the lights on versus just responding to customer needs?

Agile Business Transformation

There’s a large component of agile that talks about self-organising teams and self-organising teams are really important for innovation. But when I think about what larger-scale enterprises need to think about, it’s about taking learnings and getting a lot more people to understand them and to apply them. And so I think about centres of excellence and places where standards can actually involve better quality, and share knowledge with a larger group of people, not just the experts. Lastly, I think about delivering fast and frequently what this basically says is, I’m not going to just sprint and iterate and iterate and iterate and not deliver anything, I’m going to deliver something that meets a minimal set of requirements, I’m going to get my feedback, and then I’m going to improve on it. I’m going to do this as frequently as it makes sense for my end users. And as a frequent, as it makes sense for me operationally. Now to do this, I’m going to operate very differently when I’m running an Agile transformation. There are different roles for leaders, right leaders have to set a vision and a strategy. But most importantly, they need to listen, they need to listen to their organisation, who’s in the weeds, looking at how customers are responding, looking at how marketing campaigns are functioning, looking at how new technology is being used, or data is providing insights. And the leaders need to do better listening than speaking to be able to adapt their strategies and envisions. I think about management, who has a different role of being able to mentor teams and people and being able to coach them, right, giving them some freedom to self organise, but also know where standards and Centres of Excellence play. And then I think about agile teammates, right? How they are going to work as a team, how they respect each other, and how diverse teams actually drive innovation. The second thing I’m going to think about is the process. And this is really the heart of what Agile and Scrum deliver to a team, the ability to deliver results at the end of every sprint and push them out to customers with every release. Alright, the third thing I think about is in my portfolio, I don’t want to just do innovation, or just do growth projects, or just do operational excellence, or just do compliance and regulatory work, I need to do a balance of these things. And so how a product manager and a product owner and a delivery lead and a tech lead, and I’m using language from my book, sit together and operate together and make decisions over how much work in these different categories is going to make sense over the next sprint release, quarter and even year. So that to me, is the heart of many aspects of an agile business transformation. So let’s look at putting this together. And so the first set of concepts I want you to have is around agile itself, and how to make a transformation. And so there are three pieces to this first is it’s not just for technology, multidisciplinary teams, that means business. And it means data and analytics, professionals are also working with teams. Secondly, we’re applying agile in different departments, sales, marketing and operations, for example. And the third is we’re going to learn from other industries that have applied agile very successfully. So we’re going to talk about that over the next couple of slides. If Agile is only being done by your tech teams with limited interaction with the business, then it’s very hard for this practice to translate to ongoing success and a transformation programme. Right, we can have the doe-rs on one side, and the planners on the other side. We can’t have the execution group and the stakeholders completely divorced from the accountability of the results. Okay. The second thing is it’s convenient for business leaders to wrap an agile development process with a traditional project management process. And so this becomes somewhat challenging, right? When we talk about transformation. We’re talking about going to the CFO and saying, how can the CFO still do accounting and quarterly results in planning while teams are still doing agile and working in sprints and releases? So that’s a big adjustment. Alright, the third thing we’re going to talk about is how it empowers groups, right? Agile empowers business leaders to leverage customer feedback and to adjust priorities with every release and sprint right now with that ability comes a lot of responsibility. Because it’s an amazing tool. If it’s used well, it means you don’t need everything planned upfront, okay? It means that you’re going to learn along the way before an initiative starts. And it means that customers and end users can provide feedback as they see the product demoed and kick the tires after each sprint.

Transformation by Agile Planning

When I think about transformation. I start with continuous planning, the idea that when I have a team or a group of teams, or an entire organisation, not only am I working toward the deliverables that I committed to, but I’m also working toward planning our future, right, that means in Agile terms, every sprint, I’m not only doing stories to complete something, I’m actually also doing the work to fill my backlog, and adjust priorities and think through what the requirements are. Right. So doing that every sprint is what I call continuous planning. Now to make Good smart decisions in terms of priorities, I want the team to provide some feedback. And that feedback comes in the form of estimates, I have a unique way of making estimating rigorous and easy for groups. But I want everything to be estimated. And in particular, I want it estimated on complexity. I’m less interested in how many hours you think it’s going to take to get something done. And more interested to hear about whether what I’m asking is complex or not. Because if it’s complex, I can change priorities, I can change the scope, I can redefine the problem in different ways, and I can make different decisions around what a minimally viable solution might look like. Right, so there’s the tremendous value you can get out of estimating. The third thing is when I discussed the notion of a release, it starts from the point where teams are planning to the point where they push something out to customers. And then lastly, managing the feedback around what teams have learned from it. So release planning is the art of taking what was done and continuous planning and estimating, and deciding what’s actually going to be ready to launch to customers. And then lastly, the monitoring part of this is really about listening, right? I put something out to all or a subset of customers, what did you learn what’s working? And it’s not just about operational monitoring. It’s also customer feedback. Now, once you start putting a process like that in place, you start getting the opportunity to change some mindsets. And I do this through three functions, what I call Agile principles, which is a way for a team to understand a way of working together. Also an agile operating model, right? Agile operating models get into what are the hard requirements and KPIs and the ways we’re going to measure teams. Lastly, I’m not just concerned about what I’m building and what I’m changing I’m also concerned about how well it runs in operations. Right? Is it reliable? Is it performing? Well? Can teams adapt to it? Are we using automation the right way? Are we also using this to make sure that those teammates that are operating are also partnering with the teams that are building things? And vice versa? Okay, so I’m looking for the process to drive principles and operating model, and then a culture that balances both what we’re changing in the organisation, and then how we’re operating. Now, once I have principles and culture and operating models coming to play, it starts driving the transformation I’m seeking, right? So first, I need a process and methodology. Second, is I need to grow the way of working, which is what you see down here. And then I start seeing the benefits from it. What does that look like? Well, if I’m estimating and my estimating techniques are improving, I can start communicating a data-driven roadmap, not something somebody guessed, not something that’s also definitive, but directionally something in between a sprint, right, and something.

Agile Release = Planning + Delivering + Deploying

Putting all together in terms of what behaviours and changes this does for individual people who participate in the agile planning process. First and foremost, we start building platforms, right, we’re not just doing run-off projects, or isolated incidents of people getting things done, we’re actually starting to use Centre of Excellence to actually drive platforms. That’s really the heart of innovation. And then when I think about culture change, I think people who are going to be product managers and owners, they’re going to think more about prioritisation, they’re going to have less stress because they’re going to see their team delivering. And they’re really going to focus on what the essence of an MVP is. You’re sitting on the Agile roadmap today and you can make some decisions, right? First, you could try to go down a path of being very self-organising, letting teams decide and individuals decide how you’re going to operate. And so that works when you’re doing a lot of innovation. It works with very small teams and innovation teams. It doesn’t work well when there are more people, more teams, more complexity, and more legacy. And so you can go down a path of doing frameworks and thinking about scaling agile and putting some rigour in place in terms of process. And so I fear that either those don’t work for most organisations because neither of them finds the right balance between self-organisation, organisation and standards and rigour. When you put all that together and use a small group of people to continue to evolve your way of working. That’s truly how you end up with a transformation and a culture around agile.

Isaac Sacolick

Issac Sacolick is the amazon best-selling author of Driving Digital, The Leader’s Guide to Business Transformation Through Technology. Successful CIO leading digital transformation, innovation, agile, and data science programs in multiple organizations. Delivered new revenue-generating products and drove efficiencies through data programs.