As organizations improve agility within in their teams, the conversation quickly turns to how to “scale Agile”. Scaling is a term used for applying Agile methods and practices across multiple teams in order to produce larger products, projects, or services. There are many frameworks for scaling Agile within an organization, most of which are represented by acronyms like SAFe, LeSS, DAD, DSDM, or SoS. There is comprehensive information available on these frameworks all over the internet.
Despite the number of available frameworks out there, many organizations fall short in their attempts to scale Agile. Often this is because they see it as another process to be integrated, not as the cultural shift it is intended to be. Too many time, it is forgotten that Agile isn’t something you do… it’s something that you are. That kind of transformation takes time, often more time than is allotted.
Even if you aren’t embarking on a full-scale Agile transformation, there are number of practices you can borrow from scaled Agile frameworks to help you get started on your scaling journey. Here are a few ways that you can experiment with scaled Agile within your organization.
Look at team sizes and composition
Before scaling, it helps if teams are right-sized around a value stream. This means that teams should adhere to the classic “two pizza” team size, more or less. This number is something around 5-8 people, plus or minus one. The reason for keeping team-size small is it cuts down on communication overhead within the team, as well as creates focus in meetings and other discussions. Consider that a team of 7 people has 21 lines of communication between them, while a team of 11 has 55 lines of communication between them. The more lines of communication, the more complicated and prone to miscommunication they can be. Too few team members does not create enough cross-skilled diversity within in the team.
Secondly, these teams should be organized around value streams. A value stream is simply the process of delivering product or services to a customer, either internal or external. The critical piece here is that teams should be organized around value streams in a way that minimizes or completely eliminates hand-offs. Thus, the team should have all the skills and abilities necessary to deliver end-to-end. This can be easier with software development teams, as they are often focused on specific applications, but the same thought process can be applied to any number of products or services.
Scrum teams not running on the same delivery cadences create delays. For instance, if Team A is on a two-week cycle, but Team B is on a three-week cycle, they only have the opportunity to plan in unison once every six weeks. Even teams that are both on two-week sprints have difficulty coordinating if they don’t start their sprints on the same week. Getting all teams to adhere to the same duration and planning weeks makes scaled planning easy to achieve.
If your teams are not working in the time-boxed cadence of sprints, don’t worry. You can still look to establish a monthly or weekly session to review and align priorities, as well as plan group delivery dates. The preference would be over shorter time periods, so monthly is likely more effective.
Many Agile frameworks utilize a set of specific, focused meetings known as ceremonies. Often these are things like Planning, Retrospective, Demo/Review, and Backlog Grooming/Refinement. Each ceremony has an agreed focus, as well as a time box so that the team is efficient in their meeting.
There are three strong areas of opportunity for scaling ceremonies. These are Planning, Retro, and Review.
- Planning: To often on project, a project manager or the like will try to coordinate the work across teams without those teams ever showing each other their collective plans. Joint Planning is not overly complicated. It requires that each team review the collective project deliverables and identify what they believe will be there pieces of work. Then, each team plans their work for the upcoming duration. After that, teams come together to present their plans to each other, as well as discuss any identified dependencies between teams. These dependencies should be agreed upon and their timing layed out to create the clearest critical path possible. These planning activities can often be accomplished in a day with the proper facilitation.
- Demo/Review: One common complaint of teams is not knowing what others are working on. This can be particularly damaging on projects where teams have to bring their work together later, or have overlapping domains of responsibility. Periodic “show and tell” sessions allow teams to present to one another the work they have done, as well as allow team members to ask questions and share ideas. This encourages cross-team collaboration and learning. It also places an emphasis on how things work together. Just remember to try to “show” more than “tell”. Nothing kills review attendance like a drab death by Powerpoint. Show working software, show code, show pictures. Agile is visual.
- Retrospective: Scaling retro is similar to scaling planning, in that teams must meet separately and collectively. Each team holds its own retrospective for improvement. Items identified in that retrospective that are outside the scope of the team should be captured to take to the group retro. In the group retro, teams can talk together about what has been working and what hasn’t, in regard to cross-team collaboration, communication, and delivery. The focus should be on organizational impediments that keep teams from working together better.
Scaling does not have to be complicated or scary… it simply has to be organized and consistent. Many of the proposed approaches here can be implemented within a few weeks. Once teams are in the habit of working together more frequently, many benefits will begin to show themselves. Regardless of what you choose to do, remember to keep focus on simplicity, transparency, and collaboration.