The daily routine of the morning stand-up is so ingrained, I go through the above liturgy without conscious thought. For me, the stand-up provides a focused center for the team, our morning huddle. We look each other in the eyes, see how we’re feeling – we hear in each others’ voices strong commitment or uncertain hesitation. We lean on each other for support and promise ourselves that at the end of the day we will be one step closer to the goal.
Instead of escalating wars between departments by driving them to ever more ambitious, local goals, we need to break down the wall between development and operations. Defining overarching goals which resonate for both departments creates an environment where DevOps collaboration may thrive.
You’ve most probably been there: To win that one ueber-important client, your friendly sales rep sells the farm and his grandmother (well actually he sells features, which he invents right in front of the client to make sure to get the deal, but the effect is nearly the same). And not only does he sell „the grand new feature in the sky“, but he even guarantees a delivery date – and all without speaking a word to the tech guys. Sweet, huh? He is a hero. He made that huge deal and everyone is patting his shoulder. Well, besides you probably. And everyone else who now has to deliver a completely bloated feature in a totally unrealistic time frame. And, of course, there’s absolutely no room for negotiations. In fact, you’re not even allowed to talk to the client to ask a question about his requirements because the sales guy doesn’t want to make a „bad impression“.
How do you see agile affecting application development and delivery?
The biggest impact is that application development teams are using agile to speed up their delivery of software changes and updates. This makes the developers happy as they can get through requests faster. However, releasing that software out to the organisation is different: small teams are responsible for their own releases, while larger organisations have dedicated staff that handle getting software out to the business.
Whatever size you are, the increasing number of releases will have an impact on the overall process. One customer I spoke to recently has taken up agile, and gone from 50 releases per year up to 350. That is a huge increase. While the amount of code might be smaller, the change procedure will be the same, and that puts pressure on the overall application delivery process and the staff who release the software. This introduces the risk of there being undiscovered errors in the release. And that might mean production outages.