Full Enterprise Adoption: Ways of Working

For the audio version, click here>>>

I’ve been observing a pattern for quite some time now with my clients that in 2017 I referred to as BizIT — that is, these conversations about Ways of Working* have been seeping out of the technology teams and into ‘the business’. It’s digital disruption that is driving the global evolution towards these ways of working that are characterised by:

• Incremental change to reduce risk and create fast feedback loops
• Small, dedicated, autonomous, cross-functional, multi-functional teams
• Long-lived product-centric thinking, unlearning project-centric habits
• Empowerment, participation and peer-review
• Breaking dependencies, impediment removal and streamlining processes
• End-to-end, value stream thinking and experimentation
• Focus on customer delight and the delivery of value outcomes
• Increasing throughput and stability as equal forces

And because technology and digital disruption is driving the appetite and action for the adoption of these evolutionary ways of working, the effort is initially driven by technology teams in an organisation. Since the work I do often starts with a DevOps conversation, I typically begin by helping resolve conflict and tensions between the development and IT Operations teams, but as these teams improve the way they collaborate by breaking down barriers between them, it quickly becomes apparent that the organisation around the technology teams, ‘the business’, presents a whole new set of constraints that must be addressed in order to fully realise the benefits of these alternative ways of operating.

I say ‘the business’ because I fundamentally don’t support the concept that the technology teams are separate from the business. I can see how we got here: I understand that technology is a relatively new part of some of the organisations I work with which may have been operating for as long as two hundred and fifty years. I can see how technology started as a back-office function and that it needed to be managed as a cost centre and that departmentalising it in the way that we did back then made sense. But if our success in a digitised world is dependent on our ability to deliver technological services effectively and efficiently, these teams can no longer be order takers; they shouldn’t merely be aligned to or integrated with the business — they are the business. This is reflected by how some organisations respond to the question: “Are you a technology organisation?” — see how Domino’s, Alaska Air and Target view themselves. Every company is a technology company.

The key constraints I see that are driving the conversations outside of the technology teams are in these areas:

• Project driven funding stifling our ability to truly create long-lived products and teams
• Product owner people unavailable making fast feedback impossible
• Customer and supplier contracts that make it difficult to collaborate daily
• Regulations that are perceived to set deadlines and that require project thinking
• Performance reviews, KPIs and bonuses that drive the wrong behaviours

Change agents and leaders already have a hard time driving, articulating and sharing a vision and bringing stakeholders at all levels on a journey that is fraught with challenges, resistance and backward steps. They need to advocate these ways of working to whole new sets of people outside of the technology teams, each with their own unique methods, practices and cultures is another a big ask. Here are some things I see working:

With the Money People: “Project driven funding is stifling our ability to truly create long-lived products and teams.”

It’s nigh on impossible to run a long-lived team with short(er) term funding injections i.e. projects. We can’t create the cadence of enhancements and experimentation that these ways of working demand and it’s very difficult to prioritise improvement over function which leads to more technical debt and more fragility.

There has to be a continuous flow of funding for each team and goals set around small value outcomes that are frequently reviewed. I have observed some teams in some enterprises manage to stream project funding into a small, functional team and a single product backlog and charge it back in story points in a way that made funds and time available to tackle technical debt. But what we really need is the money people on board to break the annual budgeting cycle and work with trusted technologists on the continuous delivery of measurable value.

With the Selling People: “Product owner people are unavailable, making fast feedback impossible.”

I asked Mark Schwartz, author of ‘The Art of Business Value’, ‘A Seat at the Table’ and ‘War & Peace and IT’ recently his opinion on this common problem I see where technology teams are embracing agile ways of working and want a product owner person from ‘the business’ to support the fast flow/feedback and careful refinement of requirements as user stories, but can’t get it and end up with a Product Owner by Proxy situation.

Mark said: “Simply, if you can’t invest in your people, then what you say you want to do is not worthwhile.”

I have observed examples of successful technology delivery in a legal firm where fee-earning lawyers were product owners, and in a bank where traders were product owners. In each case, the change leader’s job was hard, but the organisations recognised that if the customer wants to get what they want they have to, as Mark says, be convinced it’s important for them too to put in the hours. Check out this story from Capital One.

With the Buying People: “Customer and supplier contracts make it difficult to collaborate daily.”

While it’s difficult to tell customers to work in a different way, the customer is always right, after all, when our customers are consumers it’s likely they are going to prefer continuous incremental improvements to their web and mobile services. Where this becomes a bit more tricky is when the customer is another business and they are not yet ready for work to be delivered in small increments, and may not yet be thinking of (or able to) working in close collaboration with the vendor/supplier. The agile manifesto though advises to value (customer) collaboration over contract negotiation. I think this works for suppliers too.

For customers, the keywords are evangelism and experimentation: if you believe there is a way of working that will deliver more value, faster and more predictably to your customer, ask them if they want to experiment with you on it. For suppliers, you can look at approaches that reduce the lead time of sourcing a new partner, reduce risk and solve the most important customer problems first.

With the Legal People: “Regulations that are perceived to set deadlines require project thinking.”

Let’s start again with the notion that incremental, frequently reviewed processes reduce risk, don’t increase it. Whilst a new or updated regulation may have a drop-dead date (with very serious and far-reaching consequences) that doesn’t mean it cannot be solved in an iterative manner.

One of my banking customers was hit by a new regulation at the back end of 2018. Using their newly acquired capabilities around iterative delivery, they rallied together around the challenge, achieved all they needed to in the time frame required, and left themselves well-positioned against their competition after the drop-dead date. They never lost sight of the date, but frequent feedback kept everyone focused on the goal. And what’s more, the iterative delivery model allowed them to be flexible in their delivery and eliminate waste as their understanding of the regulation, and the regulation itself evolved.

With the People People: “Performance reviews, KPIs and bonuses drive the wrong behaviours.”

Here it is again: little and often. Annual review cycles are painful and annual bonuses are toxic. I have clients who have paid out annual bonuses to everyone equally and others who have done away with the concept entirely and increased everyone’s base salary. I have others who are experimenting with micro-bonuses and peer-to-peer credits.

If we can’t measure it, we can’t improve it. We measure to learn first and then to improve but we don’t measure to target. If you must have targets, then think of them as goals based around value outcomes. Individual goals are not as effective at driving collaborative behaviour as team goals. If you set one goal, say deployment frequency, make sure you have a goal to ensure that this doesn’t just encourage teams to deploy *anything*. And if we’re talking about empowerment, who better to set goals than the people expected to deliver on them? Autonomy, mastery and purpose reward people better than cash.

In conclusion, we are all people, people. These new ways of working require us to step up our game and understand the end-to-end system. The definition of done isn’t: “I did my job” — it’s: “Our customer received value.” The human side of this is happening as these conversations heat up, and I’m seeing green shoots in the automation world for this end-to-end, holistic thinking with new market categories like value stream management and software delivery management. Watch this space.

Ways of Working is a catch-all term I use to avoid ‘buzzword bingo’ and encompasses the principles and practices espoused by the likes of DevOps, agile (and agile service management), lean, learning organisations, safety culture, DevSecOps, Holacracy, SRE, The Theory of Constraints, organisational change, systems thinking).

DevOps Institute is dedicated to advancing the human elements of DevOps success through the SKIL Framework: Skills, Knowledge, Ideas, and Learning. Learn more.