Stop Talking About Continuous Integration
There. I have said it. This is the elephant in the room. For years, we as Dev Ops professionals, and as an industry have been talking about how to up our game using Continuous Integration. We talk about our Software Development Life Cycle (SDLC) or how we need to improve our QA Processes and deliver faster and with higher quality.
We start implementing Continuous Integration and we try to implement Continuous Delivery and or Deployment. And you know what happens? We fail to do it the way others did. There are some examples that we try to wedge ourselves into. We try hard to mimic what others have done. And so we fail over time. Some of us, we get to where we want to be, but others...yeah...let's not talk about it!
So what should we be doing? We should be talking about Continuous Confidence. We should be talking about what processes and what things are we doing that will help us get better confidence in our product. What will give others better confidence in our product.
When we talk about our SDLC, can I be honest...don't. Don't use that term. It is a convoluted term created to sound smart. It is archaic and causes us to be bound to waterfall processes that limit our agility in the Software space. So, break it down! Think about what makes things less effective in your company.
When we talk about improving our QA processes for higher quality, stop thinking that QA is the last defense! Hold your developers responsible for what they write! Let your QA guide your development team to a higher standard. Let your QA processes be built around finding confidence in software development and proving that your team is doing what was promised to the product team.
Use your confidence to hone your skills and processes where in, if Continuous Integration/Delivery/Deployment are the tools for the business...use them! If they aren't, don't. But most important of all...recognize, that your business is unique. Your software is unique. Just because one process worked elsewhere, doesn't mean it will work for you without changes and understanding.
Ultimately, let's give each other permission to innovate where it matters! Let's continuously build confidence around our teams and product.
We start implementing Continuous Integration and we try to implement Continuous Delivery and or Deployment. And you know what happens? We fail to do it the way others did. There are some examples that we try to wedge ourselves into. We try hard to mimic what others have done. And so we fail over time. Some of us, we get to where we want to be, but others...yeah...let's not talk about it!
So what should we be doing? We should be talking about Continuous Confidence. We should be talking about what processes and what things are we doing that will help us get better confidence in our product. What will give others better confidence in our product.
When we talk about our SDLC, can I be honest...don't. Don't use that term. It is a convoluted term created to sound smart. It is archaic and causes us to be bound to waterfall processes that limit our agility in the Software space. So, break it down! Think about what makes things less effective in your company.
When we talk about improving our QA processes for higher quality, stop thinking that QA is the last defense! Hold your developers responsible for what they write! Let your QA guide your development team to a higher standard. Let your QA processes be built around finding confidence in software development and proving that your team is doing what was promised to the product team.
Use your confidence to hone your skills and processes where in, if Continuous Integration/Delivery/Deployment are the tools for the business...use them! If they aren't, don't. But most important of all...recognize, that your business is unique. Your software is unique. Just because one process worked elsewhere, doesn't mean it will work for you without changes and understanding.
Ultimately, let's give each other permission to innovate where it matters! Let's continuously build confidence around our teams and product.
Comments
Post a Comment