Skip to main content

Encapsulating Value Streams and the Object Oriented Enterprise

Mike Cottmeyer Chief Executive Officer
Reading: 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 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 ;-)

Next Aggressive Decoupling of Scrum Teams

Comments (2)

  1. Mike DePaoli


    Good post. It’s interesting how the best thinking and most basic patterns keep resurfacing in our work. The scientific method in Lean Start Up and now Object Orientation in your’s and others’ thinking about scaling Agile systems.

    I started my career in the early 80s developing real time OO systems. Worked with David Taylor in San Mateo, CA on some of the work he was doing with building a framework for real time OO-development.

    To this day this frame of thinking and the complementary frame of systems thinking has governed the way I approach problems with the best reference models being biological ones.

    For those unfamiliar with Object Oriented theory, I’d suggest David Taylor’s book “Business Engineering with Object Technology” or his first book “A Manager’s Guide To Object Technology”. Still one of the most concise presentations of the basics.

    OO-Systems manage their dependencies through explicit contract through an object’s interface. You can even have objects that have the purpose in the system to look for broader threats and isolate them and eliminate them. In the context of your post the treats can be wider system dependencies that are not being met. In the end all they are are patterns that once understood can be identified and managed.

    Designing an effective OO-Enterprise System on paper isn’t really that hard once you’ve clearly understood the purpose of the organization and its value streams and the fundamental rules that govern object interaction including learning.

    The hard part is that in reality, such a model won’t have fixed contracts because of the human component. Think of it as OOD meets “The Five Dysfunctions of a Team” (book by Patrick Lencioni). You can define the contact between the objects and the object subsystems but not until the dysfunctions that exists in teams are mitigated can you really exercise the contracts predictably. One of the fundamental characteristics of an effective Agile system is high levels of transparency. High levels of transparency enable the agents in the system to have the truth with respect to data which enables them to to exercise their contacts effectively.

    This is also why no two organizations will evolve the same way using a model framework because the agents in the system are not fixed, they are ever changing, learning and feeling. This is what injects the complexity into this problem space.

    Another big challenge in this problem space is trying to transform an organization that was designed for a different model, say waterfall. Such a model called for non-cross functional teams. The behavioral norms that evolve work to serve individual interest in this context. With such a system and behavior patterns in place, in the face of a change, people always gravitate to what is the norm regardless of how dysfunctional it is because it is familiar.

    The best success I’ve had with applying OO Theory to design a model for value delivery to a known customer is when I could define the system model and use it’s fundamental rules as the basis for building the human organization. Short of that, I have had success creating a new subculture based on an OOD based model to build a new product (Remember GM spawning Saturn?) Then the hope is that this new Sub-culture becomes infectious to the the larger one and aid in transforming it.

    Regardless, a fascinating topic.

  2. vineed

    Good article on value stream encapsulation. Had 2 questions regarding what you have mentioned here Mike. When you mentioned that you explicitly manage the value stream in the program layer by having progressive elaboration and maximizing the flow of value, is this about intentional product backlog grooming and kanban to manage flow to the development teams ? My second question is on SAFe managing the dependencies. I think the design of the scrum team (feature based, cross functional, along the lines of architecture…) should address this value stream encapsulation within the scrum teams of the release train. Do you mean to state that SAFe is not explicit in the scrum team design aspects in considering the value stream encapsulation aspects ?


Leave a comment

Your email address will not be published. Required fields are marked *