Double Half and Quarter

Question

Double Half and Quarter

Steve Jones - SSC Editor

SSC Guru

Points: 736255
More actions
June 8, 2020 at 12:00 am

#3759572

Comments posted to this topic are about the item Double Half and Quarter

Viewing 8 posts - 1 through 7 (of 7 total)

You must be logged in to reply to this topic. Login to reply

David.Poole SSC Guru Points: 76001 More actions · Answer 1

If you halve the number of incidents then you have more than halved the negative impact of those incidents.

When an incident is discovered it has to be logged, diagnosed, prioritised all before the it is assigned to a person or team to solve and fix. Maybe the team need to drag someone else in to help.

Then there's the prevarication around risk and impact on timelines on work in flight. Perhaps the incident will be downgraded to an accepted risk or a fix promised in the (mythical) phase 2.

Even when incident resolution works smoothly it can be a massive time sink. I've found throughout my career and throughout my life that quality always pays for itself.

LinkedIn Profile

Rod at work SSC-Dedicated Points: 34008 More actions · Answer 2

Donovan Brown, of Microsoft, famously said, "DevOps is the union of people, process, and products to enable continuous delivery of value to our end users." I've been witnessing just how true this whole of that statement is.

The large state agency I work go, which has been around longer than anyone who currently works there, has been dedicated to Capability Maturity Model Integration and Waterfall, for many decades. Two to three years ago a new project manager (PM) came in who championed DevOps. For a while there, I thought things would actually change. Teams at work were adopting DevOps. It really had hope of being implemented.

Then the bottom dropped out. That PM left to work for another state agency. I tried to keep the DevOps momentum going, but failed. I think there were other developers who were interested in DevOps, but perhaps I was wrong. I believe I didn't succeed because I'm a developer; so basically my trying to champion DevOps was seen as my not staying in my own lane. What really convinced me that people and process plan a much better role in DevOps than I'd ever thought was possible, was a team meeting last Friday. My boss expressed great disdain for a project that failed miserably. His comment was that this failed project was just an example of how DevOps was useless. Heck, I don't even know if it was executed using DevOps methodology; it was just labeled as an example of how poor DevOps is at getting anything done, end of story. And all of my colleagues agreed with the boss. (I didn't work on the project.) The project was very high profile, it has backing from the Governor's Office. But it had what I think were impossible criteria. A new website had to be written from scratch, providing data to the public, including a new database. And all of it had to be done in 72 hours. It took 3 weeks.

That PM has returned to the state agency I work for. I think she's in for a huge surprise, as a lot of management now see this project as an example of how poorly DevOps solves any software project.

Kindest Regards, Rod Connect with me on LinkedIn.

Steve Jones - SSC Editor SSC Guru Points: 736255 More actions · Answer 3

I've seen this throughout my career. Agile doesn't work. Scrum isn't helping. Lean can't solve our issue, etc.

Rather than debate what went wrong, someone talks about the problem with the methodology. If you don't seek to learn how to use something and why it causes you issues, nothing will work. If y0u do learn from your efforts, anything will work.

Jeff Moden SSC Guru Points: 1004356 More actions · Answer 4

We have something that works great! We don't do continuous deployments to prod! 😀

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)

Rod at work SSC-Dedicated Points: 34008 More actions · Answer 5

Steve Jones - SSC Editor wrote:

I've seen this throughout my career. Agile doesn't work. Scrum isn't helping. Lean can't solve our issue, etc.
Rather than debate what went wrong, someone talks about the problem with the methodology. If you don't seek to learn how to use something and why it causes you issues, nothing will work. If y0u do learn from your efforts, anything will work.

I totally agree with you. This experience has shown me that I'd made a fundamental mistake myself, in thinking primarily of the tools involved as being "DevOps". I'd forgotten about people (i.e.: culture) and process as being equal parts to producing the products.

Kindest Regards, Rod Connect with me on LinkedIn.

Steve Jones - SSC Editor SSC Guru Points: 736255 More actions · Answer 6

I'd argue people are the most important part, with process second. The tools/platform/automation/tech bits is the easiest part by far.

Unfortunately, too many people stop with tools/etc. and don't work on process and people.

Rod at work SSC-Dedicated Points: 34008 More actions · Answer 7

Yep and I'm one of those who unwittingly put too much faith (is that the right word?) in just the tools. ("Look how cool it is that I can assign the work item to the check in, within Visual Studio!") I fell victim to thinking that was enough "to do DevOps". It was a mistake of my own making. I know better now. If people aren't on board with DevOps, or at least willing to give it a good try, in the end I'm just wasting their and my time.

Kindest Regards, Rod Connect with me on LinkedIn.