How to implement devops and still be able to develop new features
I would like to have everybody's opinion on the implementation of a devops team. Or to be more specific: we have a dev team and would like to make it a devops team.
We started to also pick up bug fixes, performance issues and other operations tasks, but then struggle to be able to develop new features. Our scrum team consists of three developers.
What is your experience with the transformation or start-up of a devops team?
Some questions:
- Start with dev only first of immediately integrate operations? Why?
- How big is your scrum team and should/could this influence the ability to integrate operations?
- Are new featues being handled differently than bugfixes a.i.?
I'd love to hear of your experiences!
DevOps is an overloaded term that seems to mean a different thing every week. That said, there are two reasonably consistent components that seem to underpin a successful DevOps model. The first is the most obvious: the removal of team silos between Development and Operations. The other component is the use of CI/CD and automation tools in order to achieve a very lean value stream and reduced batch sizes.
That first component is the one that gives DevOps its name. Ironically perhaps, it is nothing more than an agile best practice that teams should aim for anyhow. In Scrum, for example, a team should deliver potentially releasable increments of value each and every Sprint. This implies that the Definition of Done is robust and complete enough to encompass all parts of the value stream through to delivery...development, operations, marketing...whatever.
So I'd say that the first step towards DevOps is to do Scrum better. This means removing silos wherever you find them, not just between Development and Operations, but *within* these functions where they can still be endemic. It's amazing how many supposed DevOps teams you find with rigid skill silos that are balkanized around technology stacks. Sure, they've found ways to bridge development and operations...but they still segregate themselves between Windows and Linux platforms, or between aspirational and legacy products.
The second component is perhaps the more intriguing one. If CI/CD is in effect then the batching of work into Sprint Backlogs can become moot. The decision whether or not to continue sprinting, or to run DevOps in a leaner fashion, is one that must be taken based upon risk. How small can your increments be in order to provide value and elicit useful feedback? Can you really optimize your deliverables down to single piece flow?
The implementation of CI/CD is quite a big step. Especially within rigid organisations that are just beginning to grasp the concept of Agile and scrum.
I agree that having CI/CD implemented the integration of operations will be much easier. And I agree you can do scrum better that way. But we're not that far yet. I does however got lots of attention.
I've heard of organisations starting up scrum with just development, therefor not "eating your own dog food". The latter I think being an important part of the learning process when starting scrum.
I'm curious to what people's experiences are within scrum start-ups?