Teams 102

Much of my personal journey over the past 8 years has involved unpacking some of the more dense concepts we tend to take for granted when we talk about agile. For me, it’s all about understanding the primitives of these approaches and trying to figure out how to apply them in unique ways. I’m deeply interested in not only how this stuff works, but why it works… and more importantly, why it fails when it fails. 

The time I spent with VersionOne was very formative for me. My gig with V1 was a blend of training, coaching, and helping our customers understand and implement the product. When you are trying to implement software designed to support a very specific process, and the company adopting the process isn’t really built to accommodate it, things can get goofy really fast. For any of you guys that have configured V1, Rally, Jira, TFS, or AgileCraft… you know what I mean. 

I didn’t have this language back when I was with V1, but over the last few years I’ve come to believe that most organizations struggle to adopt agile because agile is incongruent with how they’ve built their companies and what their companies value. It usually centers around how they have chosen to form teams, how they govern their work, and how they measure the performance of their organization. To me… and now to LeadingAgile… those are the things that we need to fix first. Solving this is why I left V1 and started my own company. 

A Brief Perspective on the History of Agile

I’ll admit I’m no historian of agile, and while I’ve gotten to know a few of the original manifesto signers, much of what I’m getting ready to say here are just my impressions based on the things I’ve read and heard over the past few years as a student of this approach. 

I think that many folks new to agile think of agile as a thing… they might even equate agile with Scrum and might not even know there are other approaches out there in practice that are considered agile. I like to talk about agile as a family of approaches that have their roots in the earliest days of software engineering back in the 60’s and 70’s and some of the lean stuff in the 80’s. 

When the Manifesto signatories got together in 2001, they weren’t inventing agile. They were already doing agile, they were just doing agile in many different ways. The Snowbird event wasn’t about invention, it was about discovery. It was about exploring what the various approaches had in common. I think it also might of had something to do with drinking and snow skiing, but I digress. 

The result was in effect a position statement of sorts… The Agile Manifesto. If you’re on this blog, I imagine you’ve been exposed to that document, and I’ll save you the agony of going over it in any detail here. What’s important to this conversation though, is that the Manifesto isn’t a process, it’s a set of values and principles. It guides us on how to think and behave, but doesn’t really tell us what to go do. 

The Manifesto and Teams

The Manifesto says a little about teams. What it does say specifically is that we should support them and trust them and allow them to self-organize. It doesn’t say much about who should be on a team, or how to form a team, or what to do when forming teams is hard. I think the Manifesto assumes teams of a specific sort. When we look the other principles and see that we are supposed to deliver often, get feedback, etc. we start to gather some clues about what it would take to form a team capable of providing that kind of value. 

I don’t think that anyone would disagree that when the Manifesto was written, folks weren’t really trying to apply these principles at scale. They weren’t trying to apply these concepts in the large, super complicated companies that are trying to apply agile today. They were dealing with groups of 5-10 developers, all working in the same office, all with access to decision makers. They were dealing with simpler technology stacks that they fully controlled. When the Manifesto was written, this was they environment they assumed to be in place. 

Culture, Practices, and Teams

This discussion of the Manifesto is important to me because it has clearly shaped much of the conversation around how to adopt agile, and 13 years later, how we should best adopt agile at scale in large enterprises.

Because the Manifesto is a set of values and principles… and doesn’t give much guidance around how to form teams or any guidance around specific practices… agile transformation is quite often approached as a culture change. The idea being that we have to get people to change how they think and how they behave in order to do agile. 

Likewise, because the values and principles outlined in the Manifesto were derived from methodology and practice, many transformations focus on changing the stuff that people do. Be it technical practices or management practices… we recognize that people need to learn new tools and techniques that are necessary to operate in this new way. 

While I believe culture shift in many organizations is a necessary precondition to making change stick, and I think it’s fairly inarguable that solid blocking and tackling around the core agile practices is essential to be a high performing agile team… I’ve come to believe that individually, and even together, culture change and practices are not enough to have an effective agile ecosystem. 

I think it’s what’s implicit in the Manifesto that is actually most important. I think it’s the ability to have complete cross-functional teams that gives us the foundation for a healthy, adaptive, trust-based culture to emerge and for agile practices to become contextually relevant. Cultural messaging and practices outside of a complete cross-functional team just doesn’t make any sense to me. 

Regardless if it makes sense, I don’t fundamentally see this approach work in practice. While culture and practices are essential, they are not sufficient to effect sustainable, large scale transformation in most organizations. We need to have a pattern for forming teams across the organization, guidance for how to intake and coordinate work across teams, and ways to track delivery and communicate progress. Structure, governance, and metrics.

My General Bent

My general bent is that the best way to effect sustainable change, and establish  lasting agile transformations, is to first form teams. After the teams have been formed, you get them executing with precision by teaching the practices that make agile teams really work. Why teams and practices first? Well, by forming teams and teaching practices first, you create safety for the people to change what they believe. 

My take is that it’s hard to get people to change what they think, feel, and believe… especially if they are invested personally in the old way of working. It’s extra hard if people have been punished for coloring outside the lines. If a company wants to go agile, is willing to form teams, create the environment where the practices can generate great results… I believe you will create an ecosystem where a healthy culture can emerge.

Results build trust with the organization and provide safety for the managers which in turn creates safety for the teams. Safety is what allows culture shift to happen. While culture shift is wildly important, it’s not the place you want to start in your agile transformation. 

Summary

In this post, I wanted to go just a little deeper on the notion of teams and challenge some of the common thinking around agile and agile transformation.

Don’t get me wrong… there is hard work ahead of us. We haven’t addressed ANY of the barriers yet that make forming teams difficult or what you’d even form a team around if we had permission to go do it.

LeadingAgile starting to discover some really effective patterns, thinking tools, and specific methods for giving guidance on forming teams in large, complex organizations. Furthermore, we are seeing these patterns drive significant gains within the organizations we’re working with. That’s pretty exciting. 

That said, if I don’t get you convinced the forming teams is first problem to solve, maybe even the most important problem to solve, the rest won’t really matter much ;-)

Until next time.