July 9, 2019

Agile and DevOps - its the belief and culture, NOT the ceremonies

In my previous post on Making Software Architecture Matter, I ended on this note on agile and DevOps:

I quite like these ways of workings, and these definitions. They are so much more....human, and cater for different scenarios, rather than the text-book "though shall deliver 100% up-time" when we know its not practical, cost-efficient, or even required. And this goes for agile methodologies and the DevOps movement - making things so much more human and understandable, and saying up-front that its for each team to determine their own way of work, with no one-size-fits-all card.

First up, the disclaimer: there are many definitions of whats agile is or isn't, or scrum vs kanban, with a Capital or small A, and is DevOps one team or many teams working together. All of that is not the point. What is the point is the Agile Manifesto, everything else is just lipstick. Notice how simple that site is: no fancy stuff, just core beliefs. No mention of Scrum (although Scrum pre-dates the manifesto, but thats the whole point - you can be agile, with-out Scrum) or kanban, burndown, standups, (I'm getting dizzy) or certifications. It's a core belief system. It's what separates the leaders from the MeToos, it's what make people tick. Everything else is just implementation details.

From Data Driven we read:

It’s a misconception that standup meetings and other ideas from the agile movement work only for high-tech Silicon Valley firms. Standup meetings are used to monitor situations in the US Department of Defense. The National Weather Service has a daily meeting where the weather forecasters gather (both in person and virtually) to raise any issues. The key to success in all of these forums is to be ruthlessly efficient during the meeting and to make sure issues raised (action items) are acted upon.

Notice how the agile manifesto, or DevOps, did'nt come from a consultancy, vendors, industry watchdogs, or standards organisations, all just trying to sell you last years rubbish in a new wrapping. And no mention of JIRA either! Rather, it came from guys in the trenches, the implementors, who figured it out, the hard way, and then gave us the learnings. Humans, like us, trying to make stuff better, run faster, and get away from the red tape of bureaucracy.

We read from Accelerate: The Science of Lean Software and DevOps:

Arguably the DevOps movement is poorly named, because it ignores functions such as testing, security and product management. The original intent was to bring together developers and operations teams to create win-win solutions, rather than throwing work over the wall and pointing fingers when things go wrong.

But don't let the name hold you back: it's all about having a fully self sufficient team, with all stakeholders,  that is end to end responsible for everything.

And thats the key part: making it human, and practical. Agile and DevOps embrace human limitations, and provide a workable solution to still deliver better and faster.

  • They embrace that humans cant track a multi-year program and still follow a plan that is out-dated, so it breaks it up into smaller chunks.
  • It acknowledges that we better off talking to each other, rather that using documentation as a method of communication.
  • It admits that separate silos of Devs and Ops, set against each other by allocating each other competing KPIs, will be better off if we just worked closer together.

And Culture trumps technology as well.

Too often, in enterprises we hear some of these gems, which gives agile a bad rep, and comparisons to street food:

  • "You use Trello, so you must be agile!"
  • "You dont use JIRA...so how can you be agile?"
  • "I'm responsible for Agile/DevOps in this organisation". Was anybody responsible for waterfall before that? Like I always giggle at the Dilbert about the strategy that says "we strive to be agile and nimble" , but no other strategy before said "we strive to be clumsy and slow".
  • Or the extension to the above: I'm responsible for Agile/DevOps"....but they don't have a single developer or Operations/Support person at all, even by implication or dotted-line.

To understand what they are, start doing it, then get these DevOps must-reads:

And no, dont first try to scale agile!