Tuesday, January 2, 2018

On the Bleeding Edge of Dysfunction


Note to reader: I apologize in advance for my pessimistic view. I am in dire need of a vacation.

"Agile and DevOps are better together in 2018"

This post, and these blogs crack me up. DevOps has been a part of agile for years. In order to have auto deployments, you need automated testing. Without automated testing you do not have agility. It is that simple. Oh you can apply some process framework of course:
“We’re doing Scrum."
"We're doing SAFe."
"We have small teams."
"We must be Agile.”
Wrong. 

What most people mean is that Scrum and DevOps are different. And they would be correct. But scrum does not equal agility. Scrum is simply a framework used to foster agility. Agility comes from strong technical practices, simple design, automated testing, working with the business every day, refactoring code mercilessly, continuously integrating, and continuously deploying the code to production. You can do scrum all day - or year - long but until you deploy the code, there is no agility. There is only code waiting to be deployed that may or may not serve the business needs once it has been released. 

Newsflash: This is NOT new stuff. This is stuff that a lot of us have been doing for over a decade. 

It never ceases to amaze me how slow to understand and adopt is the large enterprise. But once that buzzword becomes mainstream, everyone has to adopt it. Even if they have no clue how to do so, or what the terms they are slinging around actually mean. I have seen multiple large enterprises jump on the Continuous Delivery bandwagon and start building pipelines, all the while producing code that is tested manually. 

Sadly, they have no idea what is wrong with that picture. 

I have seen others adopt BDD as a way to automate "every test scenario" from the UI. That’s right. Let’s take the most brittle component of our software and write tests for all our functionality through it. Even if that functionality exists in another tier. Why? Because Selenium allows them to do so. Where will we get these test scenarios? From the three Amigos? From an excel spreadsheet authored by a separate test organization working in some far off location with almost no interaction with the development team. You know the same way they have done it for the last 30 years. But hey, they have people working around the clock on different continents. So you know it's more productive.

I have seen other organizations demand that everyone adopt Scrum and become a "product team". And they demand that they do so without changing the existing organization or the make up of any of their teams. Of course, these teams were built around technological silos. But hey, they "have a product mindset". Even if none of their teams are building anything that resembles an actual product. (Unless you think an ETL Transformation constitutes a product. And yes. Some of them actually do.)

They adopt all the Scrum Ceremonies but none of the agile principles. They continue to chunk up work in the same way and deliver it in silos. Then they can't understand why everything blows up during integration just like it did before they were "agile". Of course, they fail to realize that they haven't really changed a thing and are still using waterfall for delivery. Just smaller batches of it.

Now they are going to jump on the Agile DevOps bandwagon. Welcome to the party.

Unfortunately, they still don’t understand how agile software teams work and they still aren’t delivering potentially shippable increments of software.

Thanks to SAFe, they now have a way to coordinate all their releases together and commit to hard dates on fixed scope that is predetermined in a giant two-day planning session. A session where they "gain alignment" on all the dependencies between all their organizational and technical silos (never attempting to eliminate any of them) so that everyone can release together.

That sounds familiar for some reason. Can’t quite put my finger on where I have seen that before… 

Oh yeah. Every waterfall project I ever worked on. 
Well then. Nothing to worry about. 

They “are going agile” because they are “doing SAFe”.  Or Dark Scrum. Or building a continuous delivery pipeline that goes through the QA environment for weeks of system and integration testing before it can be deployed.

What could possibly go wrong?