DevOps is done, time to start focusing on ProDevOps

By bringing development and operations together organisations have been able to generate a smooth, seamless and joined delivery systems. Amazing things have happened, companies that released software once a month are now able to do this every couple of seconds. Over utilisation of servers that used to take months to migrate onto more powerful boxes can now be automatically scaled in the cloud. The old concepts of developers pushing for change and operations fortifying the walls of status quo are dying out. Well done DevOps your work here is done. OK, it’s being done, work in progress however the mindset seems to have bedded in.

So what’s the challenge?

Well we’ve streamlined everything from development to delivery, the challenge is that many in IT feel that this is end to end. Throw an idea into the corporate machine and a finished product will plop out of the other end. That’s a good thing, right!

Well yes and no, it’s a good thing that things seamlessly go from idea to delivery with the least amount of hassle as possible. It’s fantastic that what is delivered is robust, scalable, monitored and supported. This is all good stuff but it’s not the core of what our customer and potential customers need. What they really need is for the pipeline to be streamline truly from end to end. From understanding of the customers need and desires to the delivery of that into their hands.

So I’m calling for our focus to shift from development and operations to a wider perspective which includes product and customer as well. Instead of this linear thinking let us move to a closed loop starting and ending with the person who will use our system.

Lets create a system that will allow our team to experiment around our customers needs rather than the highest paid person making their best guess. The team can be truly cross-functional in everything it does, it can leverage the disparate skills that make it up to create something more than the sum of its parts. We can recognise that nothing that is released into production is the end of the line. It’s the beginning of the learning opportunity.

In 2018 I was lucky enough to meet some truly engaged individuals at [Product] Jam 2018 and at Agile on the Beach 2018. I’ve also been lucky enough to work with an organisation that has grasped the CI/CD challenge with both hands. However many of these experiences have demonstrated that a lot of people still look at optimisation from a very parochial perspective. Optimising the delivery of software is amazing but if you are still writing software that is not needed or understood by the customer then it’s a waste. Writing high quality coded that is easily understood, clean and well ordered with related support from automated tests is again a lofty goal but still doesn’t have any benefit if you are developing the wrong thing. Coming up with an amazing product idea and handing that baby over the wall for the techies to deliver doesn’t allow you to learn if your educated guess was any better than the next persons. It also makes it less likely that your vision will get delivered. We have to work together to optimise the whole.

10 things I think #ProDevOps should encourage:

  1. You don’t know the solution until one of your assumptions proves to solve a real humans needs or desires. Avoid talking about solutions
  2. Don’t have any hand-off in the process. Create a team that can ideate, design, develop, deliver and interpret the results. Don’t create silo’s between product people, developers, ops and data experts. Create one team that can do it all
  3. Development is not the start of the process, in fact avoid it until you have some insight into which assumptions are likely to be correct.
  4. Delivery doesn’t end with a release to production. You may find your assumption transforms into a beautiful solution or you may learn a hell of a lot about the people who use your product and the problems they want resolved.
  5. Always code for the person sitting across the room from you. If they can look at it in a month and explain what you wanted to achieve then it’s good code.
  6. Always automate everything that can be automated. A good developer or ops engineer is a lazy developer or ops engineer. They want the mundane repeatable stuff out of their way so they can deliver great things.
  7. If you want this team to do amazing things then provide them with all the support you can. If you can treat them like a start-up with-in your organisation.
  8. Be very clear about your constraints and thus very clear that everything else is not a constraint.
  9. Avoid anything that encourages just product people to design, just developers to develop and just ops people to deliver. People will feel it’s more efficient to stay within their skills boundary but this is largely because they don’t see the waste of hand-off between boundaries. Ensure the team are all focused on the same goal.
  10. Solve human needs and desires.

I guess the other thing is to have fun and celebrate success. Oh and one for the Scrum masters, Agile coaches, Agile deliver managers (what ever that means) lets stop arguing about who’s agile is more powerful. What is or isn’t in this or that framework. Lets avoid scaling where-ever possible. Lets focus on supporting organisations to achieve positive change in human behaviours both inside their walls and out.

I’m interested in why you do the things you do and why I do the things I do. I help people explore their truths and business engage their individuals.