Alignment and flow. Sounds like a Vinyasa yoga class. What they really are is management trends. But even the word management seems off. Because when you’re managing alignment and flow, you’re intentionally giving up much of your power. You’re following the path of a servant leader who is constantly looking for ways to make your teammates’ lives easier.
Maximising for flow and alignment is not about five-year plans. It’s about continuous improvement sprint by sprint, working holistically with individual competencies to provide added value for your customers.
It’s about accepting your team’s capacity, while always on the lookout for ways to remove bottlenecks. It’s breaking down communication silos, enabling access to information, so everyone can actively contribute to adding value. And it’s about increasing cross-organisational psychological safety.
Mary Poppendieck, co-author of Lean Software Development and The Lean Mindset, argues that unless you’re running an open source project, you should burn that backlog. “People have become way too comfortable with backlogs,” she says. “It’s just a bad, bad concept.”
For OSS, backlogs serve a purpose, providing evidence of engagement with your product. But at a proprietary organisation, you should be measuring engagement of your stakeholders—namely, your employees—in other ways. So a backlog just becomes something that weighs you down in irrelevancy.
Without a backlog, your organisation stays aligned around this sprint and maybe one or two more, focussed on what creates immediate value. You give the individual contributors the autonomy and power of “now, next, never”—to accept or reject new tasks—because they are well aware of their capacity and output—and the ability to say, “not right now, but definitely for the next sprint”.
“What you want to do is have very new stuff that’s waiting to be done and a way to make that decision right away,” Poppendieck said.
She refers to this as your throughput rate. Instead of trying to optimise for efficiency all the time, this leaves leadership and coaches focussing on aligning teams and decision making around managing throughput, workflow and delivering immediate value. Because, once you know your capacity limits, why would you waste the limited time you have on work that doesn’t add value right away?
She says that throughput is probably the most reliable measurement out there, as most organisations are using it already. With the Cloud Native world of containers and microservices those units keep getting smaller, but stay consistent. How many units can each contributor release in a sprint? Excepting unforeseen circumstances and automation, that’s unlikely to vary very much.
“Accept that as the rate that you put out. You don’t estimate. You don’t prioritise. You make a decision when somebody asks you to do something if you have the capacity to accept it,” Poppendieck explained.
She says output is a measure of capacity; at full output, you’ve reached capacity.
“If people ask you to do something and you don’t have the capacity, saying ‘I’ll put it on my backlog’ does them no good and it does you no good. It’s just a lie. You know your output capacity. You know the rate at which you get stuff done. And that’s only as fast as you’re going to move,” she said.
Different people of course will have different capacity levels, but that doesn't mean some are better than others. Technology workers are creative workers and have to work in the optimal environments and at a speed that suits them individually.
The ability for teammates to understand their capacity and to feel able to (politely) say no comes down to psychological safety. This extends to making sure people don’t feel pressured to increase their capacity—because quality will suffer. The majority of software organisations are working at full capacity as it is.
“It is an insult to teams to assume that they are not working as hard as they can, so if demand exceeds capacity, a team’s output should be assumed to be its current capacity,” Poppendieck said.
This is why performance shouldn’t be tied to capacity. We aren’t hiring robots, at least not yet.
It then becomes the job of management to understand their teams’ capacities and to make sure they protect their teams from being overburdened with an impossible amount of work. This means knowing when people are going on vacation so you can temporarily reduce the capacity of your team, and knowing when it’s time to expand your team to expand your capacity. Not overloading people is the easiest way to prevent burnout.
A: okay, but I want them to do more.
— Agile Otter Tim (@tottinge) June 9, 2020Burning the Backlog and Aligning to Flow
B: Great. What have you tried?
A: I tried assigning more, but it didn’t help.
B: It wouldn’t if the work is too much already.
A: I thought they’d figure out how to do more.
B: Unlikely, b/c they’re too busy for that.
Your role is to take the chance out of these outputs. Except for unforeseen circumstances like pandemics or major outages, you know your team’s capacity and they will deliver on that capacity sprint after sprint.
A key part of capacity management is that leadership and coaches should be looking for ways to reduce bottlenecks by, for instance, looking at what can be automated in a DevOps pipeline to allow for more focussed creative work. If the team’s output starts slowing, it’s up to leadership to figure out what in the system is causing that downturn.
And again it requires that leadership also feels psychologically safe to say the important “now, next, never” needed for good capacity management to their bosses.
Of course you then need to make sure that everything you do is aligned with customer-serving, organisational goals. By getting rid of the backlog, you naturally focus more of the available capacity on things that will immediately improve the customer experience.
Philippe Guenet, a digital leadership and flow coach, says it’s not just about understanding those units and the capacity, but how they connect to form a value stream. And in the ability to guide that stream when the focus has to shift.
“We are living in a world where change is a constant and adapting rapidly to change is a constant,” he said. “A lot is changing, and seeing flow in an organisation and seeing flow across organisations is essential. As a leader, being good with digital is a pathway to being good with change.”
Guenet adds that alignment isn’t about artificial harmony. It’s about understanding and perspective. Like most things in technology these days, that makes it continuous. It takes frequent revisiting to better understand your role within the organisation.
He pointed to the automotive industry, which is especially good at responding to change, as it undergoes the current dramatic transition from combustion to electric engines.
For him, flow is business and technology working together, bringing technology into the value chain, which is how customers interact with your business anyway. This is reflected in the shift in the focus of digital transformations over the last decade or so. “It’s no longer about bringing a budget to IT, it’s about bringing value to the customer. It’s about bringing responsibility and sustainability into business value chains. An opportunity, through change, to do business better,” Guenet said.
So flow becomes identifying the teams that have agency in an organisation and understanding the systems, in order to ease barriers and smooth flow, which will of course go faster.
For Guenet, it’s more than just understanding the systems, it’s about understanding how to connect them in a flow—not in a flow of work but in a flow of value. Flow systems are referred to as not pillars, but rather the three DNA strands of an organisation: complexity thinking, distributed leadership and team science.
Guenet paints business agility and flow as two contrasting but symbiotic forces. Agile is about pivoting, while he sees flow as much more linear and repetitive. After all, its origins are in lean and production chains, dating all the way back to Toyota declaring a customer-first strategy in 1946. For Toyota, creating flow for customer-first was about the production line. For modern organisations, it’s about different value streams, like sprints, Kanban boards, programming increments, and DevOps pipelines.
Running somewhat counter to Poppendieck, Guenet said, “It’s not so much about throughput as it’s about outcomes. Anything that's getting done should add value that the customer cares about. Everything that people do should have a value-added that the customer cares about, and that brings flow into the faster changing world.”
Guenet wonders how we could ever really achieve anything if things are in constant flux. This is where complexity thinking comes in. We all work in complex, adaptive systems, so we must accept and embrace it, not as a source of trouble, but as one of inspiration and innovation. And then look to improve the things like DevOps pipelines and behaviour driven development, which have a logical flow.
Another part of embracing flow is that it requires distributed leadership, pushing as much leadership and decision making down to the team level, aligning everyone around customer value. According to Guenet this level of autonomy is probably the hardest bit, because everyone needs to have access to all the information in order to be aware of context and outcomes.
“People are aligned from different systems of architecture, but not for value. How are the teams and the leadership and the multi-team systems and the organisation aligned to add value to the customer?” Guenet asked.
This can be direct, like QA teams helping improve the customer experience by limiting downtime, or indirect, like DevOps change teams helping everyone move in the right direction.
Harkening back to Poppendieck, Guenet said a flow system focuses on “alignment around quality and operational excellence, and making sure that people have the headroom to create quality.”
He asked, “We pressure [team members] to deliver more and more, but how do we resurface quality and have an alignment?”
Guenet argues we have a lot less capacity than we really think, at least capacity that’s dedicated to increasing value to the customer. He broke down the rough approximations:
The true value-added, namely adding new features, often comes down to 15% of the time spent, which Guenet said isn’t bad if you aren’t trying to expand much. “But if you’re expecting a lot of development out of that, then you’ll need fire fighting.”
When management streamlines the processes and lessens the friction, teams are less burdened and can spend 20 to 30% on adding value.
However, a lot of organisations will overburden capacity and expect an unacceptable 60% of time dedicated to features, which means “you are leaking technical debt and we are letting things through with not enough testing, not enough test cases, with workaround solutions.”
Eventually that creates instability which will eat even more into your capacity, and there’s not enough to invest in fixing that. Nor is there enough to invest in your people for resiliency. And none of that mathematical equation included people, who are at greater risk for burnout. As Guenet said:
We invest in technology, but are we investing in people too? We don't account for the people. They will be the ones that last.
Software is seen as an asset, but it is also a liability. Technology changes so fast, but people organised in functional teams in digital are the real asset. Therefore we should invest in people and team work most of all.
Investing in people is when you grow your assets.
The final strand of this flow DNA is team science, which involves embracing truly cross-functional teams. Anyone, from product owners to compliance teams to architects, can stand in the way of the team. Instead, you need to make them part of the team. Guenet has worked mostly in the highly-regulated finance industry, where he has even put an auditor in each team to make sure things are done in a compliant way and then that it’s built into the DevOps automation.
It’s the job of leadership to enable the direction of the team and to facilitate working with other parts of an organisation.
He says this is about making sure you invest in their resiliency and training, that you take the time to reflect on how the team is working—“very few people do that”—and that you continuously measure the psychological safety of the team. It’s about focussing on briefings and debriefings, and how to improve retrospectives.
Much of what inspires Guenet is kaizen. Japanese for “change for the better” or “continuous improvement”, kaizen embraces experimentation and innovation toward achieving excellence. We spend so much time working on continuously improving the code, but how often do we focus on improving our connections and how we work together?