The most commonly accepted definition of DevOps is that it is a movement. There are many discussions around the approaches that would work best to adopt DevOps in a specific context. Most of these threads talk about the need for culture, automation, lean thinking etc, and those that get into a little more details in terms of the engineering practices talk about Continuous Integration or Deployment, automation of infrastructure related activities etc.
This post is about how you can easily map on the underlying principles of DevOps on various activities across the Software Lifecycle. I call it the software lifecycle – to distinguish it from the SDLC – that is essentially about the software Development lifecycle. When you take a customer centric view and are focused on delivering value incrementally and steadily – aka continuously – you need to internalize the key DevOps concepts across the various steps in a typical software lifecycle, covering both the engineering and management aspects. I usually recommend a model where we group various activities under 10 buckets. These are:
- Backlog management
- Full life cycle
- Configuration management
- Architecture
- Shifting left
- Managing the user experience: deployment
- Continuous Deployment and Delivery
- Monitoring the user experience : track and analyze
- Governance
- Feedback loops
In each of the above, there are some commonly accepted good practices as well as some anti-patterns. I have shared more details on each of these in a 22 minute recording.
Once you have understood this, you would be ready to plan your DevOps journey. We recommend a six step approach to DevOps adoption. More about that in a later post. Meanwhile, if you have any comments or experiences to share on your own DevOps journey, please reach out. Of course, if you have questions, just ask!
2 Responses
While the solution is simple, its implementation will be tough since the business would not easily sponsor them. While it is a good idea to write all technical debt stories, generally, there will not be any Product Owner who likes to own and accept since the PO comes with business mindset. These kind of work is pushed by external team (not the scrum team). Generally, these is a lack of ownership of these stories and pushed by external teams. I am purposefully, I am not the solution this gap in this comment. Want to hear from others.
I agree Guru. The reason why i mentioned this as a Dilemma for the Engineering manager is do we handle only the low hanging fruits and run with it, or would you work for a harder and more difficult transformation of creation of a working pipeline.
I know one manager I have interacted made the call and felt the next 6 months extremely hard to convince and influence different stakeholders. This is easier to accept while you are doing a transformation.