Encapsulating Value Streams and the Object Oriented Enterprise

When you get right down to it, a Scrum team is fundamentally a container designed to encapsulate the entire product delivery value stream into a single workgroup.

The value stream associated with software development typically goes something like this: analysis, design, build, test, and deploy. That’s pretty much everything you need to develop a working tested increment of the product… and therefore what defines the basic requirements for a Scrum team.

When you put analysts, designers, developers, and testers into a single workgroup, let them work across skill-set boundaries, self-organize to balance load, and have them collectively produce a working tested increment of product on regular intervals, you can reduce a tremendous amount of planning complexity.

Your organization has to get past the belief that individual productivity and utilization are the measures of effectiveness, you have to focus more on team throughput and flow of value, but the construct allows you to move fast, change direction, and adapt as we learn more about the emerging product. Planning is simple, objectives are clear, and outcomes are measurable.

Why Scrum Breaks?

The problem with many Scrum implementations is that the team doesn’t actually encapsulate the entire value stream. In almost every real life organization, someone who is necessary for the team to complete their work doesn’t actually live in the Scrum team. This is very simply what causes Scrum to break. Dependencies kill Scrum.

When this happens, we get into an agile project management mindset. We are running some of the work through the Scrum team, but we need extra coordination mechanisms to help us line up the Scrum team with the other parts of the value stream that live outside the team. We have external planning dependencies that have to be dealt with.

It’s my assertion that these planning dependencies are what results in teams going through the motions of Scrum without realizing value Scrum promises. Last week I did a talk at Agile2014 that was all about why agile fails in large enterprises. The whole talk is about how to systematically break dependencies between teams.

That said, some organizations are simple enough that a Scrum of Scrums is sufficient to model and deal with the unavoidable coordination issues. Some organizations have to be more proactive coordinating complex backlogs and use constructs like Product Owner Teams, Solutions Teams, and Requirements Clearinghouses.

The key takeaway here is that when you have a Scrum team where the entire value stream is not encapsulated, you need something outside the basic Scrum construct to coordinate across the teams. Pick your poison, but something outside the team almost always has to be present.

SAFe and Value Streams

I want to see if we can pull this up a level and talk a bit about SAFe. Coming off the Agile2014 conference in Orlando, SAFe was everywhere… and for good reason. Everyone is trying to figure out how to take the concepts we’ve learned with Scrum and get the value at enterprise level scale. Scaling Scrum is the topic de jour.

Honestly, I don’t keep up with SAFe in detail… I’ve never been in SAFe training… and I’m definitely not part of the inner circle of SAFe thought leaders. That said, I’ve read everything Dean has written since he released Scaling Software Agility, have a ton of respect for his work, and agree with the basic patterns he has introduced.

This conference though, I heard something I hadn’t really heard before. It seemed that everyone was talking about value streams relative to SAFe. I’m sure the concept has been in SAFe for a while, but it caught my attention differently this time around. It made me wonder if I should think about SAFe similarly to how I think about Scrum.

At LeadingAgile, we typically coach an explicit value stream in the middle level program tier. We think about progressive elaboration and maximizing the flow of value in the middle tier. We usually encourage an explicit Kanban flow that respects some of the upstream and downstream work processes we see most often in product delivery organizations.

It occurred to me that SAFe isn’t modeling the value stream explicitly in the middle tier, it is managing the work through the PSI/PI planning meeting, fundamentally encapsulating the entire value stream within the planning construct. In short, SAFe is fundamentally operating like a big Scrum, just encapsulating a larger value stream.

Whereas I’ve been thinking most about breaking dependencies, SAFe appears content with managing dependencies and making them visible and explicit in the planning session. This is absolutely a necessary step in the process, but by not dealing with the root cause of dependencies directly, I believe they will limit your ultimate agility over time.

SAFe will struggle with dependencies at scale for the same basic reason Scrum struggles the team level. Dependencies make it hard to move.

We’ve been giving a lot of thought lately to breaking dependencies, and our work with clients is fundamentally about forming complete cross-functional agile teams and systematically breaking dependencies between them over time. We believe that this is the only true way to scale agile indefinitely to the enterprise.

We believe this concept is methodology independent and will make any methodology you choose better in the long run.

Why SAFe Breaks?

Scrum isn’t trying to break dependencies within the team, it is merely trying to encapsulate the value stream, allowing the team members to work across role boundaries, self-organize around the work and stabilize throughput, while holding them to producing a working tested increment every couple of weeks.

SAFe isn’t trying to break dependencies either within these larger value streams either, it is merely trying to encapsulate the value stream similarly to Scrum, allowing team members to work across role boundaries, self-organize around the work and stabilize throughput, while producing a working tested increment every PI.

There are clearly more constructs within SAFe than exist within Scrum to deal with the larger effective team size and integration tasks, but I think that the pattern fundamentally holds. I never really thought about it that way before. I’m curious if anyone else has ever thought SAFe as kind of a big Scrum?

If we know that Scrum implementations struggle when the entire value stream can’t be encapsulated within a team of 6-8 people, do SAFe implementations struggle when the value stream can’t be contained within a team of 125? If my assumption about dependencies and value streams holds, I suspect they would.

If SAFe is going to ultimately struggle at scale beyond 125 people, does that mean that we are going to need the same constructs for coordinating value across teams that we need in Scrum? At some point will we find ourselves talking about SAFe’s of SAFe’s or SAFe Product Owner Teams or SAFe Portfolio Solutions Teams?

I suspect we might. I think we might also be seeing evidence of this already.

Maybe there is some stuff in SAFe that already accommodates this, but I’m curious what’s out there to tactically coordinate across SAFe value streams? Remember, I’m not talking about investment decisions across a SAFe Portfolio… I’m talking about managing dependencies between value streams. I gotta figure some folks are dealing with this already given how well SAFe is doing in market.

If anyone has any insight or can point me in the right direction, I’d appreciate it. I’m interested to know how the insiders think about this? Is anyone inventing things outside the SAFe body of knowledge that are being written about? Where is the body of knowledge emerging outside of the official cannon and are people talking about this?

Ken and Jeff Got it Right

Back in 2006 Ken Schwaber put up a slide where he illustrated a team of teams structure, one where lower-level Scrum teams were encapsulated in a higher-order Scrum of Scrum construct. Back in 2006 I was thinking that there was no way this would work in the absence of very loosely-coupled teams (and at that time, that was NOT my reality).

A few years ago, I heard Jeff Sutherland and Jim Coplien give a talk at the Scrum Gathering in Orlando. The one line I vividly remember from that talk was that ‘teams were never expected to self-organize across class boundaries’. They were implicitly saying that encapsulation was the expectation for a Scrum team to form.

Jeff Sutherland, as we speak over at Scrum.com is talking about Object Oriented Design in Scaled Scrum implementations. He is basically making the case that Scrum teams are intended to be formed around Objects in an organization. It is a prerequisite for Scrum to work.

I think that this one concept is a point which has been wholly misunderstood and largely ignored by organizations adopting Scrum. Many people implementing Scrum now-a-days don’t have any idea about OOD principles, let alone as they relate to organizational design and team structure.

When you read Craig Larman and Bas Vodde’s stuff around LeSS (Large Scale Scrum) and consider the structures they’ve put in place, you have to view those structures through the lens of an Object based organizational structure. Their work is built on the same foundation that Ken and Jeff laid 25 years ago but that is seldom implemented.

I find myself fundamentally in alignment with Ken, Jeff, Bas, and Craig… and I think theirs is the best end-state for a scaled agile enterprise. The problem is that their underlying operational structure for a scaled Scrum implementation to work… the Object Oriented Enterprise… doesn’t exist in most companies adopting Scrum,

SAFe Is A Compromise

I think I’m coming to the conclusion that SAFe is a reasonable compromise given the operational constraints in many organizations. If you aren’t going to form teams around Objects in your organization, you probably shouldn’t bother implementing any of the Scaled Scrum variants. You’ll just get frustrated.

That said, I do believe that SAFe is going to suffer from many of the same problems that Scrum deals with organizationally in the presence of incomplete or dependent value streams and a lack of organizational object orientation. It’s just a matter of time and scale.

At this point in the evolution of my thinking, I find myself in a place where I don’t believe the Scaled Scrum stuff will work in most companies in their current state. I think SAFe will work to a point, but if it’s sold as the final destination, we are going to limit our ability to scale and ultimately limit our ability to be agile.

We can only be as agile as the size of the team, and the independence of the value streams, and the length of the PI boundary. I think organizations will soon find they are going through the motions of SAFe without really solving the problem. Again, it sounds just like where we are with Scrum in most companies.

Refactoring Your Enterprise

The only real, long term sustainable approach to Scaled Enterprise Agile is to take the long hard road toward refactoring your enterprise into an organization based around the OOD principles that were implied, but maybe not explicit, when agile was formally articulated 13 years ago. The problem is that this message doesn’t fill CSM classes and has to be sold all the way at the top of the organization. It will require a significant investment on the part of the executives.

The cool thing is that in the presence of this kind of organization, everything else starts to make sense. You can see a place where Scrum and Kanban live side-by-side in peace harmony. You can see where the technical practices fit in at scale. SAFe, Disciplined Agile Delivery, and LeSS all have a place in the pantheon of ideas. No matter which path you take, the Object Oriented enterprise makes everything else make sense. It’s the right context.

With the Object Based Enterprise as a sort of backdrop to sort out all the different perspectives on agile, we can begin to see that the conversation around potential future states starts to get WAY less interesting than what it takes to get there. I think the interesting conversation is around how we do the refactoring in the first place, and what the possible transition patterns look like that help us get there, while still running our businesses effectively.

If I think about it… that was really what my talk last week was about. The talk is up on the blog, and it was recorded by the conference, but that might take a few weeks to publish. I think I’ll do my next post as an overview of the content and rationale behind the material in my presentation. Let me see if I can make that happen this weekend ;-)