Value stream teams: a non-technical introduction

For value stream teams to come together effectively all team members need to speak the same language

For the last few months I have been working with a client that wanted help in structuring their organisation in a way that would enable them to sustain the growth the business was experiencing while preserving the good culture, engagement and psychological safety they had created along the way. We introduced them to the concept of cross-functional value stream teams in an effort to move them away from the functional silos that had started to emerge, along with the usual handover delays and lack of context that accompany such an organisational structure. As they are “trying on” this new way of working, bringing people from different business backgrounds together into a single team with a shared focus, we are seeing some encouraging results: enthusiastic team members, more autonomy at every level yet better alignment and understanding of the bigger picture and what really matters in moving the business forward.

Naturally there is an equal amount of uncertainty at this early stage as people are grappling with new structures, responsibilities, terminology and what is expected of them. This made me realise that almost all of the literature on the subject of value stream teams is written with a technical audience in mind. We teach engineers and engineering managers how to step out of their technical context and into the world of business outcomes and towards closer collaboration with “the business”. We explain value streams with our tech hat on as we are moving away from “tech projects” towards business value and product thinking. This not only leaves the onus on “us” to teach “them” why they should work in this way, but we don’t give our new team members any literature they can easily relate to and which answers their questions in a way they can relate to.

To move beyond “us” and “them” and “IT” and “the business” I want to explain this cross-functional value stream focused way of working in a way that is accessible and useful to all. This will no doubt take a few blog posts as I order my own thoughts and absorb and process some of the questions I’m being asked. I also want to deliver useful information in bite-sized pieces that are easily digestible and don’t overwhelm those new to the subject. Who knows, maybe one day we’ll see “the business” pushing to not be separate from their tech guys ;-)

So, what is a value stream?

A value stream can broadly be defined as a set of activities that need to take place in order to create value for someone, usually a customer. That customer can be internal to the organisation (e.g. an Account Executive in the Sales team) or external (e.g. a particular type of customer with a particular need). Wikipedia tells us that a value stream “begins with the initial concept, moves through various stages of development and on through delivery and support”.

That’s starting to sound a bit technical again already, doesn’t it? In today’s world a lot of value delivery does require some sort of engineering involvement, technology is everywhere after all. But it doesn’t have to. In manufacturing the “development” aspect of the value stream might be the assembly of component parts into a piece of machinery for instance. Or if you consider the value stream focused on delivering entertaining novels to the real-crime-loving female population, the development part of the equation covers the author’s research, the writing of chapters and later review and editing process by various other professionals required to create the next bestseller novel. Or a value stream focused on creating memorable culinary experiences in your local restaurant - their development effort is one of sourcing ingredients, testing recipes and perfecting their execution in a time bound manner appropriate to meet their customers’ expectations.

Maybe a more technology-agnostic definition could describe a value stream as the “set of actions required to turn an idea into reality that a customer will derive value from”.

What that set of actions will be heavily depends on the type of value stream, the industry, country, even the organisation itself. Consider a bank looking to offer the best possible mortgage products to first-time buyers. Imagine how varied the activities might be that are required to turn an idea into a mortgage someone can buy a house with. Different jurisdictions, different internal policies and processes, different approval hurdles, different software systems, both those considered legacy and those not yet built. It is not uncommon for organisations to lose sight of what series of activities a “value item” is undergoing during its creation process - the larger the organisation, the more people are usually involved, the more hand-offs happen, the more layers of approvals are created along the way. An exercise called value-stream mapping can help visualise these activities and inform future state discussions (more on that another time).

What is a cross-functional team?

Now that we have a better understanding of what value streams are, let’s look at the meaning of cross-functional teams. A cross-functional team is quite literally what it says on the tin. It is a group of people, a team, that consists of individuals with backgrounds from various functional areas within the business. A functional area may be Sales, Marketing, Procurement, Finance, Operations, Legal, Technology, Compliance, Manufacturing, Human Resources. We can think of a functional area as a group of people that share a common skill set - accountants, lawyers, authors.

What brings the team together and defines its composition is a common goal. Such a goal might be to create the next best selling real-crime novel, or to create the first Michelin starred restaurant in town, or to create a superior retail product that satisfies an untapped customer need better and faster than the competition.

Cross-functional team + value stream = <3

Now let’s put the two concepts together. A cross-functional team needs a common goal and value streams provide a focus on value creation for a particular customer. Combining these two concepts yields a cross-functional value stream team.

The value stream activities dictate the team composition. To be successful we want to create a self-sufficient team that within the team boundaries contains all necessary skills required to perform the activities identified to take an idea from concept to value creation. No bestseller is going to write itself [1] in just the same way that no perfect story will get noticed without at least some advertising efforts.

Whenever a team is devoid of a critical aspect required for value creation, we create handovers or approval hurdles and thus delays that slow down the value delivery for our customers. By providing the team with all the skills they require to create value, we enable them to do this in the most effective way possible. We create flow and with it a significant competitive advantage.

What does this mean for my “actual” team?

This morning you woke up and were a car salesman. By this afternoon you have suddenly been thrust into a value stream focused on creating the next revolutionary car that is going to push Tesla off its top spot. Cool - but slightly unnerving too. Who are you now? And what about the other Sales guys? Do you not hang out anymore?

For self-sufficient cross-functional value stream teams (I wish there was a better acronym than SSCFVST which somehow doesn’t strike me as very memorable) to work best, the tribal identity of its team members should be derived from their new cross-functional team. This will take some getting used to but should be taken seriously - teams need trust and psychological safety to become truly high-performing. A few “meta” team conversations can be helpful: Who are we? What are we going to be called? How do we work together? What matters to us, what do we dislike? How will we interact with the rest of the organisation? How will we tell everyone about the great work we’re doing?

These and other questions create a first layer of social fabric upon which the team can build familiarity, trust, respect and an appreciation for the different value contributions each member is capable of. Everyone is different and that is exactly the point but it can create initial anxiety - terminology that was well-understood in the Marketing department yields nothing but furrowed brows in the new team, or systems and processes second-nature to most engineers have never been heard of by some team members. Take some time to get to know each other, agree on terminology and take nothing for granted. Once the dust settles, a new team identity will emerge and things will start to feel familiar again, order returns.

But what about the other Sales guys? The ones in the value stream about inventing a tricycle that can turn into a boat? And the guys helping to create the first electric commercial airplane? They were your buddies once, if they’re not your team anymore, what are they?

They are a valuable source of knowledge, good practices, lessons learnt from mistakes and they should absolutely be on your lunch buddy list. Spotify calls them Chapters, in other frameworks terms like “Centres of Excellence” and “Communities of Practice” are covered. There are differences but I promised to keep this as non-technical and jargon-free as possible so let’s not dwell.

Ultimately these are groups of people that share similar skills, functional roles or even just interests and we absolutely want to encourage these groups to get together, discuss and share ideas. This enables lessons learnt in one part of the company to reach another, it encourages standardisation and common practices to ease company-wide communication, initiatives and reporting. It can even provide line management leaving the management of value stream teams to be purely outcome-focused while entrusting an individual’s career progression, training needs and personal development to a line manager that shares a similar background and has a level of functional understanding to judge the individual’s competencies.

But I’m getting carried away - the simple answer to the question is that your primary team should become the cross-functional team that is in pursuit of a specific goal or opportunity but you should maintain and build a network of like-minded individuals across the organisation to encourage knowledge sharing and transfer within a specific profession. Plenty of lunch buddies going round!

Am I joining a Tech project?

Hopefully what you have read so far will convince you that you’re not just a stakeholder in a Tech project surrounded by people who talk about cycle time, story points, retros and stand-ups. You are part of a cross-functional team that is hoping to create significant value for your customer(s). Depending on your organisation and the kind of value it creates this may necessarily be fairly engineering-heavy, but every team member contributes something unique to the value creation process without which said value creation would either not be possible at all or extremely delayed.

Everyone’s value contribution to the goal is considered equal, there is no better or worse in terms of skills provided, they’re all just different. This may well take some getting used to all round, including the Tech guys who may need reminding that their weird lingo isn’t as commonplace as they always assumed. This is a learning process for everyone and the more transparent we can be about what we don’t know, the easier it will be for all participants to find their feet and feel at home.

I hope this has given you some interesting ideas and insights to take away and mull over. Stay tuned for the next post(s) in which I’ll cover business outcomes - how do you articulate that common goal - and metrics - how do you know you’re winning, and possibly other interesting musings on the subject.

You have questions that can’t wait? Get in touch!

---

[1] At least not quite yet