"Do we try new, agile approaches, or stick to the old, methodical processes?"
May I take this to mean that there is no methodology behind agile at all?
There’s a debate going on right now about the best way to run IT: specifically, all those custom applications and services inside organizations. Do we try new, agile approaches, or stick to the old, methodical processes? Gartner did much to start this discussion with their bi-modal concept: Bimodal IT is the practice of …
I starting to think these El Reg agile articles are actually a guerilla campaign to bring agile into disrepute.
"Do you want your boring, old, planned development environment or would you like to spread fishpaste on every keyboard, set a bunch of cats loose in your office, and commit the result of that at 5pm because it's disruptive? Hell yeah!"
Well, all these articles are making me think that DevOps is the most annoying thing ever. Even the FishPasteCatsOps you've suggested looks more attractive.
Time for a new El Reg slogan? "Biting the hand that feeds IT. Until IT is DevOps, then we'll lick their fingers."
Maybe instead of bi- or tri- or quad-modal it makes more sense to think about a continuum. At one end, when a project or idea is new, speed and ease of experimentation are paramount. So move fast and sure, go ahead and break things from time to time when you're at that stage. But if the project succeeds, people start depending on it, and stability becomes more important. If you're doing it right, there's a natural progression rather than a fixed dichotomy.
This is true even for new, disruptive businesses. In the early days of, say, Uber or Twitter or Facebook, an occasional burst of unexpected downtime was probably quite acceptable if that was the cost of rolling out new functionality at a rapid pace. But now that those companies are successful and established, they're probably much less willing to risk unplanned downtime -- service disruptions now trigger immediate snarkery from world + dog + vulture. Or think about AWS -- an occasional glitch in some new experimental / beta service is to be expected, but we expect EC2 and S3 to remain stable and reliable all the time.
So you evolve -- you use agile when it's appropriate, and you use stricter change control when that's appropriate. Different processes and standards for different stages of the project's lifecycle -- a continuum as the risks and costs and opportunities change over time.
I agree that the happy/sad mode is not ideal and that it would be great to run everything in awesome mode, but then again, remember the push for "application modernization" some years ago? I don't have numbers to back this opinion, but I don't think it was very successful.
To me, bimodal IT is a consequence rather than a proposal. It is:
- Gartner saying "ok, we know that no matter how much we press you into modernizing your legacy apps you won't do it, so ... for new projects why don't you try this modern approach"?
- Accepting the fact that there are new kinds of IT buyers (ie CMOs) that need new kinds of projects ("why don't we build a gif creator platform to support the new advertising campaign?") that need to be built in a couple of weeks and will only be live for a couple of months.
- Recognition that it is too much to ask of CIOs to support business as usual at max stability+efficiency while at the same time developing new digital products/services. That is why we are seeing the rise of the corporate CTO. The CIO is responsible for business as usual (ERP, payroll, reporting, etc) and the CTO leads exploration/development of digital products/services. Both are important. One allows you to operate today, and the other allows you to be in business tomorrow.
I was working on a large-scale very high profile product for five years. Development was a mess, project management was non-existent, egos were rampant, nothing worked, teams weren't cooperating, the UI was terrible and we were being continually and publicly mocked for being impotent and talentless failures. Morale was rock-bottom, the project was in a death spiral, and none of us from junior to senior could see a way out. People left in droves.
Then we adopted DevOps, and in three weeks we'd turned everything around and got our new product - Windows 10 - pushed out and installed on millions of PCs. Now if that's not a DevOps success, I don't know what is.
JUST SOLVE THE FUCKING PROBLEM ALREADY.
I swear to God all this intellectual masturbation about development procedures is seriously getting on my nerves.
No later than this very afternoon I had a conversation with one of my customers. A shop with 2000+ employees and an IT sysadmin very much on top of his game. He told me that one of the procedures that we put in place to ensure proper transfer of data to the mainframe (yup, that still exists out there IRL) had been reported as not working.
Well guess what ? The mail-in where the info was supposed to be sent wasn't being used because some jackass middle-management wanted the info on the side to do whatever Godawful Access thingy and get some vested-interest statistics out of the data. The fact that Business Intelligence Central no longer had the data was a case of Not My Problem (for said manager, of course).
As a seasoned veteran with complete access to all data streams, what did he do to solve the problem ? Simple, really : he instructed the database receiving the data to send a copy to the one that should have been used. Bam! Problem solved. Data re-inserted back into the proper stream. Code change : minimal. Time used : 5 minutes. Procedure : who the fuck cares ?
People who spend their time spouting nonsense about procedures should be relegated to where they belong : university or retirement homes. Real Life is about solving problems, not deciding who should be named whatever the new name for Scrum Master is.
Now get off my lawn !
Have an upvote.
When I was a young programmer I developed a simple tool to organize some files in floppy disks.
The requirement procuration integrator A coworker had some dozen of files for an application that needed to be divided into floppy disks by category/extensions, I have no idea why. Our hyperdedicated team of analysts, engineers and developers I wroted something simple in Turbo Pascal (yes!) that copied the files in the desired order. The technology integration evaluator user was quite happy with that.
Later that year the head of our department decided that we need a Systems Analyst/Software Engineer to "guide us" on the development, and he decided that the first logical step was to evaluate what we did in the past to tell us what we did wrong. In a first meeting he asked me to show every piece of paper produced in the meetings with the stakeholders for that small piece of software. I had to "respectfully" explain that the users' problem was solved, and I wouldn't work to justify hiring that
douchebag moron specialist with pointless paperwork.
After one year, one of us was fired. Surprisingly, it wasn't me.
There is a guy called Simon Wardley that talks about pioneers, settlers and town planners when describing this phenomenon and it helps me because it puts it in human terms that my fragile cortex can deal with.
When the west of the US was first colonized by immigrants it was typically the pioneers - the adventurers that wanted to break new ground and discover untold riches. Another group followed them, the settlers. Life wasn't easy for the settlers but they were effectively able to take advantage of the pioneers effort to discover new produce and then sell it back to the east. The settlers had sheriffs, and hostels, banks and bars but it was still a pretty tough and violent existence. Ultimately the town planners followed the settlers and began to develop the towns and cities that both took advantage of the new resources at industrialised scale and developed all the support structures that a growing population needed - schools, hospitals sewers and the like.
It is a pretty easy comparison to say Pioneers= innovators, settlers=early adopters and town planners = ITSM and ITIL folk. As PDH says above its a continuum - the trickle needs less management than the flood that follows.