Get Certified as a DevOps Leader at DevOps World | Jenkins World 2019

Editor’s Note: This is a guest post written by Helen Beal , product owner of the DevOps Institute. Helen will be speaking and leading a workshop at DevOps World | Jenkins World 2019 .

I’ve observed 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 characterized 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

*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, organizational change, system thinking etc).

And because technology and digital disruption are driving the appetite and action for the adoption of these evolutionary ways of working, the effort is initially driven by technology teams in an organization. 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 organization around the technology teams, ‘the business’, presents a whole new set of constraints that must be addressed in order to fully realize 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 organizations I work with which may have been operating for as long as 250 years. I can see how technology started as a back-office function and that it needed to be managed as a cost center and that departmentalizing it in the way that we did back then made sense. But if our success in a digitized world is dependent on our ability to deliver technology 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 organizations respond to the question: “Are you a technology organization?” - 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 behaviors

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. That 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 prioritize 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’ about his opinion on this common problem in which 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 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 organizations recognized 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 valuing (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 and frequent feedback kept everyone focused on the goal. 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 behaviors.”

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 microbonuses 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 behavior 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, controllery 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.

Leading people through a DevOps evolution requires new skills, tools, innovative thinking, and transformational leadership. Leaders up, down and across an organization must align and collaborate to break down silos and evolve the organization.

If you want to learn about this (and get certified!), come join me in San Francisco at DW|JW in my DevOps Leader workshop. The DevOps Leader course is a unique and practical experience for participants who want to take a transformational leadership approach and make an impact within their organization by implementing DevOps.

Register here to attend DevOps World | Jenkins World in San Francisco from August 12 to 15.