Making Agile work Better with Scaled Retrospectives

The Agile movement continues to mature as companies gain more experience with the software development methodology. We previously talked about the Agile Tribes organizational innovations implemented by the music streaming company, Spotify. In short, it allowed the company to improve their overall efficiency to better meet the goals of the business.

Scaled Retrospectives (or “Scaled Retros”) is another recent Agile innovation aimed at handling the various problems that crop up outside of the normal scope of a development team. Let’s take a closer look at this concept to see if it makes sense implementing it in your shop.

Scaled Retrospectives – What are They?

During any software project – Agile or not – a variety of issues come up impacting a team’s ability to complete a task on time. In an older methodology like the Waterfall, the entire project might be delayed, while in Agile, a Sprint completion date might be missed. Some problems, like a slow developer, are within the team’s area of influence. Scaled Retrospectives, on the other hand, identify any adverse issues happening beyond the team’s control.

The blog, Agile Uprising, identifies Scaled Retros as items meeting three different criteria. First off, the issue is outside the team’s sphere of control. Secondly, it is impeding their ability to complete work in a timely fashion. Finally, the underlying problem is one that needs to be fixed.

Software development shops that implement a process to identify Scaled Retrospectives are seeing a noticeable increase in efficiency provided an effort is also made to deal with the noted problems. Properly cataloging the items and analyzing any patterns affecting an entire enterprise is a key factor in the success of a Scaled Retros program.

The Benefits of a Scaled Retrospectives Program

While a formal Scaled Retros program benefits big development shops with multiple teams, even smaller groups gain an advantage from identifying any large-scale problems impacting the software engineering process. The author of the Agile Uprising blog post noted above describes a scenario where he cataloged retro items from 100 different teams. This quickly became a process that would require a few full-time employees.

Instead of trying to do everything himself, he engaged the different development teams to communicate with each other. Any serious problems affecting everyone in the shop quickly bubbled to the surface. A cataloging effort was still required, but the amount of repetitive data entry and analysis became smaller. This final process allowed a small list of major problems to be delivered to the senior executives able to fix the issue.

The most notable output of their first Scaled Retro process highlighted the need for an automated build server. This issue was identified by 70 percent of the enterprise’s development teams. The voice of a singular programmer carries more weight when combined with many others.

As noted earlier, even smaller shops would benefit from an informal Scaled Retrospectives program. It is especially vital at large businesses where company-wide issues may not be identified without the effort. The most significant point is to realize the importance of finding any large-scale issues impacting the efficiency of your software development teams.

Put Scaled Retrospectives to work for you!

Stay tuned to the Betica Blog for future insights from the worlds of software development and QA. Thanks for reading!