Adopt an Agile culture

If there's one lesson to be learned from the last decade of "Agile transformations," it's that there's no one-size-fits-all solution to adopting or implementing an Agile approach. Every organization has different needs, constraints, and requirements. Blindly following a prescription won't lead to success.

The Agile movement is about continually finding ways to improve the practice of building software. It's not about a perfect daily standup or retrospective. Instead, it's about creating a culture where the right thing happens more often than not. Activities like standups and retrospectives have their place, but they won't change an organization's culture.

This article details foundational elements that every organization needs to create an Agile mindset and culture. The recommendations shouldn't be followed blindly. Each organization should apply what makes sense in a given environment.

Schedule and rhythm

There's no perfect sprint length. Teams have been successful with sprint lengths that range from one to four weeks. What matters most is consistency.

Select a sprint length that works for your organization's culture, product, and desire to provide updates. For example, the Developer Tools division at Microsoft (roughly 6,000 people) works in three-week sprints. The leadership team didn't choose this sprint length; it came from direct feedback from the engineering teams. The entire division operates on this three-week sprint schedule. The sprints have since become the heartbeat of the organization. Now every team marches to the beat of the same drum.

It's important to pick a sprint length and stick with it. If there are multiple Agile teams, they should all use the same sprint length. If feedback drives a change, then be receptive. It will become clear when the right term is in place.

A culture of shipping

Peter Provost, Principal Group Program Manager at Microsoft, said "You can't cheat shipping." The simplicity and truth of that statement is a cornerstone of Agile culture. What Peter means is that shipping your software will teach you things that you can't and won't understand unless you're actually shipping your software.

Human nature is to delay or avoid doing things until absolutely necessary. This couldn't be more true when it comes to software development. Teams punt bugs to the end of the cycle, don't think about setup or upgrade until they're forced to, and typically avoid things like localization and accessibility wherever possible. When this pattern emerges, teams build up technical debt that will need to be paid at a later time. Shipping demands all debt be paid. You can't cheat shipping. To establish an Agile culture, start by trying to ship the product at the end of every sprint. It won't be easy at first, but when a team attempts it, they quickly discover all the things that should be happening, but aren't.

Healthy teams

There's no recipe for the perfect Agile team. However, a few key characteristics make success much easier to achieve.

Co-locate teams whenever possible

Can a team find success with people spread out across different geographies? Yes, but it's more difficult. When people are co-located and sitting in the same room, the right conversations just tend to happen. It's still possible to succeed with teams located across globe and different time zones. But wouldn't that same team have an advantage without all of those obstacles?

Keep teams intact for a reasonable length of time

Allow teams to master the art of building software together. When teams are scrambled, any chemistry they've developed gets disrupted. Sometimes it's appropriate to reorganize, but teams are typically more productive when they're given time to learn how to work together. As a guideline, try to keep teams intact for at least 12 months.

Load balance work, not people

Sometimes teams fall behind and need help. A common tactic to address this is to lend a person from one team to another. However, that can be counterproductive. A better solution is to load balance work to another team, rather than load-balancing people between them. Pulling a person from one team to help another disrupts both teams, and it can frustrate the person being moved, even if temporary. All of this affects team productivity and, more likely than not, negatively impacts the ability to get back on schedule.

Load balancing work instead of people allows a team that's already established to step in and help out. It becomes a conversation about priorities, not a conversation about people.

Let teams own feature areas, not layers of architecture

Strive to build vertical teams that own feature areas. These teams are responsible for all the work required to add features to their area, from database to user interface changes. The team is empowered to deliver and own an end-to-end experience.

When horizontal teams own layers of architecture, no single team is responsible for the end-to-end experience. Adding a feature requires multiple teams to coordinate and requires a higher level of dependency management. Resolving bugs requires multiple teams to investigate whether they own the code required to fix the bug. Bugs are batted around as teams determine it's not their bug and assign it to another team.

Feature teams don't have these issues. Ownership and accountability are clear. There may be a place for some architectural-based teams. However, vertically focused teams are more effective.

Next steps

As teams embark on their own Agile transformation, keep these foundational principles in mind. Remember, there's no single recipe that will work for every organization. Agile transformations are a journey. Make changes and learn from them. Over time the organization will develop the Agile culture it needs.

Microsoft is one of the world's largest Agile companies. Learn more about how Microsoft adopted an Agile culture for DevOps planning.

Learn about how Azure DevOps enables teams to adopt and scale an Agile culture.