Agile has played a huge role in my professional life over the past decade. The teams that I’ve directly managed and led have typically used some variation of scrum. Agile also fosters cross-functional collaboration with other groups. In the past, I’ve successfully used it to collaborate with departments including product design and content creation.
Although various people have different ideas about exactly what agile means, most agree that it’s a valid method to cut down on bureaucracy and get things done more effectively. Its flexibility also means that you can pick and choose which parts of the process you implement in your team. This, however, is a double-edged sword, so use it with caution.
Agile works well, but its cyclical nature leads to some challenges that practitioners need to be aware of for successful implementation. One of these challenges is the tendency for the team to repeat the same mistakes over and over again, sprint by sprint. Perhaps this happens because the daily standups give teams a false sense of security over the status of the sprint. As a result, though the team thinks they’re in control of the project, something systematically wrong may be happening in the background unnoticed.
Let me show you how this manifests itself in practice. One of the teams I worked with regularly faced issues with inconsistent UI across the software. It looked as if the implementation team, a cross-functional engineering and product design task force, couldn’t stick to the definitions set out in the style guide. The team introduced new components every time it developed a new feature instead of reusing and adapting existing ones. As a result, the software often failed “go-to-market” acceptance, and clean-up/polishing sprints became the norm. Now, this may sound like a silly problem, easily solved by using a checklist and reviewing the implementation plan before the team started writing code. The reality is a bit more profound, however.
Eventually, we realized what was causing the problem. In the spirit of being agile, most of the low-level specification work for the details of a feature happened in real time while the code was being written. Sometimes, that meant coming up with a UI solution on the spot. This often led the team to create custom UI components without much thought about the components’ place in the system overall.
This wouldn’t have been a problem had the team flagged the necessity of creating new widgets at the daily stand-up. We could have scheduled a review with the relevant experts to highlight and resolve potential inconsistencies in the design. Due to the limited time available for a daily stand-up, however, these issues often flew under the radar, surfacing only once the sprint had been put to bed.
From a high-level standpoint, the failure to follow styling guidelines probably seemed trivial. As it turned out, though, it was actually the symptom of a deeper-seated problem: the failure to understand that an issue was critical enough to be discussed at a daily stand-up. So how and when can you make the connection between these two problems so that you can start addressing them? This is where wash-up meetings come in.
What’s a Wash-Up Meeting?
A wash-up meeting happens at the end of a sprint to review its execution. Scrum calls this the sprint retrospective meeting and provides some guidelines on how to run it. Let’s have a quick look.
The meeting should take place shortly after the end of the sprint and last around one hour. The scrum master should chair the meeting and include the whole team. In a sprint retrospective, you’re supposed to cover three questions:
- What did we do well?
- What went wrong?
- What do we need to do to avoid making the same mistake(s) going forward? What lessons have we learned?
These guidelines are a good starting point, and they work well for a single agile team. The problem is that they aren’t enough when you have multiple task forces running in parallel, working on different parts of your software in a given sprint.
In an environment with multiple task forces, the cross-functional teams adhere to two processes. Each task force has its own internal process, but team members are also following the overarching processes of their respective departments. Software engineers can’t stop doing code reviews just because they’re on a given task force. Likewise, designers can’t make up their own design approval process, isolated from the rest of their team.
In this context, the sprint retrospective isn’t just a simple check-in. Instead, it becomes the starting point for a bigger conversation about the processes in place at your company.
Next-Level Wash-Up Meetings
If there’s one thing that agile has taught me, it’s that nothing is ever set in stone. Even the operational process of the team is subject to revision. Everything must be flexible. Thanks to this flexibility, processes naturally evolve over time to match the team’s work.
Wash-up meetings at the agile team level offer great insight into the process’ efficiency as it’s executed on a day-to-day basis. It would be foolish to not use the lessons learned to drive change at the department level. At the same time, you can’t just let each task force change the way the wider team works. Some type of control must be in place to avoid the chaos of a complete process breakdown. A high-level wash-up activity should take the feedback from every task force and implement it appropriately throughout the wider team.
Although department managers can do this on their own, that’s less effective than working with the leaders of each task force involved. After all, they have firsthand experience of the problems that the team encountered and are therefore more likely to provide good suggestions on how to fix them. During this exercise, you need to answer the following questions for every lesson learned:
- Is this lesson relevant for the whole team, or is it specific to the task force (maybe because of some special requirements for the project they’re working on)?
- Do we need to modify the team’s process to address this scenario, or was it a one-off?
- Can we fix it ourselves, or do we need help from other teams/departments to improve the situation?
Often, a single sprint isn’t enough to highlight systemic issues in the process unless multiple task forces highlight the same problem. More commonly, problems that recur across different sprints in different task forces highlight process issues. The UI consistency issue I discussed earlier is a good example of this.
The best time to hold the wash-up meeting is at the end of every sprint when the problems are still clear in everyone’s mind. Keep in mind, though, that you don’t need to take action on any of the suggestions immediately. You can wait it out and see if the issues were just a temporary blip. If it turns out they’re an indication of something more serious, though, you can spring into action.
My team and I took this approach to address our UI inconsistency issue. We noticed that the issue was happening time and again, and the sprint retrospective recommendations always pointed to having better specification documents at the start of the sprint. We went back and forth on this solution at the department-level review for a couple of sprints, discussing how creating better documents isn’t always possible. Eventually, we trained all the task force leads on the kinds of issues that need to be raised at the daily stand-ups.
Parting Thoughts
Agile methods effectively drive an iterative product development process. They’re also flexible and adaptable to the most disparate teams.
With this flexibility, however, comes the temptation to cut out the parts of the process that are more time consuming and don’t provide an immediate, visible benefit to the product under development. For this reason, some agile teams often skip process review meetings like the sprint retrospective, especially when they’re under pressure to deliver in shortened timelines. The end result is that the team repeats the same mistakes over and over again, and the team’s work doesn’t improve over time.
In short, even when you’re under pressure, it’s better to take some time to analyze your work at the end of the sprint rather than rushing headlong into the next one. But just analyzing the mistakes made during the sprint and recommending changes isn’t enough. These changes need to be implemented.
This process is easy enough to follow when you are just looking after one agile team. If you’re a department head though, say a VP of engineering or a VP of product, and you have various agile task forces running concurrently, you need to do more.
Of course, you could let each task force implement their own lessons learned, but that’s limiting and potentially destabilizing to the whole team’s process. You can’t allow that. What you can do instead is to review the recommendations from the wash-up meetings of each task force and make the necessary process amendments at a department level.
After all, the process is there to serve the team, not the other way around. In order to serve the team effectively, it needs to be flexible and evolve over time. By using wash-up meetings, you can build evolution into the process itself.
