This post is from the Collabnet VersionOne blog and has not been updated since the original publish date.
Scaling Agility Without Killing Agility
Frameworks for scaling agile methods have exploded in variety and popularity over the past few years: Scaled Agile Framework® (SAFe®), LeSS, and DAD are a few prominent examples. A common facet of these methods is the delineation of Portfolio, Program, and Team layers, with the idea of allowing goals at the executive level to be effectively communicated and driven through groups of teams. The growth of scaling patterns has had significant effects, notably driving adoption and interest in areas where agile methods have historically encountered skepticism, such as government agencies and some large organizations. But it's not all is peaches and cream, as companies like mine which have helped organizations employ these methods have seen time and again. Based on these experiences, I offer the following guidelines for those considering the adoption of agile scaling frameworks.
- Get the team right first. Fundamental to all agile methods is the idea of autonomy at lower levels, such as a team in Scrum/XP, or a group of aligned individuals in Kanban. The ownership that this drives keeps teams more engaged and interested, while also speeding the process of evaluating and executing decisions. Our coaches have often noticed that introducing hierarchies early on can dramatically impede the ability of teams to decide, flex, and adapt to local circumstances, hence limiting the organization’s overall agility. Ensure that teams are able to make decisions and deliver locally before linking them in large hierarchies.
- Keep hierarchies as flat as possible. Layers of approvals slow decisionmaking, which hampers organizational agility. They also tend to slow delivery, and limit local innovation. However, it is often the case that scaling methods are introduced largely with the idea of limiting organizational disruption, and hence they can provide an excuse for avoiding deeper (and often needed) organizational redesign. Consider how you might break an organization into smaller autonomous units before introducing multi/layered hierarchical planning processes.
- Pay attention to infrastructure and tooling. While perhaps the majority of agility focuses on the human element, the technology that underlies the process is just as critical when dealing with software delivery. The recent DevOps movement echoes the early agile method Extreme Programming by emphasizing the critical need to automate basic delivery capabilities through techniques like continuous integration, test driven development, and build automation, to the greater end of dissolving dependent silos. Absent this sophistication, teams find themselves still dependent on one another and external testing/release groups, once again defeating the local speed and flexibility that define agility. Scaling before addressing tooling can hurt organizations by allowing them to retain lengthy release cycles and dependent specialized teams, whereas short time boxes force better delivery capabilities.
- Release often to learn. Patterns like SAFe’s Agile Release Train can have some great effects by aligning historically separatist business/oriented silos such as Sales, Marketing, and Finance with their technology partners in Development and Operations. However, release cycles often end up settling on one/three month cycles. While there is nothing inherently wrong with this, it is of course possible (and often desirable) in many environments to deliver much more rapidly than that.There are two core purposes for releasing software in agile methods: to learn and to profit. These must be considered separately. Constrained availability releases are generally meant to drive feedback at scale, like giving software to a field testing group or doing gradual rollout of new functionality through live A/B testing. This helps us understand what features are used most often, where glitches occur and so forth, and hence drive subsequent planning cycles. These should happen very frequently, on the order of days and weeks, and should not be constrained by higher/level planning cycles.Typically we have a higher bar for full/scale production release, which can also be driven or constrained by customer demand cycles. This can happen less often, as seems appropriate based upon market and customer cycles, but should not hamstring the ability to do small, quick releases for the purpose of learning.
- Ensure that information flows up, not just down. Building on the point above, much of the reason why agile methods encourage rapid releases is to ensure smarter, more empirical data/based planning, as opposed to the typical “guess what the customer wants then build it for months” approach we’ve seen historically. However, this requires that information garnered from user testing is rapidly received, understood and acted upon. In general, hierarchies dampen or eliminate the ability for such granular information to travel back up the chain and influence decision/makers.Some of my best agile business stories came from projects that were canceled or dramatically altered based upon information that was unavailable during initial planning, but that rapidly became available as ground truth became apparent from user and system behavior in the wild. If this information had been suppressed in the interest of avoiding disruption of some higher order, millions would have been lost in building the wrong thing. This isn’t an impossible problem to solve, but it requires curiosity and flexibility at higher organizational levels, and a clear strategy for ensuring that team/level data is considered properly during planning cycles.
Agile scaling methods have clearly filled a demand void, and they have introduced many tools and patterns that have been observed to work in certain environments. However, not every company or situation is the same, and hence no one method is likely to work the same way for everyone. One must remember that such methods are essentially toolboxes, so understand your goals before picking your tools, and keep in mind that true agility will never be so simple as adopting a methodology. Lithespeed is a VersionOne premier partner. You can learn more about Arlen Bankston at www.lithespeed.com.