Pawel Brodzinski on Leadership in Technology

Whatever it takes to lead a team, build a product, and run a business

Tag: retrospective

  • Retrospectives Reloaded

    I’ve read and heard a lot advice on running better retrospectives. I’d even go that far to say that if you speak at agile event and you want an instant hit “how to run a good retro” should be very high on your list of potential topics.

    After all, this whole “getting better” thing seems really important to everyone and improvement is almost always a struggle for teams. A retrospective is a nice package; it’s pretty self-explanatory, it has a good name and it’s open-ended enough that you can adjust it to your needs.

    It’s not a new concept though. I was doing post mortems back then when agile was just a word in a dictionary. Same goal, different package. Well, maybe not that sexy, and that’s exactly why you should rather jump on a retro bandwagon to win the crowds.

    Anyway, the problem with vast majority of stuff I’ve heard or seen about running better retrospectives is simple: they are all recipes. You may apply them and they either work or not. Even if you’re lucky and they happen to work once, they quickly wear out. After all, how many times do we laugh at the same old gig?

    Then, we’re back to the square one. How to revive the next retro one more time?

    It’s because we get the wrong advice on retrospectives over and over again. It shouldn’t be “try this” or “try that.” The real magic happens when the thing you do during a retro is fresh and everyone gets involved.

    Both things are often surprisingly easy. You can count on people’s engagement when you don’t push them out of their comfort zones too far, e.g. I would say that singing in front of the team probably isn’t the best choice you might make. But all sorts of drawing are usually safe.

    And being fresh? Just think about all these funny ideas you discuss by the water-cooler. Playing an act, recording own version of movie classics, a concert, a cooking event, or cleaning a randomly chosen car on a parking lot are all such concepts. People were enthusiastic to sign up for such things. Wouldn’t they be so if it was a part of a retro?

    However, if you’re going to use a cooking event as an awesome idea for the next retro you understood nothing. Go, read the post again from the beginning. I don’t want to give you any recipe. I’m going to simply point the fact that every goddamn team on the planet Earth has a ton of fresh ideas for their next retro. It’s enough if you retrieve a single one of them.

    In fact, it’s even better. If you use one of those crazy ideas your team discussed a couple of days ago during lunch, odds are they will eagerly sign up for it.

    This is why I’m not going to be stunned with the next “better retros” session. Because, you know, I have such a session a few times a week. I just pay attention.

  • Cadences and Iterations

    Often, when I’m working with teams that are familiar with Scrum, they find the concept of cadence new. It is surprising as they are using cadences, except they do it in a specific, fixed way.

    Let’s start from what most Scrum teams do, or should do. They build their products in sprints or iterations. At the beginning of each sprint they have planning session: they groom backlog, choose stories that will be built in the iteration, estimate them etc. In short, they replenish their to do queue.

    When the sprint ends the team deploys and demos their product to the client or a stakeholder who is acting client. Whoever is a target for team’s product knows that they can expect a new version after each timebox. This way there is a regular frequency of releases.

    Finally, at the very end of the iteration the team runs retrospective to discuss issues and improve. They summarize what happened during the sprint and set goals to another. Again, there is a rhythm of retrospectives.

    Then, the next sprint starts with a planning session and the whole cycle starts again.

    It looks like this.

    All practices – planning, release and retros – have exactly the same rhythm set by the length of timebox. A cadence is exactly this rhythm.

    However, you can think of each of practices separately. Some of us got used to the fact that frequency of planning, releases and retrospectives is exactly the same, but when you think about this it is just an artificial thing introduced by Scrum.

    Would it be possible to plan every second iteration? Well, yes, why not? If someone can tell in advance what they want to get, it shouldn’t be a problem.

    Would it be a problem if we had planning more often then? For many Scrum teams it would. However, what would happen if we planned too few stories for the iteration and we would be done halfway through the sprint? We’d probably pull more stories from backlog. Isn’t that planning? Or in other words, as long as we respect boundaries set by the team, wouldn’t it possible to plan more frequently?

    The same questions you can ask in terms of other practices. One thing I hear repeatedly is that more mature teams change frequency of retrospectives. They just don’t need them at the end of every single sprint. Another strategy is ad-hoc retro which usually makes them more frequent than timeboxes. Same with continuous delivery which makes you deploying virtually all the time.

    And this is where the concept of cadence comes handy. Instead of talking about a timebox, which fixes time for planning, releases and retrospectives, you start talking about a cadence of planning, a cadence of releasing and a cadence of retrospectives separately.

    At the beginning you will likely start with what you have at the moment, meaning that frequencies are identical and synchronized. Bearing in mind that these are different things you can perfectly tweak them in a way that makes sense in your context.

    If you have comfort of having product owner or product manager on-site, why should you replenish your to do queue only once per sprint? Wouldn’t it be better if the team worked on smaller batches of work, delivering value faster and shortening their feedback loops?

    On the other hand, if the team seems mature frequency of retros can be loosened a bit, especially if you see little value coming out of such frequent retros.

    At the same releases can be decided ad-hoc basing of value of stories the team has built or client’s readiness to verify what has been built or on weather in California yesterday.

    Depending on policies you choose to set cadences for your practices it may look like this.

    Or completely different. Because it’s going to be adjusted to the specific way of working of your team.

    Anyway, it is likely, that the ideal cycle of planning, releases and retrospectives isn’t exactly the same, so keeping cadences of all of these identical (and calling them iteration or timebox) is probably suboptimal.

    What more, thinking about a cadence you don’t necessarily need them to be fixed. As long as they are somewhat predictable they totally can be ad-hoc. Actually, in some cases, it is way better to have specific practice triggered on event basis and not on time basis. For example, a good moment to replenish to do queue is when it gets empty, a good moment to release is when we have a product ready, which may even be a few times a day, etc.

    Note: don’t treat it as a rant against iterations. There are good reasons to use them, especially when a team lacks discipline in terms of specific practices, be it running retros or regular deployments. If sprints work for you, that’s great. Although even then running a little experiment wouldn’t hurt, would it?

  • The Purpose of Retrospectives

    Those of you who read Software Project Management regularly know for sure that I have sort of experimentation attitude. I like to try different things, see how they work and, if they sort of do, share my experience here with you. I’m particularly happy with a bunch of such concepts, one of them being ad-hoc retrospectives.

    This story is more than a year old, but recently Bernd and Ilja from it-agile reminded me about it with their comments under the post.

    A short version of the idea is that, instead of doing regular retrospectives bi-weekly, monthly, or whatever your cadence for retrospective is, you do a very short and focused ad-hoc discussion on a single problem raised by any team member. The outcome should be similar to what you get from a regular retro – an action point, or a bunch of them, aimed at solving the issue. In my case the whole mechanism proved to work very effectively. If this teaser sounds interesting I strongly encourage you to read the full story.

    Both Bernt and Ilja pointed that I shouldn’t call it a retro. As Ilja puts it:

    Retrospectives are more than just meetings where you solve problems you are already aware of, anyway.

    Well, I guess we are in full agreement on this one. The only difference is I actually believe that even with ad-hoc retrospectives we are (usually) solving problems that we aren’t yet aware of. At least we aren’t when we launch the retro. Pretty often we start with just a symptom. Someone spots something that they think is worth discussing. So here we are – at ad-hoc retro.

    First, we don’t have to agree that this is a real problem and often, initially, we don’t. Thus a discussion. Even though we actually are focused on this single starting point, we dig deeper trying to find some common denominator for our views.

    Second, as I’ve already told you, we usually start with just a symptom. Quite often we are yet to discover, and address, a root problem.

    Finally, we try to come up with some action points to fix a root cause we agree on.

    Now, I happen to facilitate a bunch of regular retros recently and all of them seem to follow similar pattern, no matter the team or the organization. We start with a handful of things we like or don’t like, try to cluster them somehow, look for root causes and address them. However, it all starts with observations people make.

    It’s not some kind of magic that tells us what we are doing wrong. It’s not an outsider who comes and blesses us with an epiphany. It’s not a scientific process which makes us come up with the right solution. It’s the team that finds it out by themselves.

    In both cases: regular and ad-hoc retros the outcome is similar, the process is similar and even the same people do the job. The main difference is granularity. While during a regular retro we try to cover things which happened during a specific time-box, on ad-hoc retrospective we start with just a single idea. An idea we would write down on the on a sticky note at the very beginning of the next regular retro anyway. In other words we would bring it up as well, no matter the process.

    I just wanted to add that another difference is, that during typical retros, not every problem is acted on. We usually try to focus just on a bunch of most important things at the moment. However, on a second thought it works the same with ad-hoc retrospectives. Sometimes after a brief discussion we just decide to leave a thing alone for the time being. We either don’t share views of a person who proposed the issue or don’t see any action points that we could agree on or whatever else. So similarly to regular retrospectives the outcome can be “do nothing” too.

    If nothing so far convinced you that both concepts are surprisingly similar I have a question about a purpose of retrospectives. It is improvement, isn’t it? We want to do better in future that we’ve just done. If so, we can perfectly do this job using both approaches. Of course, depending on a team’s maturity I would go with one or another, but that’s a totally different story.

    Of course we can bring it down to some orthodox discussion over definitions, but don’t count in. I’m more into solving problems than arguing over definitions. It just feels more useful.

  • What Makes a Good Retrospective

    The other day I facilitated a retrospective for a fellow team. My goal, as a facilitator, was basically to help them to suck as much value out of the meeting as possible.

    Now, before we move on, a picture from a past. I recall a bunch of retrospectives which looked like this: a whole project team met for a longer time and everyone was asked what was good about the project and what needed improvements. Then, one of project leaders wrote it down in a document uploaded the document to a server and finally everyone could just happily forget about the whole thing.

    Does it sound familiar? It probably does for many of you. Does it add any value? Um… next question, please. Isn’t it a complete waste of time? Oh well… If you don’t plan to make any use out of retro, don’t even start it.

    So the question is: what makes a retrospective valuable?

    The answer is actually pretty simple.

    Value of retrospective can be measured in terms of changes sprung by it.

    It basically means that the team decided to act, to try something new, to deal with a problem. It doesn’t necessarily mean that it will be an overnight success. Most likely it won’t. But at least they gave themselves a chance. They might even totally fail with the first approach, but they kept trying.

    Note: when I say changes I think about things which are really changing, not about those we just say we’re going to change but don’t do so.

    Anyway, another problem pops up. We want changes, but how to make them happen?

    Um, that’s sort of easy. Remember about a few simple rules:

    • Don’t chase too many goals. It’s usually tempting to cover each and every issue we spotted. After all we have all the enthusiasm and we want to improve. The problem is that when we commit to too many tasks we’re going to fail at many of them. Then, we’ll get discouraged that we don’t see any results of retro and our enthusiasm won’t be that enthusiastic next time. If there’s going to be the next time, that is.
    • Assign people to tasks. Task with no individual attached to it isn’t really assigned. A decision that the team would do something means that, well, someone else can do it, not necessarily me, right? Tasks assigned to everyone most likely end up not being done by anyone.
    • Have deadlines. Ask when you’re going to be done doing this or that. Keep your deadlines possibly short, yet definitely reasonable and achievable. Stating that something will be done in 6 months is meaningless. In 6 months I can work in the other place of the planet. A couple of weeks are a time frame we understand way better than a few months. If tasks don’t suit short time frames, chop them to smaller ones.
    • Verify outcomes. When deadlines pass remember to discuss with the team what was done, what was the outcome, what else, if anything, has to be done about discussed issues. Again, I don’t assume that all the problems are solved. You may end up with a solution, which didn’t work, and will to try something different. You can also end up with solved problem but the least you should do is saying so. Starting the next retro with such a summary of outcomes from the previous one is a good practice.
    • Repeat. One retro is just a quick fix. If you need sustainable change do retrospectives regularly. I don’t believe you are so perfect that one retro is enough to solve all the issues you might possibly have.

    In short you want to end up with a short list of actionable work items assigned to people and then check how you’re dealing with them.

    Of course sometimes it just sounds that easy. Sometimes you need to work hard to avoid blame game, get focused on specific issues, cut out longish but pointless discussions, learn to accept things you can’t change etc. Sometimes you will need to try different formats to animate communication or build basic trust between team members or change their attitude to anything positive. Sometimes it may be damn hard work to do.

    But as long as you aim for the goal and your actions help in achieving it, you should do pretty well.

  • The Kanban Story: Retrospectives

    Chapters of The Kanban Story are published pretty irregularly these days but it doesn’t mean the story is over. This time, encouraged by Michael Dubakov’s great post on retrospectives, description of our retrospectives.

    The first thing is we generally don’t hold meetings. At all. This also means we don’t have retrospective meetings. At all. Also, if you asked the team about retrospectives, you’d get mixed answers. Some would answer positively others negatively. Yet I keep saying we do have retrospectives.

    The pattern is very simple: every time someone sees an issue which seems worth reviewing we start discussion. Here and now. Without waiting for a meeting or something. Then people who are interested join the discussion. We also poke people who we need feedback from and they haven’t yet joined us. We try to finish this retro with some action points, but sometimes our action point is “do nothing” as we agree we have no quick idea how to do things better than we already do.

    Doing nothing about the issue isn’t a big deal since when it is important it’s going to come back soon.

    These retrospectives are, by design, very short as they touch only one problem each. We usually finish in less than 5 minutes; hardly any of them lasted longer than 10 minutes.

    Retros are done on the fly. On one hand we don’t prepare ourselves to the discussion but on the other we start talking when the problem is fresh which compensates lack of preparation.

    Prerequisite to this approach is co-location. If you start talking and expect to be heard, everyone should be in the same place.

    Now, the tricky part: interruptions. Sometimes it happens we interrupt others when launching retro. We all know it is costly. However, an interesting thing I’ve noticed is that we’re pretty good at “turning ourselves off” when we’re in the zone. It happens over and over again that we need to poke someone to get him involved in discussion as voices in the room aren’t enough to break into the zone. This means we limit a number of interruptions only to those situations when we really need someone’s input.

    I’m not sure why it works that way. I don’t know if we worked that way from the beginning or I should attribute that to maturity of the team. The trick is it works.

    Of course this is only one of many possible approaches to retrospectives in Kanban. I recommend reading Michael’s article along with comments if you want to learn others.

    Read the whole Kanban Story as well.