Introduction
If you’ve kept up with recent trends in IT, you’re probably well aware of two different but related concepts that have been influencing the state of the industry: the “agile” movement and the DevOps model. Together, these form the foundation for “next generation IT” – but because they involve a totally new way of thinking and working, even many of those who embrace the ideas and ideals that they represent aren’t completely sure of how this brave new world will work in the long run.
Perhaps the distinguishing characteristic of the agile/DevOps movement is that, unlike most past technology trends, it is thought of as a “movement.” It’s not just a new set of practices; it’s an entire cultural shift. After all, the agile movement began with The Agile Manifesto, so that should be a clue that we’re talking about a pretty radical approach that advocates the adoption of a completely different philosophy from the traditional IT mindset.
Change of this magnitude doesn’t come easily to many – and that’s especially true when it’s presented almost as an article of faith or a mandate from on high, without any honest explanation of the real benefits and drawbacks (as it has been presented to many IT professionals). That’s the reason that open discussion regarding a planned transition to an agile/DevOps system, before the fact, is so important to the acceptance and ultimate success (or failure) of the effort.
Let’s look at some of the defining characteristics of these methodologies, where companies go wrong in implementing them, and how to enjoy the benefits while avoiding the pitfalls.
Agile for all?
The agile movement began as a new way of thinking about software development. It came about in response to the limitations that were inherent in the more traditional process, which is often referred to as the “waterfall” methodology. It’s called that because it’s based on a group of fixed sequential steps that flow downward like the water in a waterfall, through a set of phases:
- Conception
- Initiation
- Analysis
- Design
- Construction
- Testing
- Implementation
- Maintenance
As you can see, this constitutes a rather rigid structure, as is highly appropriate in the manufacturing industry where it originated. Construction of complex machines, edifices, or other physical items requires clearly defined steps and stages, and it’s important to get it right the first time because major changes after the fact can be costly and difficult – sometimes almost impossible. Tearing apart a skyscraper to make modifications to the design would be prohibitively expensive, and making a major change to a mass-produced item such as an automobile would be even less feasible. A company that did this often wouldn’t be able to stay in business.
The software industry sprang up in the middle of an era when the economy was based on manufacturing and real estate development. It’s not surprising, then, that its leaders looked around for a successful model on which they could build guidelines and practices, and ended up with a variant of the waterfall. There were some minor differences: conception and initiation phases were encompassed in a system and software requirements document, construction consists of the coding phase, and implementation – which envelopes installation, migration, and support – are rolled into one package and labeled “operations.”
It worked, but it didn’t always work well. One of the biggest problems is that with such rigidly defined steps and timelines, there is no testing of the design and code until after the design and coding phases of the project are long past. Then you have little or no time to make major changes if they’re needed.
The intent of the agile movement was to provide for more fluidity so that all of the “steps” are on-going continuously instead of isolated into a sequential process. While obviously you must analyze in order to plan a good design and you must design before you can start writing the code, you can begin testing earlier, before all of the code is written, and go back to reassess (re-analyze) and modify or even completely overhaul the design without the high cost of demolishing a fully completed project and starting over. You get feedback throughout the process instead of just at the end and you have increased visibility into what works and what doesn’t. Quality improves, cost goes down, deliverables get finished faster, and customers are happier.
At least that’s the way it’s supposed to work – but more on that later.
Where does DevOps fit into this?
DevOps follows the same philosophy of consolidation and fluidity as agile, taking the idea a step further and applying it to job roles as well as to work processes. As the name suggests, it’s about combining the development and operations roles into a more cohesive team structure that encourages more communication (and in some cases, cross-training) between software programmers and IT pros such as network admins, security specialists, network engineers, network architects and product specialists.
Instead of looking at software-related tasks as fitting into two distinct silos, with designing, coding, building, testing and packaging in one and installing, configuring, maintaining, monitoring and troubleshooting in another (which sometimes also includes securing and sometimes it’s relegated to yet another bucket), DevOps is about putting all of these activities together as one continuous process.
Benefits of an agile DevOps team
The new model offers some obvious improvements over the old “waterfall” and siloed approach. Most major technology companies have adopted it to one degree or another. It’s evident in such corporate decisions as Microsoft’s announced intent to make Windows 10 the last clearly defined “version” of their operating system, with new features and functionalities (and in some cases, the deprecation of old ones) to be accomplished through small, incremental updates rather than big OS releases that draw a clear line between one version and the next.
You can also see the DevOps influence in action with Microsoft’s push to use PowerShell and PowerShell scripts – requiring more of a programming mindset and skillset of IT pros, in contrast to the more traditional GUI management tools. Speaking of scripts, another characteristic of the DevOps model is more of a focus on automating processes, both the software creation and delivery process and the software management process – something that also ties in with the automation-centric nature of cloud computing.
Better communication and more collaboration between the people who create the software and the people who are expected to work with it every day should result in better usability and less frustration on both ends. The ongoing feedback, frequent reevaluation and continuous cycle of updates should ensure a constantly improving product. This more fluid process also provides more opportunities to make major changes that will increase the security of the software, as well.
What could possibly go wrong?
When good agility goes bad
The theory behind the Agile/DevOps methodology makes sense, but as with all ideas, how it works out in real life is all about the implementation. Also like almost every good idea, there will be some companies and individuals who twist the intent so that what’s put into practice barely resembles the original aims.
Automation, for example, can easily be taken too far. Some organizations go overboard in their attempts to streamline processes and eliminate human error to the extent that they remove the crucial creative and critical thinking elements that make a product or service great, rather than just good.
Another risk of going full-tilt down the agile path is trying to force communication and collaboration by throwing everybody in an “open” office floorplan and expecting them to magically coalesce into a functional team. As with over-automation, this ignores the human factor, which dictates that some people will work well in such an environment and others will be driven to distraction by it and unable to do their jobs well. Taken to the extreme, employees who were happy and productive working from home or in private offices are turned into stressed out, ineffective, miserable workers who spend the day dreaming of escaping the sensory overload into which they’ve been placed.
A basic tenet of the Agile Manifesto is “less documentation.” The elaboration is that this refers to hundreds of pages of dry, boring, incomprehensible technical jargon that never gets read. However, some businesses take it at face value, eschew writing anything down, and end up losing valuable knowledge if a key player leaves.
This is the ultimate irony: agility turns into rigidity. As another example, one of the twelve principles of the Agile Manifesto is “Face-to-face conversation is the best form of communication.” Embracing this as a hard and fast rule ignores the fact that for some people, it’s not. There are those who can get their points across clearly and quickly in writing, but are unable to express those same thoughts in an in-person encounter.
Even continuous change can become a rigid requirement when changes are not just welcome, but are mandated. Then you can fall into the “change for the sake of change” trap, something that frustrates and alienates the end users as they’re required to keep adapting to modifications in the way their software or service works, and developing familiarity and proficiency becomes a moving target that’s always just out of their grasp.
Make “Agile” more agile
None of the above is meant to imply that the agile movement is a bad thing or that we should go back to the old waterfall methodology in IT. By and large, the concepts are valid; it’s the implementation that needs work. The original meaning of “agility” is the ability to move quickly and in a well-coordinated manner. “Quickly” doesn’t mean without planning and forethought, and “well-coordinated” means adapting the rules – or even changing them (after all, receptiveness to change is what it’s all about) to ensure that all members of the team are able to work in the way that allows them to contribute their highest quality work in the shortest time that can be accomplished.
Simply put, for some of the companies that are experiencing problems as they attempt to adopt the agile principles, the solution is to do it in a more agile way.
