Staying Agile – Part 3/4
9 min read
9 min read
by Aleksandra Stamatović
By its nature, agility is quite a challenge for any large organization. The staple of Agile principles, such as the necessary flexibility, experimentation, ability to quickly pivot, and a dynamic environment, clash with the rigid structure of an enterprise.
This doesn’t make the implementation of agile methodologies impossible; it just makes it a tad more challenging. However, agility at scale can undoubtedly be achieved with the proper framework, cultural mindset, and creativity.
In today’s piece, the penultimate part of our Staying Agile series, we’ll talk about the big names out there, such as Google, Spotify, and Lego, to see how they reaped the benefits of agile in their organizations.
A team that was initially working with the traditional, waterfall method when designing the SBP (Cisco’s Subscription Billing Platform), where each team would work in sequence, adopted SAFe (Scaled Agile Framework) and decided to test out agile to speed up the development process, in turn reducing release cycles, meeting delivery dates, mitigating quality problems and reducing overtime.
The main idea this team was working with was to collaborate on building and testing small features within a unique SaaS component and delivering them to the system integration and a team of testers.
As a result, Cisco’s team delivered the new release of SBP on time, and they did it with no overtime. In addition, in comparison with the previous releases, when they were using the waterfall methodology, defects were down by 40%. And there was a spike of 14% in defect removal efficiency, which can be attributed to the overall improvement in team collaboration.
The next one on our list of fascinating agile implementation journeys is Barclays. The financial services company, with over 130,000 employees, thousands of internal teams, and several different business lines, have already had specific teams working based on the agile approach. However, once they decided to apply this holistically, scaling across this huge, heterogeneous enterprise, they picked DA (Disciplined Agile), which worked for them because it was most suited for their size.
DA allows for some practice variances as the context changes, with recommendations. Given that this company was founded in 1690 and had a long history of innovation, it is no surprise that they know how to keep up with developments, adjust and thrive.
Another great thing about their agile journey is that the transformation was holistic – it was not a technology thing only. Everyone was involved in the value stream, from concept to cash, while maintaining customer experience as the most crucial aspect from which shareholder value follows.
After the first 12 months, they had over 800 teams working with an agile approach, all of them not having done so ever before. They reported seeing a 300% spike in throughput (the average number of stories completed per month per app), a 50% drop in code complexity, and a 50% increase in test code coverage.
LEGO Digital Solutions is a part of the famous toy-brick maker, and it holds responsibility for communicating with LEGO’s customers via various channels. Initially, this team had only 5 development teams, and they collaborated easily. However, once they grew to over 20 teams, they encountered complexities and decided to tackle this by changing their project management approach.
Until then, LEGO Digital Solutions teams were pretty successful with their sprints and retrospectives, but what seemed to be a problem was mostly connected to collaborating with clients, achieving and maintaining cross-team alignment, successful platform development, and release planning.
They decided to implement the SAFe approach to add a program level between the teams, and the portfolio management process was implemented at the top of the organization.
In turn, they saw, almost immediately, a reduction in double work, an improvement in planning and execution, a decrease in dependency issues, and greater client satisfaction and trust.
With over 1,700 cafes in Canada and the US, Panera Bread needed to work on increasing speed in delivering its IT solutions to keep up with and support the high growth and rapidly changing business landscape. Their IT group has around 250 employees supporting a mixture of custom-built apps integrated with off-the-shelf packages.
Panera began by kicking off a series of agile-training workshops and then piloted the new approach on two of their critical projects, relying on the help of an agile coach. After doing so successfully, they rolled out the DA framework across the enterprise.
Within one year, they made significant progress in transitioning from a traditional waterfall approach to the DA approach, which helped them make better process decisions fitting the organization’s unique context and their projects.
The adoption of DA has led this team to quicker, more frequent delivery, high-quality solutions, and a better relationship between IT and the business. They also reported seeing a growth in digital sales, which now accounts for 25% of the company’s overall sales, all thanks to the new and improved mobile ordering process.
Every PlayStation product release results from the collaboration of over 1,000 Sony Interactive Entertainment engineering team members across eight cities. Relying on the waterfall approach or Scrum wasn’t giving them good results. In addition, there were differences in cadence; other groups were iterating daily, weekly or bi-monthly, and they decided to switch to SAFe instead.
After months of coaching, the company finally launched its first agile release train. SIE currently follows a strict cadence of 2 weeks with 12-week iterations, running 6 and sometimes 7 iterations at a time.
Around 700 team members across 60 Scrum teams use SAFe now, and SIE has, by doing so, reduced planning time by 28%. Another great result was a reduction in downtime, which saved the company roughly $30 million a year.
Fitbit was using Scrum to meet its strict, holiday-driven product delivery schedule. However, once the company and its customer base started growing, it became evident that it would need to scale its project management approach. Their program manager office director has had previous experience in adopting SAFe and has helped fore-front its adoption at Fitbit, too.
Right off the get-go, they noticed a 33% spike in velocity and cadence and an improvement in team engagement. In addition, one year after officially deploying SAFe, Fitbit released 4 new products and shipped over 22 million devices.
A considerable part of Spotify’s global success is driven by the company’s innovative approach to organizing around work to enhance team agility. As Spotify’s teams worked towards achieving improved agility, they made sure to document their experience and share it with the world, ultimately influencing the way many tech companies organize around work. This is what is now known as The Spotify model.
It revolves around encouraging collaboration, innovative ideas, and productivity, all the while maintaining autonomy, high quality, and communication. So how do they do it? By relying on a unique organizational system that breaks down into Squads, Tribes, Chapters, and Guilds.
Teams are broken down into Squads, something like a Scrum Team, which is supposed to work like its own mini start-up within the company. Squads are collocated and self-organized, working together to achieve long-term missions and goals. For example, a Squad could be in charge of a task such as improving the Spotify radio experience, providing payment solutions, or improving the app’s usability for iOS. They don’t have a leader, but they do have a Product Owner, just like in Scrum. And each team has access to an Agile coach tasked with encouraging and nourishing continuous improvements.
Tribes are groups of Squads working together in a specific area, and they should have less than 100 people each. Chapters are small groups across one Tribe with similar skill sets and work in the same competency area. And lastly, Guilds are the largest group in this model. Guilds are comprised of people across the organization who want to share knowledge, tools, code, and practices.
This model focuses on organizing around work and not necessarily processes or ceremonies. It allows them to have greater flexibility and encourages autonomy and creativity. For example, when deciding whether they need to ship software or if they need to change direction – it’s all up to the Squad. This model is based on decentralized decision-making and transferring that responsibility to Squads, Tribes, Chapters, and Guilds.
Software development teams, and those that have nothing to do with tech, have proven that agile framework implementation, be it scrum, kanban, or something entirely different, can help them deliver solutions to their customers faster, increase predictability and allow for suitable and quick reactions based on new information.
Implementing agile at the individual team level is relatively straightforward. There’s a long list of benefits, and the resources are everywhere you go – you will be supported easily with this.
The real challenge is when you have to extend your agile methodology across multiple teams in a large organization – also known as implementing agile at scale.
And yet, there are many ways to do it. It won’t be an easy or quick fix, but if done correctly and with the right mindset, it can help your organization and improve your delivery & output no matter the size of the teams.
Whether you choose agile portfolio management, SAFe, DA, Scrum@Scale, or something entirely tailored to fit your needs, it comes down to understanding your organization and being open to experimenting and exploring.
We encourage you to be inspired by the stories we outlined in this part of the series but not to emulate any of them. Instead, be reminded that each team requires a different workflow and system when organizing their work. Therefore, copying and pasting an exact model to your team is not a good idea because the chances of this venture failing are high.
What works for Spotify or Panera Bread may not be an exact fit for your team. If you are on a team that needs scaling, try using the aspects that would work best for your organization. Don’t be scared of trial and error; if something doesn’t feel right, you can easily adjust your approach. Be agile and creative with this journey & never consider yourself done improving.
We’ll see you for the Series’s fourth and final part.
https://www.atlassian.com/agile/agile-at-scale
https://www.infoq.com/news/2016/09/benefits-agile-barclays/
https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf
https://www.atlassian.com/agile/agile-at-scale/spotify
https://techbeacon.com/app-dev-testing/10-companies-killing-it-scaling-agile
