Distilled Agility for skeptical teams

Ligia Gaspar-Lukianchikova at UXDX Community: Designing for Agile Domains. Video: https://youtu.be/-blmouBvwdQ

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Agility and skeptical teams

[00:00:00] Yeah, my name is Ligia. I'm currently in Copenhagen, Denmark. It's very dark and rainy, but hopefully this will be an interesting discussion. A little bit about me: I have worked in a few different types and sizes of product organizations, applying agile ways of working from very different roles. I started by practicing very strict, by-the-book practices of Scrum and SAFe, learning then how to adapt them and explain them to the more skeptical minds in the engineering world. As part of my experience I've created this distilled approach, with a strong belief that everyone can understand the foundational concepts that underpin agile methodologies.

[00:00:40] As an engineering manager in the past, and now as a product manager with an agile coaching background and approach to my work, I use these concepts to help the teams that I work with find their way and learn how to be agile, and not just apply agile methodologies. I usually talk about agility and not just agile. It's a small distinction but an important one: agility is a state of being agile, not just doing it, which means going beyond the well-known practices.

[00:01:14] Skeptical teams: it's something that I've been thinking about a lot lately. Many software industry professionals have had unsatisfactory experiences with how agile methodologies have been applied in companies over the past 20 years, and this has led to teams wanting nothing to do with agile as a process anymore. That's what I call skeptical teams. Either they oppose it openly, or they retreat into individual work they can do without being involved in the ways of working. I've been calling this agile PTSD, without knowing that there is an agilePTSD.org website. I really encourage you to go check it out. It's fun to read.

[00:02:00] I think I could probably talk and even rant for hours about what's wrong with agile implementations in different companies and why things don't work well. But a few common problems are imposed, strict agile processes where teams are not empowered to make any changes to their local context. There have been difficult organizational experiences with agile, where some sort of hierarchy has been created around it. And the most common complaint I hear is too many meetings and ceremonies, and it's usually because a lot of people either don't see the value in them, or they're not being facilitated in a way that is valuable.

[00:02:43] Okay, so we've established it doesn't work that well sometimes. Where do we go from here, when we have skeptical teams and we talk about what isn't working well, or they are very resistant to anything related to the agile domain? Do we just throw it away? If we feel like doing that, we should ask ourselves why. Is it just because we consider it a failed experiment, or we are just tired of trying to apply these methodologies, or because we really don't believe anymore in the core values behind them? Good food for thought.

Back to the manifesto

[00:03:20] After all my experiences with agile, I can say I still believe in those principles, and I think practicing agility contributes to amazing products, great teams and overall very enjoyable work life. I like how Dave Farley, the pioneer of continuous delivery, puts it: agile is a good approximation of where we should go. Please start with the manifesto and then we can talk. If you haven't had a chance to read the Agile Manifesto, I invite you to try it, and think also about how it was written when you go through it. I won't go into the details of the manifesto. It is linked here, and you can just Google it, you'll find it immediately.

[00:04:00] But think a little bit about the story of how this was written. It was 2001, at a ski resort in Utah. 17 people met to talk, ski, relax and try to find common ground. What emerged was the Agile Software Development Manifesto. In those 17 people there were representatives of Extreme Programming, Scrum, Adaptive Software Development, Crystal, etc. A lot of these are not that used anymore, but they were extremely relevant at the time. And other sympathetic people that just needed to talk about an alternative to the documentation-driven, heavyweight software development processes of the time.

[00:04:44] With this image in mind, let's think about where we are today. Allen Holub, a widely published agile trainer, speaks about how agile has become a priesthood. And Kent Beck, author of Extreme Programming, says we have been focusing on the wrong things around agile instead of the core of it. I'm very inspired by them, and by all of those that have challenged the status quo in ways of working. They challenged it 20 years ago when they created the Agile Manifesto. Why not continue challenging it today as well?

[00:05:19] Until now I've talked about what makes teams skeptical about agile, and I want to validate their experiences and also provide some ideas on how to start healing from agile PTSD. I think the way to do that is to go back to basics. What is agile? As we look back to that weekend when the manifesto came to life, we can imagine the feeling they had and the ideas that were spoken. And agile is that: it's an idea, maybe a collection of ideas, that were created by people that shared experiences, that shared a certain mentality, that wanted to embrace change. And then they put on paper, and later online, a set of principles that are at the foundation of how to be agile.

[00:06:04] Agile does not mean faster. This is the first principle that I like to talk about. It means embracing change and creating space for flexibility, accepting that we cannot control all the variables. Agile doesn't mean that the development, design or problem-solving work itself will be done faster. Many companies struggle with this topic. There's a strong belief in some of them that by implementing agile methodologies we will help the company deliver the same features faster. That is wrong. The work to develop the feature is the same. But it does help very much with making sure that we are delivering the right solution faster, and we do that by making mistakes, by doing it in an iterative way, and by collaborating through the process with the customers. It means not locking the solution, and leaving space to adjust and react to change.

Timeboxing

[00:07:03] This is where the distilled part of my presentation comes in. When I look at stripping everything down from the main known agile frameworks, these three core practices come to mind, and I consider them to be the three pillars of being agile. They are timeboxing, value delivery and continuous improvement.

[00:07:31] Let's start with timeboxing. A timebox is a previously agreed period of time during which a team works steadily towards the completion of a goal. That's the definition. Rather than allowing work to continue until the goal is reached and evaluating the time it has taken to get there, the timebox approach consists of stopping the work when the time limit is reached and evaluating what was accomplished. When planning in the context of software development, we can either think of what we want to build, fixing the scope of it and clearly defining the quality at which to build it, and then we do it until it's done. That's the opposite of a timebox. We cannot be sure how long development on something specific will take.

[00:08:20] This can be a very attractive way to work for engineers. You probably have had those experiences: some engineers really love just taking the problem and working on it until it's done. It's a very natural thing, but it's too unpredictable for the business itself. In order to create predictability, and a space to react to change that is not chaotic in its own way, we can use a fixed period of time as our guide. We fix the time, we uphold our quality standards and our work ethic, and we allow the solution to be flexible. One of the most common timeboxes everybody has worked with is a sprint, but it's not the only one.

[00:09:00] Here are some more examples. One example that might have come up, but maybe people haven't thought about it as a timebox, is timeboxing a task. It can be called a spike in some frameworks. It means we have a difficult, complex, unknown problem to solve, so instead of spending an infinite amount of time going down trying to solve it, we timebox it. We give it two or three days for someone to investigate and go deeper into it, and at the end we check in and decide what we want to do next based on the information that we've accumulated in that timebox.

[00:09:36] An iteration, for example, in the context of agile is a timebox that usually takes one to four weeks. It can be called a sprint, but if you don't want to call it a sprint, or you don't want to do Scrum, or you have a team that is very against any Scrum terminology, it's an iteration. It doesn't have to be a sprint. Another concept is the increment. This comes, I think, from Scaled Agile. The idea is you have a sprint of sprints, or a timebox that contains multiple other timeboxes. Quarters can also be timeboxes. If you use OKRs, you are probably used to that as well.

[00:10:20] What do we do inside the timebox? We work towards a goal. We build something that can provide value and from which we can receive feedback that will then inform our next timebox goals. Okay, but what if we cannot deliver the scooter in this image in one sprint? I have heard a lot of teams be so concerned with the fact that none of this makes sense, because the way they develop, they cannot deliver something valuable on its own into the hands of a customer in one sprint. The majority of teams use two weeks. That means that maybe the sprint, or the duration of it, is not the right timebox for value delivery in your case. Of course there could be other reasons, but it depends on the complexity of your product.

[00:11:09] When we think about timeboxing and delivering value in that timebox, we can start backwards and look at the timebox in which you can predictably deliver value now in your product team, even if that means a quarter. It could be that big. It could be that it takes you that long to put together all the moving pieces. And once that is clear to you, then you can move that value delivery towards smaller and smaller timeboxes. That is one way of improving this way of working.

Value delivery

[00:11:42] The second pillar that I usually talk about is value delivery. All the practices that we have should serve the delivery of value to the customer, the business itself, or internally to other teams and systems. How do we make sure that we are building the right things? There are so many different options and flavors when we organize our own value delivery ways of working, but one good place to start is answering the three magical questions of why, what and how. Why usually informs your business value. What is your acceptance criteria, also a great place where you can split pieces of work with the most value included in each of them. And the how is the solution, the specs. That could be technical specifications, the design.

[00:12:37] For areas where you can apply this logic, you could start small. Look at your tickets in Jira, or other systems that you use, and make sure they can all answer these: stories, features, but also technical tasks. Even bugs, at some level, could answer these three questions. Then you can go bigger. Look at your team's ways of working and ask why. Why do you need them? What is actually needed in order to achieve a certain result, the outcome? And how are they implemented? You can continue this way, asking these questions to try and find the value in the work we do and the way we do it.

[00:13:19] I really love this drawing. It is not made by me, it is made by someone from Crisp, but it shows a very interesting dilemma in value delivery. We have output. We work a lot, and it's very natural to work with output. It's much harder to learn how to work with outcomes. Output does generate outcome, and it does then generate impact, but if we focus too much on output we get into a situation where, well, customers do not want features, they want you to solve their problems. Then if you spend too much time on the impact side, on your bottom line and revenue and KPIs, an organization can lose sight of its customers and start solving its own problems. The sweet spot is to be customer-centric and outcome-driven.

[00:14:19] How do we know when a product team is focusing on outcomes? It's when we're organizing the work around objectives related to customer outcomes, when you work in product teams that engage with customers directly, when you remove, or at least try to avoid, organizational silos that create handovers, and when you understand your value streams. One great thing that you can try there is value stream mapping workshops. They put all of your teams together, and you try to map everything from idea to product delivery and product releases, see all the steps in between, and understand where your waste is and how you can get the idea into the hands of the customer as fast as possible.

[00:15:06] Another thing to consider when thinking about value delivery is the simple Gherkin language. If you haven't used it before, I challenge you to try it on at least a couple of your features. Creating value-based features means writing them in a way that we see the value very well. I'm really sorry we're not in a live audience where I can ask this question, but if you look at the sentence, where do you think the value is? The value is in the "so that" part. There is a reason why the customer or the user needs a certain action to be performed, and we need to focus our efforts on that area.

[00:15:51] Another important practice is definition of ready and definition of done. This can be applied to all types of tickets, and also to product areas, for example to design work, to the product itself. Tickets need to meet the definition of ready criteria before they can be moved to the implementation phase. And we use the definition of done to create a common understanding of when something is done, meaning when the work is completed. The definition of done needs to be created with the product or system in mind, considering the context of your product and system. Usually developers are very involved in that, and product managers and designers are more involved in the definition of ready, but I really think this should be a whole-team effort.

Continuous improvement

[00:16:41] The third pillar that I like to talk about is continuous improvement. This is the most important one. I left it for last, but experimentation is the most important agile concept. We have to continuously check how things are going and try new things, to make sure that we don't just follow whatever process we have in place for the sake of following it, but because it actually brings us value.

[00:17:09] The most common continuous improvement meeting is the retrospective, which usually happens if you use Scrum. I have seen teams that don't use Scrum that have retrospectives, which is great, but I've mostly seen it done just at the development team level. I would like to challenge everybody to think about continuous improvement at all levels of your organization that you can be a part of. It could be in the design team, it could be at the product team level, it could be at the managerial level, it could be at any level of the organization. The important thing is to continuously think about what else we can try, and how this is going.

[00:17:53] When you do a retrospective session, some ideas here that I wanted to share are about listening, rinsing and repeating. First, inspect the previous timebox. That's usually what we do. We then analyze, think about root causes, and try to prioritize some areas of improvement that will bring us the most value, and then implement gradual improvements. But there are some pitfalls to be aware of here. Looking through all my experience of running retrospectives for different teams, it can happen that we focus on things that the team cannot affect. Sometimes sessions of ranting, or complaining about what is wrong in general, can be good and very refreshing. But if we do that every single time we do a retrospective, it's not a great idea, because it makes us resentful and maybe ironic and condescending about the situation that we're in. Focusing on the context of your team and things you can affect, finding things that you can take action on, can be very empowering.

[00:19:02] Sometimes it can happen that we never make time to try out any of the improvements we agree on. We go through the retrospective session, we come up with some ideas of what we want to try, but then nobody finds the time to actually implement them. And sometimes there's no follow-up. Let's say we tried something new, a simple example, a new type of board in Jira, and we just go with it and never come back to it to evaluate: was that good? Did it solve the problem that we had? We forget sometimes to talk about that. And some of these experiments can be failures. We can try something and it won't work for us, and it's totally fine to backtrack and get back to how things were before. If you look at retrospective items for, I don't know, the past six months in your team, and you see the same subjects and no change, then you are not continuously improving.

Takeaways

[00:20:01] These were the three main pillars, and I would like to summarize and end my talk with a simple takeaway. If you work in an organization where you have the freedom and you're empowered to review, change and experiment with your ways of working, please do that. If what I've shared today can inspire you, maybe try to ask some questions, try to see what timeboxes you're using or how you're delivering value. Try to look at it from a simple, productive ways-of-working perspective. It doesn't have to be Scrum, it doesn't have to be Extreme Programming, it doesn't have to be SAFe. It just needs to be simple and productive for you and your team.

[00:20:47] But then there may be some of you in here that work for enterprises that have very set-in-stone processes that you, from your place in the organization, cannot change at a systemic level. If you can't affect the whole process, you might look at what I've talked about today and think, well, very nice, but I can't do any of that, I don't have the power to do any of that. What you can do then is try to automate as much of it as you can. Look at what you can affect, and for the parts of the process that are very reporting-heavy, KPI-heavy, that require you to do things that don't feel productive for your team, try to automate as much of it as you can. I really hope that could be a takeaway for some people here. And that is the end of my talk. Are there any questions?

Q&A

[00:21:42] Host: Thank you very much, Ligia. I like that. It reminded me a lot of what we do at UXDX and what we're trying to achieve, which is making sure that people can improve their processes, because I fully believe that the process often is the dictator of how good an outcome you'll achieve. Just to reiterate, if you have any questions please post them in the chat box on uxdx.com, or whichever platform you're watching this on. But I want to jump in: you finished off saying sometimes teams don't follow up and implement the ideas that they have in their retro. Are there any tips you can give for making sure that people do, or making sure they have the time? Because it's always, well, we have this deadline to hit, we have this deadline to hit. Is there any advice that you can offer people?

[00:22:33] Ligia: Yeah, for sure. There are a few different things you can try. One of them would be to create some sort of community of practice within your organization: people from different roles that care about ways of working, who create a roadmap for these improvements if they're bigger. If they're small and they can be done just within your own team, then allocating time. Usually a 20% allocation works for a lot of teams that I've worked with, and that can be used for learning and for development of your own projects. This can be something you can advocate for if the rest of your backlog is so full and you don't have any other time. These are two ideas, but using a roadmap is a great way. Like we have a roadmap for our product, we can have a roadmap for our process.

[00:23:22] Host: And how would you sell it? I can just picture going up to some of my past companies: I've got this roadmap and I want 20% of my time. How do you sell that? Because to the business that can often be quite a hard sell; they're going, no, that's going to distract you, go build what we're asking you to build.

[00:23:42] Ligia: I think there are ways to measure throughput and efficiency of how we're building things. If you can do that, please do it. Track how productive you are in your team, and if you have identified certain practices or processes that you feel take too much of your time instead of development, that is a really good argument. I once managed, in one company, to calculate the man hours that were spent on dealing with a very inefficient process, and advocated from that point of view. It depends who you're selling it to. If you're selling it to management that is very numbers-focused, then try to find the numbers, try to make those work, and try to present it from that perspective.

[00:24:25] Host: Brilliant. And then the other angle, for me: what I've noticed is that what you can manage within your team isn't the big stuff. It isn't the move-the-needle type of things. It's the stuff that's outside, the stuff that, as you said, keeps coming up and becomes a bit of a moaning session. But that is the big stuff, the stuff that can move the needle. What can teams do to try and get some change happening there, which is outside of their direct control?

[00:24:57] Ligia: Okay, so I'm a very big fan of asking for forgiveness instead of permission. If there is some flexibility in things that you can do in your team, just go ahead and do them, if you know that they're not going to affect something very business-critical, of course. Become that team that sets an example. If you can advocate for change inside your team and make your team work differently than everybody else, in a way that has an impact that you can measure, you can get everybody in your team aligned on: let us be that team that proves that we can do things differently and better. And then use that. Communicate it across your organization, show those results, go and talk at whatever town halls you have, wherever you can get in there and talk about it.

[00:25:48] I have seen this work before. It is a tough one, but I think it's the only one where you can break that status quo. Of course, if you have a good product manager involved, or an engineering manager that does, then we're talking about levels of people management that you can get involved in this, and the more the merrier. But if you don't, let's say, like you mentioned, you can't convince them, just do as much as you can to prove that you can do things differently.

[00:26:19] Host: Brilliant. Yeah, a lot of times it's like, whoops, I didn't know I wasn't supposed to do that.

[00:26:25] Ligia: Yeah, exactly. Just go ahead. I do that with J[?] all the time, wherever I go.

[00:26:31] Host: Brilliant. Well, I think that brings us to time. Thank you very much, Ligia. That was a fantastic presentation. I really enjoyed it, and I hope everybody did as well.

[00:26:39] Ligia: Thank you so much.