DevOps has risen in popularity over past twelve to eighteen months to the point that most enterprises are either practicing something they call DevOps or are at least exploring how they can leverage DevOps to be more agile. The problem companies are having with DevOps is that it is not really a thing that comes with instructions or a framework that is prescriptive in nature. DevOps is instead a shift in the way we approach building software and even running a company. The age-old way has been more factory oriented, where software went from inception to production by passing through various silos of specialists (developers, testers, security experts, system administrators, operations, etc.).
Articles Tagged with agile
Ask five IT people what the term DevOps means, and you will likely get five completely different answers. Go to any online job board, search DevOps, and look at the job descriptions, and you will see great disparity in the desired skillsets and responsibilities, as well as job titles. Go to LinkedIn and search for people using DevOps, and you will see thousands and thousands of people calling themselves DevOps engineers. Some of them may even claim having up to ten years of experience. I find it quite amusing that nobody can define what it is; very few companies are actually doing it and doing it well, yet we are all experts at it.
Does this scenario sound familiar? A sprint team delivers another release on time and on budget. It boasts about how much its velocity has improved and how many story points it was able to cram into a two or four-week sprint. It shows its business partners a bunch of nice, pretty charts that illustrate how it is cranking out software and how agile the organization has become. The business partner is not impressed, however. Her competitors are crushing her by getting more rich features out each month. The competing products seem able to adapt on the fly and quickly address new requests from customers. The business partner asks the team to call out the major features delivered in the last release.
When people hear the word agile, they usually think of words like scrum, kanban, and velocity. Agile methodologies are geared toward churning out faster iterations of software, but the speed of software development does not always correlate to an organization being agile. What makes an organization agile is when the software that is being delivered is producing enough value to meet the business demand. In order to increase the value of our releases, we need to stop spending so much precious time racking and stacking infrastructure and managing application servers and databases, and spend more time adding valuable features for our business partners and customers. In other words, we need to embrace the cloud.
As a consultant, I have witnessed numerous organizations struggling with implementing agile. Agile fail patterns is a topic I have written about often (here, here, and here). Every now and then, I stumble across a company that is having great success with agile. One of the best success stories I have ever seen is from Valpak, out of St. Petersburg, Florida. Since they are right in my back yard, I was able to visit with them in person. Valpak’s transformation from a pure waterfall shop to an agile organization is a textbook example of how to drive change within an organization. Stephanie Stewart, Director of Agile Leadership at Valpak, shared with me her agile transformation story, which is summarized below.
Many companies use some flavor of an agile methodology today with mixed results. I have written about agile fail patterns in the past, but some companies do an excellent job of applying agile best practices yet still suffer from missed dates, botched deployments, and low quality. Why is that, you may ask? Because most agile methodologies only address the development side of the house and clearly ignore the operations side of the house. The two need to work in tandem to produce the desired results, which is the goal of DevOps.