Historically, agile software development has been synonymous with smaller teams. The principles behind this approach such as close collaboration, adaptive planning and continual improvement are a natural fit for co-located teams of 8 – 10 members.
However, this isn’t always the case with larger projects, especially those on the enterprise level. Although agile has proven itself to be a viable methodology for smaller teams, there are some serious concerns when it’s applied at scale.
And that’s understandable. Some have gone so far as to say agile at scale isn’t agile at all.
But when executed correctly, it’s not only feasible but highly effective.
As Joe McKendrick explains in ZDNet, one of the largest manufacturers of agricultural machinery underwent a large-scale agile transformation where their development team went from fewer than 100 developers to over 1,200 and counting. By implementing an agile methodology, the end result was a 20 percent faster time to market and a 20 percent decrease in time to production.
So there’s no doubt that you can make it work for your organization. Here are some guidelines for running agile software at scale.
Change your mindset
Many larger enterprises are accustomed to having multiple teams working in silos. One department is responsible for task A, another is department is responsible for task B, and so on.
But this isn’t conducive to agile development.
What needs to happen is a fundamental shift in your company’s mindset where it goes from being “I need to finish this task” to “we need to finish this task.” In other words, ditch the silos where tasks are isolated to a specific department and take more of a team-oriented approach.
It’s all about close coordination and having your entire team working as a collective unit regardless of size. Making this change in your mindset is essential for getting agile software development to take root and flourish.
This brings us to our next point.
Address information flow
A high level of organization and streamlined communication is fairly straightforward in a small team setting. But as you might imagine, this becomes considerably more difficult with much larger development teams. For those with 100+ developers, it can become incredibly onerous.
One of the main issues that must be addressed is how information will flow between various teams.
When making the shift to agile, you must determine what specific information will flow and which tools you’ll utilize to facilitate this communication. It’s also critical to identify potential coordination issues that may arise and develop a viable solution.
For instance, you may want to use workflows to assign various tasks to teams or individuals from a centralized dashboard. Whether it’s design, business logic creation or anything else, every single team member will know the status at any given time. An added plus is the built-in approval mechanisms to ensure that critical changes to your product are approved before they’re actually made.
This is vital for preventing communication breakdowns and keeping everyone on the same page with one another.
Establish a team that’s solely devoted to inter-team coordination
With collaboration being the primary concern for most organizations, you may want to take it one step further and establish an additional team with strictly collaborative efforts in mind. Sometimes known as a “scrum of scrums” team, this will consist of individuals from smaller teams who will serve as a representative.
It’s their job to meet frequently and discuss key aspects of software development including architecture, user interface design, deployment, and so on. This helps to further improve the flow of communication and ensures that any issues are quickly resolved before they have the chance to escalate.
This particular strategy coincides with the sixth principle of the Agile Manifesto which states that face-to-face conversation is the most efficient and effective method of conveying information within a development team.
When choosing individuals to participate in inter-team coordination, you’ll want to look for those who are highly motivated and have already earned your trust.
Work toward shorter, more adaptive life cycles
Another major focus of agile software development is short development cycles. It’s about iterations where development is broken down into small increments with short time frames. This is what enables teams to rapidly adapt to changes and make continual improvements to a product along the way.
But this isn’t necessarily the approach that’s traditionally been taken in enterprise environments. Often dev teams are accustomed to long life cycles and plenty of wiggle room when developing solutions. Therefore, a fundamental change must occur where you make the switch from long life cycles to shorter, more adaptive ones.
So how do you do this?
Perhaps the best strategy is to take a minimum viable product (MVP) approach, which Techopedia defines as, “A development technique in which a new product or website is developed with sufficient features to satisfy early adopters. The final, complete set of features is only designed and developed after considering feedback from the product’s initial users.”
So rather than develop a full-blown product with maximum functionality, opt for developing the smallest useful, functional software. Then gather feedback from customers and make the necessary adjustments in your following releases. In the long run, this should help you develop the best product possible.
This is also vital for satisfying Agile Manifesto’s continuous attention to technical excellence commandment and for ultimately delivering an excellent customer experience.
Try to keep user stories small
Tony Baker of custom software development company Atomic Object writes about the importance of keeping user stories small for large-scale projects.
He says, “At a smaller size, we were successful in having stories that were about a week or less in size. As we have been growing, these bigger stories have been causing us some pains. Lowering the maximum size of a story to two days in size has worked well for us.”
Baker also adds that smaller stories are helpful for keeping his team’s code bases synchronized and for generally keeping chaos at bay.
And this is great advice considering that short user stories are a central tenet of agile development. This way your team can seamlessly develop code in a manner that A) satisfies the requirements of the user story and B) ensures cohesion among your team members without unnecessary headaches.
The 10th principle of the Agile Manifesto is simplicity, which revolves around maximizing the amount of work not done. It’s about being as lean as possible and eliminating or at the very least reducing activities that don’t genuinely add value to the end product.
So it only makes sense that successful agile development at scale will examine potential wastes and make every possible effort to eliminate them. This is essential for making the entire process more efficient and for getting the most out of your manpower.
But what are some specific sources of waste that you need to look out for?
Most experts would agree that the more common wastes include:
- Over documenting activities – Documentation is obviously important, but you should be aware of when it gets to the point of being excessive. Also, note that many platforms will automatically keep track of actions that are made on the platform that could modify your product.
- Adding extra features – It doesn’t matter how great a feature is and how flawless the coding if customers aren’t actually using it and/or assign no value to it. Once again, an MVP approach is effective in solving this problem.
- Task switching – This is where you assign people to multiple projects, thus inhibiting their ability to focus on what’s most important.
Wait to make critical decisions
Today’s software market is rapidly evolving. As technologies advance, we’re continually seeing new features, design options, etc. For this reason, it’s smart to keep your options open for as long as possible and wait to make critical decisions.
So rather than making a major decision that’s possibly irreversible in the early stages of development, try to wait until the last possible moment. This should enable you to make better decisions and not commit to something that could potentially lower the quality of your end product.
Making agile work regardless of size
When thinking of agile software development, many people envision a small team, perhaps with no more than 10 members. They may also think that scaling up dramatically, especially to larger enterprise projects, simply isn’t doable.
With so many moving parts, maintaining the level of collaboration and communication needed for agile to thrive just doesn’t seem realistic.
But in reality, it’s not only feasible but actually quite practical in many cases. It’s simply a matter of getting your ducks in a row and creating a workable framework.
The guidelines discussed here tackle the core obstacles that teams face when running agile software development at scale and provide solutions to those challenges. While there will certainly be a transition period and some growing pains involved, making this shift should be advantageous in the long run.
What do you believe is the biggest barrier to scaling up like this? Please let us know:
Featured image: hitesh choudhary / Pexels
In-post image 1: bruce mars / Pexels