Patrick Debois (@patrickdebois) is the founder of DevOpsDays, another conference to support the growing DevOps movement. He does not know the future, but he sees patterns. And today, we’ll see some of those patterns—hints of what may lie beyond dev and ops.
As interesting as the DevOps pipeline is, we’re going to look at what lies beyond it. Many teams see the product backlog as a point of entry. But if your delivery pipeline works well enough, what’s the next bottleneck? To answer that, we can look at other departments in our organization.
The first department we can find bottlenecks is sales. How can we have an agile sales pipeline that feeds into our backlog? A book by Justin Roff-Marsh called The Machine presents some ideas.
There’s often a sales process with a lot of players in place. If you look closely, this process looks like a Kanban board, a key tool in DevOps! We want to connect this process to our backlog, which for most teams currently is akin to magic. How do we improve in quickly and reliably connecting them?
It feels like sales people are good mind readers when it comes to what customers want. But they often focus on the cost to make something instead of the value that thing will bring. Value and cost are often not connected.
Screenshot from Patrick Debois’s “DevOpsDays: Hints & Glimmers Of Things To Come” presentation.
Our backlog and our plan really starts at the beginning of the sales process. Like product roadmapping, sales has its own cone of uncertainty. As sales comes closer to an agreement, things become more certain. It’s understood that estimates at this point are not promises.
The sales relationship is also continuous—it’s not a project that gets “done.” Yet contracts are written as if they have a stopping point. Agile delivery handles this well, but current sales processes don’t.
We can help sales with their process by making things simpler. By making things simple, the value will be clearer and easier to sell.
Documentation also helps sell engagement. It’s often ignored by developers, but making it a first-class concern will let us land more deals. This also makes customer support easier, which turns out to be a big reason why customers stay loyal to an organization.
Overall, DevOps and sales can go really well together.
Beyond sales, there’s another pipeline secretly connected to DevOps: the marketing pipeline. Without both marketing and sales, it would be really hard for software professionals to do their job. A key part to DevOps is automation, and marketing actually has some intriguing automation in its pipeline. They also track metrics, using things like website heat maps. They even apply lean principles to their pipeline.
An IT department can really help marketing. A great example of this can be found in the book The Business Value of Developer Relations by Mary Thengvall. It talks about this in depth.
Marketing is like IT’s grandmother: they are developers’ biggest fan! So keep a marketing perspective in mind when working in your DevOps pipeline.
DevOps may benefit greatly from your budgeting approach. Instead of traditional budgets, look at using rolling budgets that are focused on product and value streams, instead of vertical functions like database, QA, etc.
DevOps and finance can go together beautifully with the right budgeting strategy.
DevOps can benefit by being agile in your procurement. A great way to approach agile procurement is by using lean procurement canvases, which focus on the risks of finding the right partners and team fits.
How we approach serverless is a good example of agile procurement. In a serverless mindset, we procure a myriad of partner services, such as Gmail, to manage our system. This is superior to building most things ourselves.
As DevOps teams, we need to embrace our suppliers and the tools we procure from the outside.
There’s a manifesto for agile HR development to better support your employees. It hits upon collaborative networks, transparency, adaptability, and inspiration for managing people-centric challenges.
Automation is even invading HR. A great example is Shopify occasionally and automatically removing all recurring meetings off employee calendars to encourage more dynamic collaboration instead of traditional meetings.
Microsoft embraced agile HR by trying a four-day work week. Productivity shot up as a result of this experiment.
There are some team room practices that are not strictly a part of DevOps but can increase performance. Mob programming is a great example. Everyone is collaborating and watching a problem at the same time, which can reduce handoffs and review times.
Mob programming as depicted in Patrick Debois’s “DevOpsDays: Hints & Glimmers Of Things To Come” presentation.
Overall, there are so many other departments that can have value for how DevOps works. And we can also give them value. Don’t just stick to your own IT silo. Look at how you and your other departments, such as marketing, sales, and finance, can partner together.
This post was written by Mark Henke. Mark has spent over 10 years architecting systems that talk to other systems, doing DevOps before it was cool, and matching software to its business function. Every developer is a leader of something on their team, and he wants to help them see that.
Photo by Giu Vicente