So everyone is moving to a DevOps world these days. It’s cool to say my company uses DevOps.
Do you have a DevOps team? Have you just hired someone who says they do DevOps and have formed a team? NONE of this is DevOps.
Do you have a DevOps role open currently? This is still not DevOps.
So then what is DevOps?
Well, we can all agree that integrating testing into a dev team was the right idea. No longer are there giant teams that argue all day and pass work over a virtual blame wall. Now we have testers that work alongside devs to deliver value to our customers. BUT how can we deliver that value if the teams can’t release software.
I have seen the world where a team is doing everything right. They are working together to produce value. They are visualising their work using a Kanban board, and they are even using pair techniques such as BDD to remove rework between the business, test, and dev. But the last lane on their board is, “Ready to release”.
The work piles up there forever. It then gets pushed to the “DevOps” team to fix the problem. In this case management just wanted to know how fast the team where getting work through the board. Not realising it didn’t matter if it took the team a week or a month to deliver a story, If the work was just going to sit on a test server for months waiting to be released.
This is a fall out from giant tech projects. The idea being that a spec doc is written up and a 6 month deadline is given. Once work is progressing inside that 6 months then boxes can be ticked green and everything is on time……nobody cares about actually releasing. Nobody cares about customer value.
So in the above teams case they had to wait on the DevOps team. Now the name DevOps was just used for what was basically an unintegrated ops team. This is NOT DevOps. DevOps is developers DOING ops work. It’s a collaboration between dev and ops. It’s not throwing the work over a new blame wall to the ops team and saying, look our bit is done it’s their problem now.
I was lucky enough to see Janet Gregory speak at the SoftTest conference in Dublin last year. She was kind enough to send me her slide on this which sums it up brilliantly. If you don’t know Janets work I urge you to check her out. (https://janetgregory.ca)
We can see here that it’s everyone helping. By doing the same as you probably have already done to integrate test into a team, you need to bring the ops folk along as well. Instead of having them separate why not go invite them along to your teams standup?
Also if there is pressure from the ops side as they feel there is not enough people to do all the work, what better way to fix that, than training devs or even testers on the team to be able to do the ops work.
Instead of building up backlogs for the ops team. How about assigning an ops engineer to sit with one of the agile teams. The ops person is then free to unblock the teams ready to release items. Together they can prioritise work like building a delivery pipeline so that the pesky releases can be automated.
Instead of having to waste valuable time manually deploying code to servers, these tasks can be automated to remove human error. Eventually much like what happened between dev and test a trust will be built between the ops side and the team side. Soon your team will be able to actually complete work. Instead of waiting till near the end of that 6 month deadline you can release as each story is complete. Think about the value that will deliver to the business?
If they release software that is not actually solving anybodies needs then brilliant. No need to keep working on that project. You can scrap the work that only took a few weeks to build test and deploy, instead of wasting more company time and money on delivering software nobody will use.
This is only possible if there is a collaboration between ops and dev teams.
Now there could be other blockers, what about security? Why not bring them in early as well. The sooner each department in the company realises we are all working together to deliver value, the better the software will become, thus the happier the customer will be.
As with anything I suggest starting small. Trial this on one team first. Monitor it closely to see what works and what doesn’t. Then take what works and roll it out to some more teams.
So DevOps is a team effort, and by team I mean everyone involved in the life cycle of software, not just the ops folk. Try it and let me know how you get on.
Remove the blame walls.