5 Hard-won Lessons From a Successful Large-scale Agile Transition
Completing a large-scale agile transition can seem intimidating for any business. Agile pushes teams to change their cultural expectations and work processes, a combination that is tough on any work environment. Larger organizations, however, often face an especially daunting migration.
The good news is that businesses don’t have to face these migrations alone. At KMS Technology, we provide everything from consulting and training to doing the legwork on dev projects for clients across a wide range of sectors. In our work, we’ve overseen plenty of examples of successful agile projects. Those efforts have taught us many lessons, with one major project standing out.
An Agile Migration at a Glance
KMS Technology recently worked with a large company to help it scale out to a more sophisticated agile development scheme. We applied a customized Scaled Agile Framework (SAFe) to the project. In doing so, we established a development environment with:
- Fifteen scrum groups divided under four release trains.
- A product feature team configuration to define user responsibilities.
- Two-week sprint cycles.
- A quarterly Innovation and Planning (IP) sprint.
- A transition from VersionOne to Rally.
- Weekly production deadlines.
After six months, the automotive company had a continuous delivery (CD) pipeline in place and had laid the groundwork for a successful project. Of course, plenty of bumps arose along the road to a solid agile environment. Here are five of the lessons we learned during the project:
No single tool will serve as a “silver bullet.”1. Don’t Allow for Missed Connections Between Scrum-to-Scrum Teams
We established a feature team setup for this project. In this setup, teams work on specific feature sets instead of simply dividing components of the software and hoping it all works when put together.
The initial plan was to have quick sprints and an emphasis on features allowing for relatively simple dependency management. In action, however, different understandings on features between groups led to some challenges – issues linking feature teams and eventual defects after integration. This challenge reinforced the importance of a few key best practices, including:
- The vital role of a Scrum of Scrums team featuring representatives from each scrum to provide cross-team collaboration and ensure work is coordinated.
- The need to build out retrospective cross teams in order to minimize dependencies and identify the universal issues within the agile system.
- The necessity of end-to-end testing that is clearly set forth in the Definition of Done (DoD) project framework. Creating clear DoD parameters can help teams ensure they minimize redundant work while avoiding mismatched data within the QA environment when compared to production.
2. Continuously Inspect Sprint Expectations and Right-size Project Guidelines
Throughout the project, we found that, in some instances, teams struggled to identify the best velocity for sprints, even after four or five iterations. There was a lack of transparency into whether timelines were actually working because formal discussions around scrum velocity weren’t taking place. This resulted in technical debt adding up over time and incorrect ideas about what constituted a completed project.
Struggles to identify the right speed for scrum sprints created instability. We learned to counter this problem by formalizing scrum event planning so teams can identify the right velocity for their tasks and recognize times when they may need to adjust how they are working in light of shifting project demands. This includes honestly assessing technical debt and setting timelines for dealing with it.
3. Identify When ‘Done’ Doesn’t Really Mean Done
A great deal of effort goes into identifying the DoD for a project. However, teams can easily struggle to pin down the Definition of Ready (DoR) for backlogged items that arise as the result of technical work. This situation can spiral as small items are left incomplete over multiple sprints until, near the end of the project timeline, testing and similar practices get less attention because everybody is scrambling to complete work. A few ways we overcame this issue included:
- Using the INVEST criteria to prioritize tasks when trying to identify DoR. This is particularly important as teams that neglect small issues of technical debt risk falling into waterfall habits toward the end of project cycles.
- Trying to minimize how many work in progress items we left unresolved at any time to avoid situations where dev teams are spending more time on backlog items than active sprint work.
- Creating visualizations of the shared scrum space for better coordination and monitoring across teams.
- Establishing consistent analysis of and updates to the DoD to better reflect real results. This was best accomplished during the sprint retrospective event.
Putting a continuous delivery pipeline in place lays the groundwork for a successful project.4. Make Sure You Don’t Neglect Training
Agile is all about getting projects moving quickly and eliminating waste. In that vein, many organizations will try to reduce training and spend a couple of weeks teaching workers about agile and expecting them to mature through their experiences on scrum teams.
In action, scrums need an opportunity to go through storming mode together to develop their agile skillsets, but companies don’t set time for that type of training. Businesses must establish realistic expectations in terms of training, particularly for cross-functional and self-organizing groups, as these users need a deep understanding of best practices in order to work well together. Employees need time to adapt to change, and businesses that want to scale agile effectively must establish their core values, reduce direct accountability within new teams that feature interdependencies and, in general, be patient with employees as they adapt.
Within this transition to agile, it is also important to train users on how to work effectively as a team. Technical skills and process education is key, but those capabilities can fall flat if employees are unable to work well together. For example, the landmark book “5 Dysfunctions of a Team” highlights a variety of typical challenges that teams face, including issues such as a lack of trust or unwillingness to face up to conflict. Businesses need to train workers to counter these types of issues.
5. Leverage Efficiency Tools, But Not With Excessive Rigidity
In this project, we used Rally, an enterprise-class platform built to help businesses scale agile teams. Even in Rally, there are still some limitations to how much the technology can support collaboration between teams and identify project dependencies.
In practice, no single tool will be an agile silver bullet. Instead of expecting a platform to solve your problems, consider adopting practices that make sense for you situation, such as tracking dependencies on a whiteboard. Within this environment, it is vital that businesses also clearly define and manage their development and release processes through ongoing training that establishes a culture of transparency.
Scaling an agile framework built around scrum methods within a large dev team can seem like a daunting process, but we’ve learned plenty of lessons the hard way – by solving them in real-world projects. We can help your business do the same. Contact us today if you want to learn more about how to navigate an agile transition.
