There's a Retrospective for That

Ever feel like Scrum isn’t a good fit for your team? Are you annoyed by the fact that Scrum seems to disregard comprehensive design? If only we had time available to devote to defining a better process. Oh wait, we do. There’s a Retrospective for that.

How did we get here?

I received this article from a friend who was curious about my take.

Of all the various points made in the article, the one that stuck with my friend the most was the implication that agile hasn’t changed in twenty years. Technology changes at such a rate that most find it impossible to keep pace. The projects that companies undertake today weren’t even possible twenty years ago. So how can the mindset defined twenty years ago still be relevant?

In my friend’s words:

“Very little throughout history has remained relevant in the long run because of changing time and needs.”

Fortunately, it’s almost like the Scrum guys and the agile peeps thought of this ahead of time. There’s a Retrospective for that!

“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”

-Agile Manifesto

“The Scrum Team identifies the most helpful changes to improve its effectiveness. The most impactful improvements are addressed as soon as possible.”

–Scrum Guide

Several agile methodologies include an event that allows the team to adapt to keep pace with the times.

I Always try to Fix Things

My original idea for this article had been to do a rebuttal of sorts, and I guess in a way, that might be what this is, but it likely won’t take the format one will expect in a rebuttal.

While drafting this article, I realized that I’m less interested in debating a point than I am in fixing an issue. Much to the distress of my husband, I commonly play devil’s advocate in conversations, but this isn’t exactly a conversation. To take that stance with an online article feels a bit wasteful.

“Those convinced against their will are of the same opinion still.”

-Dale Carnegie

Anytime I read one of these “Agile is Dead” type articles, I have this voice in my head that just keeps yelling “impediment!”

Impediment! Impediment! IMPEDIMENT!

It’s like I can’t turn off my Scrum Master instinct. This thought process is very similar to how I function in the daily standup. I can’t help but see all the nails sticking out of all the foreheads.

I believe this is because I’m a problem solver. Another of my aspects that my husband sometimes finds irritating. Come to think of it, I’m probably fortunate that he puts up with me at all.

But I digress. My point is that my problem-solving skills compel me to fix all the impediments I identify in these articles. So instead of crafting an unwanted rebuttal that is likely to fall on deaf ears, this article will advise people of potential methods to overcome remove these impediments. If you find yourself in a similar situation to that described by the author of the referenced article, you’ll hopefully find some information here to help improve your situation.

I’m going to attempt to get rid of the nails.

Posterior Positioning

I must admit that the original author’s storytelling skills are impressive. I’m sure every reader cringed at the description of the daily standup.

I felt my eyebrows compress in disdain for the Scrum Master that sat while expecting the rest of the team members to stand. I mean, the gall of some people to break such a cardinal rule.

But then my senses came back to me a bit. This “rule” that everyone stands in the daily standup isn’t legislation; it’s simply a type of working agreement.

Where do these working agreements typically get established and tweaked? You guessed it; there’s a retrospective for that.

This specific best practice has a particular objective. The thought is that it’s much more likely the meeting will stay within the fifteen-minute timebox when participants are standing uncomfortable vs. sitting in a nice comfy chair.

If this team doesn’t have an issue staying within the timebox, there may not be a reason for anyone to stand. However, based on other information in the article, it seems this team could benefit from methods to keep meetings short.

The next question to ask would be, is the Scrum Master aware of the working agreement? Depending on the team, they may not have documented these established norms. Before judging someone for breaking working agreements, make sure they’re aware of them. Based on the judgmental tone, I can only assume that the rule breaker is fully aware of the incongruity.

So, whose job is it to enforce these working agreements? It’s the responsibility of the whole team. Luckily, in this case, the team is armed with a hockey stick ample of whacking those that sit when they aren’t supposed to. Speaking of that elephant in the room, perhaps we should address it next.

Hokey Hockey Stick

To be honest, I feel a bit silly writing a whole section based on a hockey stick, but the original author features this stick as the straw that broke the camel’s back. So, I’ll spend a few words on this hokey hockey stick.

I don’t know where this originates, but there seems to be many gimmicky activities thrust upon agile workspace. Such as wearing a rubber chicken around your neck for punishment for being late to Scrum or tossing a stuffed moose in standup as a sort of randomized speaking stick.

I’m not immune to having gimmicky ideas myself. I once brought in a gavel as a means of drawing attention to decisions in the hopes we’d be more likely to stick to them. Needless to say, that went over like a lead balloon for some of the team members.

When these gimmicks rub someone the wrong way, it’s generally one of the two following situations:

1. Leadership came up with this idea, and everyone just went along with it, even though it provides no real value and the entire team thinks it’s dumb.
2. The majority of the team finds value in the practice, and just one or two people roll their eyes.

Given that everyone in the article sighs in relief as they rid themselves of the stick, I think we can safely assume we’re talking about the first situation. Gee, it would be nice if there were an opportunity where the team could make changes to their process to eliminate waste. Oh yeah, that’s right, there’s a Retrospective for that. I hope we’re all starting to see a theme at this point.

If by chance, you happen to be the sole person that has a hatred for this hockey stick, I would suggest you evaluate your level of disdain for the practice. It seems a small price to pay if it brings your team members joy.

Perhaps said hockey stick has become a focal point embodying a litany of other issues you have with the team.

Some individuals won’t be a good fit for some teams (and vice versa). Find another group if you just can’t seem to gel with these team members or their culture. Either transfer within the company or find a new employer.

Micromanagement

If the words “and management is watching” are ever uttered in my general direction, I’m going to be inclined to respond with “tell them to watch me walk out this front door.”

As a proponent, I’m obligated to point out that the agile manifest includes a bit about trusting people to get the job done.

“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”

–Agile Manifesto

However, as Kurt Cagle demonstrates in his article, not every company successfully instills these principles. If your standups devolve into status meetings that focus on individual contributions, change the format to escape that anti-pattern.

How should a team impose such a change? You guessed it! There’s a Retrospective for that.

Focusing on work items instead of individuals can help shift the focus away from managing people and back to managing the work.

Another tactic for avoiding micromanagement is to distract the micromanager with purposeful work. If your Scrum Master is too focused on status updates, distract them with some team impediments they can remove. The team can gain a bit of breathing space, and if the Scrum Master successfully removes those impediments, the team will benefit doubly. It’s like feeding two birds with one scone.

Design Deficiency

The reaction that agile is missing a process to ensure proper design is a common opinion. On the surface, one might think that agile doesn’t treat design as a first-class citizen. However, allow me to draw your attention to this agile principle:

“Continuous attention to technical excellence and good design enhances agility.”

-Agile Manifesto

Ah, but there I go again, pointing out how things should be instead of meeting people where they are. What I meant to say was, wow, that sounds really hard.

In fact, it sounds like we’ve discovered a deficiency in our process. If we know we need better design, but we aren’t sure exactly what that should look like, perhaps we could collaborate as a team to find somewhere (anywhere) to start. From there, maybe we can enlist the help of the ole scientific method to make incremental changes as we see fit.

Wait for it - there’s a Retrospective for that!

I will mention some related tidbits that teams could potentially find useful. Design is a general term encompassing several concepts like big picture thinking, architectural design, UI/UX, and technical implementation details.

If the team struggles to define the functionality that could deliver customer value, check out Human Centered Design or The Design Sprint.

If you have a Product Owner that can define what to build but tends to throw the stories at the development team with no context, consider creating stories collaboratively in a story writing workshop or using story maps to show how everything fits together.

If it feels like the team never gets around to discussing technical implementation details, consider rebooting the second half of your Sprint Planning meeting. According to the scrum guide, the third topic to cover in Sprint Planning is “How will the chosen work get done?” It’s at the team’s sole discretion to answer that question, so have whatever design conversations are necessary to get everyone on the same page.

Try to understand the root cause of the gap you’ve identified in your process. From there, experiment with different ideas and iterate toward an approach that works for your team.

Mandatory Meetings

Scrum is usually the framework that gets the most flack for having too many meetings. The thing is, those meetings are all designed with a specific goal in mind. If you find no value in those meetings, it’s likely indicative of a more significant impediment, or your team accomplishes that objective differently.

No customers (or customer proxies) showing up to the Sprint Review? The meeting will feel like a waste (and likely is). However, the root cause isn’t the meeting itself; it’s the lack of customer involvement. Did the customers stop showing up because the team wasn’t delivering valuable working software? Perhaps the customers and stakeholders work so closely with the team that demoing stories as they go, and thus the Sprint Review feels a bit redundant.

Understand the objective of each event and determine if it could provide value to the team. If so, uncover the root cause for the meeting not delivering the expected value. Resolve that impediment before continuing to waste time in unproductive meetings.

Hopefully, it’s apparent at this point that the team should control the process through the Retrospective. If you’re drug to a ton of meetings that provide no value, discuss it in the Retrospective. If that doesn’t work, vote with your feet. Indicate your opinion of the meeting’s lack of value with your absence.

Perpetual Planning

On the one hand, we’ve said that agile is flawed because we spend too much time planning. On the other hand, we point out that the lack of design time is a flaw. These two points seem to contradict each other.

Let me make some assumptions based on my experiences with other teams. I suspect that a lot of time might be spent pointing stories and committing to work. After all of that is done, no time or energy is remaining to have design discussions.

If that is the case, I suggest flipping the script. Do the high-level discussions first, potentially using a story map or architectural design diagram. Provide any context needed to understand the deliverable. Allow time for questions. After a high-level discussion, go down to the story level. Estimating should go faster with the additional context.

There is a generally accepted way to work a jigsaw puzzle. First, you look at the picture on the box. Then you dump and organize the pieces. You might organize by shade, color, or recognizable patterns from the target image. You’ll separate the edge pieces as you go. You’ll want to keep the box close at hand to reference the ultimate objective. Next, put together the edge pieces. Then assemble groups of similar pieces. Place completed sections within the frame approximately where they go. Eventually, the whole puzzle starts to come together. As more pieces go in, it becomes easier to place the next.

For some reason, product owners tend to jump straight to the user stories. It’s akin to showing random seemingly unrelated pieces to the team and asking how hard it will be to find where they go. The frame, in its non-existent state, can provide no context. We don’t bother to tell the team how many total stories we have, so they don’t know if they’re looking at a 23-piece puzzle or a 1500-piece puzzle. The worst part, though, is we never show them the picture on the box.

As we discuss each story, the team tries to relate them to each other and build a mental model in their minds, but it happens in the most confusing and inefficient way possible.

Do everyone a favor and start with the picture. Start with the high-level context. Do this when everyone is bright-eyed and bushy-tailed. Combine that with the minimum architectural conversations, and everyone will have a general understanding of the work they need to perform.

From this shared understanding, dive into the individual stories. Estimating and committing to work will become way easier once we are approaching it from the top down.

Customer Commitment

In the agile space, it’s common to try to get the scrum team closer to the customer. Some proponents would say that the best-case scenario would be to have the customer sitting with the development team. As pointed out in the article in question, this is a hard commitment for the customer to swallow:

“The longer a project dragged on, however, the more likely that other demands would take more and more of that customer’s time, to the extent that their involvement became cursory at best.”

Generally, introducing the Product Owner role will solve this. The Product Owner’s sole responsibility is to manage the product backlog and plan out the vision for the product. They do so with customer input, but they can serve as a customer proxy and take on some of the responsibilities typically expected of the customer. This devoted role limits the amount of time the customer needs to devote to a product to be successful.

The risk introduced to a project due to lack of user engagement is not limited to agile projects. Regardless of what project management methodology you use, I can’t imagine it will be successful without some level of customer involvement.

Vanished Vision

Kurt Cagle touches on the lack of a visionary in the follow-up article Beyond Agile: the Studio Model.

Again, the role described here aligns with what Scrum defines as the Product Owner. This role is responsible for the vision of the product. They walk the line between stakeholders, customers, and the development team to define the roadmap.

If you feel like your team is missing something in the way of a visionary, discuss it in the Retrospective. Given that the Product Owner is part of the team, they should be present to hear the feedback.

Tiny Timebox

Scrum has several events that take place each Sprint. The shorter the sprint cycles, the more frequently the meetings occur, so it can start to feel like you spend more time in meetings and less time developing the product.

I worked with a team once that had one-week sprints. When everything repeats that frequently, it’s hard not to feel the time crunch.

The shorter sprint cycles also obviously limited the amount of work we could commit to, given that the goal was to complete it within one week. The unintended side effect was that our Sprint Reviews were a bit lackluster.

The team raised the Sprint Review’s perceived lack of value as an issue in the Sprint Retrospective (see what I did there?). As a result, the team decided to experiment with two-week sprints. As it turns out, two-week cycles worked better for our team.

Before everyone jumps straight to 52-week sprints, I’d be remiss if I didn’t point out the benefits of shorter sprints: the more cycles, the more opportunity for feedback and experimentation. Even if your team suffers from a lack of customer or stakeholder involvement, you should still be experimenting with ways to improve your process. By the time you get to four-week sprints, it becomes hard for the team to remember what happened since the last Retrospective. As you lengthen your sprints, you reduce opportunities to adapt your process.

The key is to manage the ratio between meetings and work time. Extending the Sprint timebox is not the only way to manage this ratio. You may also choose to limit the scope of work that the team commits to, thereby condensing meetings as you should only be discussing the work of the current Sprint. This reduction of scope will leave you with more time to finish less work.

The urge for longer Sprints is indicative of a team that is overcommitting to work. Thus, waste occurs in the planning meeting by discussing work that inevitably gets deferred to the next Sprint, where the team will likely address it again in the next Sprint Planning meeting.

Works Consulted

• The End of Agile
• The Scrum Guide
• The Agile Manifesto
• Team Ground Rules and Working Agreements
• It’s Not Just Standing Up: Patterns for Daily Standup Meetings
• Human Centered Design
• The Design Sprint
• Story Writing Workshops
• The New User Story Backlog is a Map
• Beyond Agile: the Studio Model

TLDR

Next time you find yourself frustrated by waste, yearning for a lacking concept, or feel that your process has gone stale, take note. Bring these items up in the Retrospective. Correcting these deficiencies is the purpose of the Sprint Retrospective.