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. In my work, I’ve overseen plenty of examples of successful agile projects. Those efforts have taught me many lessons—with one major project standing out.
I recently worked with a large automotive 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:
After six months, the company had a continuous delivery (CD) pipeline in place and we 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 lessons we learned during the project:
We established a feature team setup for this project. In the setup, teams worked on specific feature sets instead of simply dividing components of the software and hoping it all worked when put together.
The initial plan was to have quick sprints and an emphasis on features that would allow for relatively simple dependency management. In action, however, different understandings of features between groups led to some challenges, including issues linking feature teams and eventual defects after integration. This challenge reinforced the importance of a few key best practices, including:
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 constitutes 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 could identify the right velocity for their tasks and recognize times when they may need to adjust how they were working in light of shifting project demands. This included honestly assessing technical debt and setting timelines for dealing with it.
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:
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 skill sets, but companies typically don’t set aside 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 to work well together. Employees need time to adapt to change. 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 lack of trust or unwillingness to face up to conflict. Businesses need to train workers to counter these types of issues.
In this project, we used Rally, an enterprise-class platform built to help businesses scale agile teams. Even in Rally, there are 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 your 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.
Redis is taking it in the chops, as both maintainers and customers move to the Valkey Redis fork.
GitLab Duo Chat is a natural language interface which helps generate code, create tests and access code summarizations.
Expect attacks on the open source software supply chain to accelerate, with attackers automating attacks in common open source software…
The emergence of low/no-code platforms is challenging traditional notions of coding expertise. Gone are the days when coding was an…
Datadog today published a State of DevSecOps report that finds 90% of Java services running in a production environment are…
Linux dodged a bullet. If the XZ exploit had gone undiscovered for only a few more weeks, millions of Linux…