The Problems of Traditional Structures
One of the major challenges I see around the ability for organizations to truly be adaptive to market needs — comes from the structure and incentives we regularly see throughout organizations that prevent our ideal behaviours.
The characteristics of these structures are gates — controlled with disparate incentives & ownership — encouraging separation over collaboration.
When their value streams are mapped, we tend to see patterns like below:
What these structures do is create multiple hand-offs, one of the seven key forms of software waste¹. When we look at the flow of product ideation through to our customers — the picture looks like a set of stairs.
handoffs
Falling down the stairs
Teams shift from caring about optimizing the flow through the entire value stream and care more about ensuring they handover to the next responsible team as quickly as possible.
As teams grow further apart and more insular in their motivation — they gradually lose sight of not only of the shared goals of the teams around them but also of the organization outcomes themselves. As the authors of ‘The DevOps Handbook’² put it:
With enough handoffs, the work can completely lose the context of the problem being solved or the organizational goal being supported
This manifests itself has two key impacts on your ability to efficiently provide value to your customers — measured in the form of long lead times through your entire value stream:
Impact 1: Delay of Awareness
As we move through our value stream — The closer we get to the release of our product to the customer, the less time we have to provide and respond to valuable feedback.
In doing this, we delay obtaining and incorporating other internal feedback sources into product development early. Often forgetting it is not only our Product organization who talk to customers each day — but that our support teams do as well. In the world of stair-like handovers, teams like support are often the last to be engaged for feedback.
Of course — being mindful that…
It is important to make sure that knowledge is available exactly when and where it is needed — not too soon, or it will have to be changed, and not too late, or it will have to be ignored¹
As Glinz & Fricker presented in their 2013 conference paper³:
The practice of short feedback cycles strongly influences impact by reducing the timespan between causing and detecting misunderstandings: the less time a misunderstanding has to unfold, the lower its impact.
The goal here is to address that key point — to reduce the time a misunderstanding (in our case, product feedback) has to unfold by having enabling awareness, and in-turn feedback, earlier in the value stream.
With early awareness, we’ll obtain greater levels of internal feedback.
Impact 2: Constrained Feedback
The second major impact we see is the constraint of feedback to immediate predecessors in your development value chain — which causes two major challenges:
1. The speed of communication slows linearly with the handoffs
2. A shared understanding of feedback isn't obtained
Instead — our goal should be to bring all stakeholders involved together quickly, develop shared understanding through conversation, assess and apply what was learned, and make refined collective decisions on that learning — creating a customer-focused organization.
With greater collaboration through conversation, we’ll achieve a better common understanding.
Three Steps to Slides
To combat these impacts of delayed awareness and constrained feedback, there are three areas of improvement you should focus on adopting across your organization:
Improvement 1: Sharing Product Development Responsibility
Our first step is to create an environment where all involved in the value chain share responsibility for getting the right product to market.
The best way to do this is to establish what’s known as a generative culture⁴ where trust is high, teams shared responsibility, there is safety for failure, new ideas are encouraged, and high collaboration exists across all teams.
As a leader, it’s all too easy to for failure to lead to scapegoating (power orientated cultures) or justice (bureaucratic cultures)⁴ —where you will actively prevent a learning culture that encourages staff to take risks, speak up, and lower barriers to communication⁶.
As Google’s DevOps manual⁷ notes:
The response to failure shapes the culture of an organization. Blaming individuals for failures creates a negative culture. If instead, failures lead you to ask questions about what caused the failures and how you can keep them from happening again in the future, you’ve improved your technical system, your processes, and your culture.
This doesn’t strictly need to take the form of cross-functional teams — but we do want to ensure all involved in the value stream have high trust and collaboration, so boundaries are loose and ownership of outcomes shared.
This allows us to look laterally, past the boundaries of our individual teams — and come together to optimize the whole¹.
Improvement 2: Establishing Continous Collaboration
The more groups supporting the value stream are informed of what value the product development organization is trying to achieve — the greater the collaboration and feedback they can provide to hone and improve not only the ends but also the means in which the whole value stream works together to achieve the product goals.
I’d written about this in my previous article on Lean Software Development:
Rather than manage dependencies, focus on handling them through regular sharing and collaboration — addressing them through communication rather than control.
But to piggyback the trend of applying the ‘Shift Left’ concept — we as collaborative product development organizations need to shift left on our shared understanding across the value stream — having early and open conversation on our target product goals and vision.
Improvement 3: Rally Around Shared Goals
Lastly, we need to look at our incentives and how they are driving the behaviour of everyone across the value stream. Too often we see incentives that are lag indicators.
Product releases on time, sales conversions, gross revenue — all driving reactive action to change course, and providing little influence on the future. Measuring the outcome relies you on waiting and seeing if the result is met, rather than actively curating the behaviours that drive the result
How many times have you come across siloed and lag indicator driven incentives like:
Support Desk staff measured on the number of tickets resolved (customers having to log more tickets), rather than measuring them on the absence of tickets (customers not having to log tickets)
Testers measured on the total number of tests they create and run, rather than the measuring them on how many defects they can resolve as early in the development cycle as they can.
Developers measured on the velocity of total story points delivered, rather than the value their development work delivers for the product.
What we need are compelling, lead driven incentives that not only drive behaviour — but are carefully constructed such that they drive shared values and norms towards the shared goals and vision. Things like stable velocity, sufficient quality, stable teams, and limited or no blockers.
This requires transformational leadership focused on removing the constraints of organizational silos through strategic alignment and shared goals⁵. As I wrote in my review of Accelerate⁵ — the key role of leaders and managers is to:
Provide your employees with control, empower them with a clear vision and goal, provide an environment that encourages experimentation and learning, create diversity in teams, and connect them with the products and customers they are building — and they will develop a strong sense of identity, and in turn, software delivery performance.
The Slide of Collaborative Product Development
When this all comes together, you will see a gradual transition of product development through to our customers. Teams will no longer be surprised and reactive, the information will flow quickly through your value stream, and your product and customers will be better off for it.
A practical example I recently applied — was transforming a Support & Operational organization to collaborate by driving the voice of the customer through into the Product Development organization. We incentivized the Service Desk staff to lower the number of tickets we received from customers, rather than focus on ticket throughput — showing that leadership cared more about happy customers than high team utilization.
We set up a rotation to have Service Desk staff to spend time with the product team to provide feedback in the form of service desk root cause trend metrics and inform and discuss backlog prioritization with them.
The Service Desk provided validated trends on the issues our customers were having on the product — and in return, saw Product saw that fewer customers needed support in using their product.
Optimize your value stream to be a slide of continual and collaborative delivery, not a flight of stairs of handovers and segregation.
Share product development responsibility, establish continuous collaboration, and create compelling, shared, and carefully considered goals — creating the structures, behaviours, and incentives to drive fast, effective product development.
Thanks to our guest blogger Trevor de Vroome for the collaboration on this publication. Whiteboard People have had the pleasure to work alongside Trevor on client engagements and value his experience and insights. In this article Trevor highlights the need to establish shared value stream goals which encompass all teams from Product to operations. Continuous collaboration early and often ensures we deliver the highest value products to our customers sooner.
References
Poppendieck. M & T (2006), Implementing Lean Software Development: From Concept to Cash, Pearson Education (US)
Kim. G, Humble. J, Debois. P, Willis. J (2016), The DevOps Handbook, It Revolution Press
Glinz. M, Fricker. S (2013), On Shared Understanding in Software Engineering, Software Engineering — Multikonferenz Software Engineering
Westrum. R (2004), A typology of organisational cultures, Quality & Safety in Health CareForsgren. N PhD, Humble. J, Kim. G (2018), Accelerate : The Science of Lean Software and Devops: Building and Scaling High Performing Technology Organizations, It Revolution Press
Peha. S (2013), The Fail-Safe Organization, InfoQ
Unknown (2019), DevOps culture: Westrum organizational culture, Google