DevOps is in many ways the popular little sister of Agile. She is not a completely new, rebellious generation, like Agile was to his mother Waterfall, but she looks up to her older brother and has a some opinions of her own.
Coming from the same family, DevOps and Agile have similar values and principles. The highest priority of Agile is to satisfy the customer through early and continuous delivery of valuable software. To create valuable software, Agile insists that business people, customers and developers collaborate and work together. DevOps agree, but her main concern is that Agile does not emphasize collaboration throughout the software life cycle as a whole, all the way to production support. She wants to collaborate with IT operations as well.
The highest priority of Agile is to satisfy the customer through early and continuous delivery of valuable software […]. DevOps agree […].
Agile has already lived long enough to see the consequences of his preachings. Agile principles were picked up by well-intentioned people (and inevitably people with economical motivations as well), turning them into methods and rituals that everyone wanted to join in on. But somewhere along the road paved with good intentions, Agile practitioners took a wrong turn, and the frustration towards Agile started growing.
In the history of Agile, we have seen some unfortunate unintended consequences:
- Projects not producing a single line of documentation because working software is valued more (this has also been said to be the reason for the decline of UML)
- Projects being rewarded only for delivering value to the end-user on time – not the quality of the product
- Customers not specifying any requirements up-front because “You are supposed to welcome changing requirements late in development” or “Isn’t ‘agile’ the just another word for ‘flexible’?”
- Product owners not representative of the end-users prioritizing features and giving feedback on the product alone
- Scrum teams having worthless daily standups and other Agile rituals that no one really sees the point in
- Cross-functional Scrum teams where developers are forced to pair-program and rotate all the tasks, turning specialists into miserable, average performers
Ironically, Agile processes and tools became the main focus for many of its followers, even though the first value of Agile is individuals and interactions over processes and tools. Many practitioners also seem to skip the basic understanding of the values and principles, and applied them with no pragmatic sense at all.
Ironically, Agile processes and tools became the main focus for many of its followers, even though the first value of Agile is individuals and interactions over processes and tools.
Agile received many hate mails because of this. Is DevOps in store for the same kind of misuse and harassments?
A common interpretation of DevOps is that the people implementing the software should be the same people running it. This way, developers are accountable for what happens after release as well. This will lead to better quality, as the developers have an interest in making the system less error-prone and easy to maintain. In a context with virtualization, cloud computing, automated tests and quick and easy deployment, this implementation of DevOps can be a great success.
However, if your organization is a large, complex bureaucracy with old infrastructure and legacy systems where the different IT operations require deep, specialized knowledge, firing the entire IT operation department and having the developers take over might not be a great idea. In this case, instead of spreading the knowledge thin across the different domains of expertise, collaboration between experts might be a better approach to DevOps.
DevOps, like Agile, has some potential pitfalls, like turning specialists into mediocre performers. But even if DevOps is about to make the same mistake as Agile, we cannot blame a concept for our failures. We as practitioners need make sure that everyone involved in the process grasp the values and principles behind what we are doing, and remain pragmatic about it. Us humans apparently need to remind ourselves constantly why we are doing what we are doing not to get too carried away.
We as practitioners need make sure that everyone involved in the process grasp the values and principles behind what we are doing, and remain pragmatic about it.
DevOps does not have to make the same mistake as Agile, as long as we as a community take responsibility for our mistakes with Agile and learn from them.
Great post! Looking forward to the continuation 🙂
LikeLike
Thank you, Mario! ^_^
LikeLike
It’s interesting how you often pick up your dislike for pair programming. Personally, I’ve been on teams that weren’t able to do good pair programming (and that abandoned it) and on teams where pair programming worked and the team had a massive learning curve, gained and shared expertice and had fun.
Do you have any theories on how your experiences have been so radically different. I’ve heard you express your *opinion*, but I haven’t heard you *experience*?
LikeLike
Thank you for your comment, Johannes.
I am in no way against pair programming and I applaud it when it’s working. I was refering to *forced* pair programming.
My own experience is in no doubt good. As a newly graduate I got to learn from patient and experienced developers. However, I have seen the dread and dislike in some of the other team members who hated it. It can be an intimate and intruding practice for some, the tasks are not suitable, and they are not able to concentrate and benefit from it. When someone outside the team force everyone in the team to pair program every day, they create resistance.
My point is I don’t think we should glorify any agile practice or make it mandatory. It should be up to the team to decide how to do the work.
LikeLike