Here’s the recording of the webinar:
Q: What’s your favorite tip to improve collaboration when an organization moves to agile and DevOps?
A: I think the core DevOps thing with collaboration is getting people to trust each other. Most corporate cultures are not built on people trusting each other and feeling comfortable: they’re based in competitive, zero sum structures or command and control management at best.
Organizations that are looking to DevOps for help are likely trying to innovate new software and services and so they have to shift to a mode of operating that encourages collaboration and creativity. Realizing that is a critical step: we want to create and run new software, so we need to understand and become a software producing organization.
In contrast, if you operate differently if you’re just driving down costs each quarter and not creating much with IT. We’d counter-argue that if you’re a large organization and you’re not worrying about software then you’ll be creamed by your competition who is becoming a software organization.
If forced to pick one tip to increase collaboration I would say: do it by starting to work. How you do this is to pick a series of small projects and slowly expand the size of the projects. These projects should be low profile, but have direct customer/revenue impact so that they’re real. It’s important for these projects to be actual applications that people use, not just infrastructure and back-end stuff. It will help the team understand the new way of operating and at the same time help build up momentum and success for company wide transformation later down the road.
As a basic tactic, Andrew Shafer has a fun, effective tactic about having each people on the team wrote fantasy press releases about each other to start to build trust.
I’m at Gartner AADI this year, the first time I’ve been to a Gartner conference. One of the sessions was a read-out of a recent survey about Agile. While a small sample set – “167 IT leaders in 33 countries” – it was screened for people who were familiar with or doing agile of some kind. As with all types of surveys like this, it’s interesting to look at the results both with respect to “what people are doing” and how they’re thinking about what they’re doing. Here’s some slides I took pictures of during the talk:
My first take-aways are:
- Well, Scrum is popular.
- Most of the “stumbling blocks” are, of course, meatware problems: people and “culture.”
- Pair programming, as always, gets no respect.
- Organizations want to use agile for speed, not for cutting costs.
“Managing the incompleteness of communications” is core to mastering agile software development.
I recall reading the first edition of this book years ago. Man, that was fun.
Here’s the slides for the talk I gave this morning on lessons learned from working on a DevOps product in a large company, that is, Crowbar in Dell.
Sometimes it seems like It’s near impossible to get anything innovative, interesting done in a large company – it’s as if BigCos are goaled to prevent just that. While you can’t type a URL without hearing how a Ramen-fueled startup got ground breaking product out the door, you rarely hear about how the other side of the exit lives in Large Company Land. This talk will use the story of Crowbar at Dell to grope out how to get good things done in big technology companies, esp. when it comes to something as BigCo esoteric as DevOps!
I’m amazed when I find a skunk-worked project that’s blossomed into a valuable, strategic asset for a company. In the case of Dell and Crowbar, it’s even more astonishing: Dell has traditionally been a stone-cold hardware company focused on shipping more boxes each quarter, Crowbar is an open source piece of software whose business model depends on the nuanced dynamics of open platforms strategy. You’d never think these two things would go together. And yet, Crowbar exists and has had amazing success (both externally and internally) in an extremely short time. With the access I have to the “real story,” being at Dell now after six years at RedMonk covering tech from the outside, I’ll go over lessons learned on getting DevOps and a DevOps product through the Brazil-like pneumatic tubes of a $62.1B company.
In this episode we talk about a whole passel of things, most interesting of which are:
- Game On! Leagues /// November Madness Halo 3 Tournament – $600 in prizes – Charles’ site is running a tournament where you could win, bra’!
- Coté’s week with Leopard
- Peeing on floors to get out of leases in the Fringeware age
- Coté’s new EVDO card
- The “unfun” job of marketing software
Finally, go check out DFoF!
(This episode edited by Coté.)
Thanks to the valiant efforts of Mr. Steve O’Grady, the RedMonk blogs will be up-ish tomorrow. I say “up-ish” because, as most you know, dear readers, switching domain names around on the internet is not a speedy science. Indeed, I’m often taken aback at how controlled and yet how chaotic the ‘net seems.
Then again, I’d be willing to be that there are teams of jack-booted thugs with hex screw-drivers and Cisco certifications ready to keep the network up. I mean, how terrible would that be if it went down?
Other Meanings for “High Availability”
I used to work at a company. Let’s call it WXYZ, Inc. One of the class clowns there made this joke one day:
High Availability? Baby, if you wanna get high…WXYZ is available!
Remarks like this were often followed by, “Waitress! Another Dewar’s!”
The Wealth of Networks
I started reading The Wealth of Networks last night. It’s nice, dense yet concise, academic talk about how content-producers controlling the means of production and distribution changes things. Information Marxism? Sure, sign me up as long as I can have a swanky Paris flat to go with it.
I’ve read a scant 20-30 pages, and there’s already a great conclusion: the physical distribution constraints of the “industrial information age” (pre-net) were the requirements driver of all that nasty, hegemony friendly IP law we created and now have.
Now, of course:
The removal of the physical constraints on effective information production has made human creativity and the economics of information itself the core structuring facts in the new networked information economy.
At least, that’s my understanding of those pages.
PC Means “Personal Computer”
As I read it, I keep thinking about the other 4-5 billion people who aren’t on the network. I had the pleasure of hanging out with Mr. Koranteng Ofosu-Amaah last week while he was in town. We had some Ruby’s BBQ and then some coffee (well, he had tea) at Spider House.
Somehow we got to talking about the $1
0040 laptop. He had two interesting things to say (side-note: a longer post on the hangin’ out is much over-due):
- The notion of a 1:1 mapping between a computer and user may not be universal.
- Hey, how ’bout them cellphones?
Which was interesting, because we talked with Nokia this morning. Now there’s a mega-platform for you: cellphones. The strange thing about The Wealth of Networks thinking (my 20-30 pages understanding of it) is that the people who run and own the networks seem a few successful startups away from being PanAm and TWA to the analogous Southwests. I mean: telcos! Come on!
In America, we always wave off madness in the telco world — Korea is light years ahead of us, I hear, and they have some sort of crazy cool network in Europe — as regulation and FUD. Really, it’s probably just 50-100 well paid people who’re waiting to retire until they screw with the golden goose.
And there we have one of my new pet-theories. (Inquire within for more pet-theories.) Technological change is generational. You have to wait for one generation to hand over the reins before real change can happen. Excited about Agile Software Development? Keep your eye on the retire date of all those managers and “decision makers.” Want better cellphone networks in America? Wait for “insiders” to retire.
Of course, firing people works too, but it feels so nasty. And really, wouldn’t you just be sticking it to yourself in that case?
Luby’s Upgraded to STRONG BUY <eom>
The problem for us youngin’s is that retirement is soon to retire itself as a concept. Aside from all the fretting about not being able to live out The Golden Years in an RV or finally getting to writing That Novel, the generations in the tech world need to make a pact. A sort of realpolitik:
OK, we’re all going to keep our minds flexible and updated, right? I mean, if you’re going to stay in the work force forever, you’ll voraciously take on new ideas throughout your term, not just in the first 10 years. Maybe in exchange we’ll slow down a bit and focus on creating technology that allows you to work just 40 hours a week instead of 60. And we won’t say “no” next time you suggest Luby’s…. Okey-okey, and we’ll be less — just a little — snarky if you’re letting us play in your lawn.
Of course, we should probably be lining up to thank the generation ahead of us for working to pay the bills instead of bankrupting society. So, let me be the first: Thanks! …but now can we get on with some badly needed changes in core thinking?
Disclaimer: I actually like Luby’s. One word: okra. Bonus words: tarter sauce, deviled eggs.
- You can rarely pick the people on your team, or pick those that your team must work with and depend on. “If we had all the right people, of course all the right things would happen.”
- Putting people in one big room is a defensive move against the above. Open source software is developed by geographically dispersed groups (the word “team” is even too strong to use). Sales is driven by geographically dispersed, ad hoc teams.
- Theory: we haven’t figured out how to do software in business, on a large scale. It may be done, but it’s not normal, or thought of as “good” (by programmers at least).
- Theory: worse, we haven’t come up with re-usable ways to solve the people problems associated with not being face to face. We expect our geographically developers to work as well as open source developers, but it hasn’t worked out yet on a large scale.
- Given all that, your best bet is one big room.
- Is it true that technical skill is disappearing in the US? MSFT and others are always saying “we have to hire globally because those in North America who’re smart enough aren’t plentiful enough.” Is business skill is suffering the same thing? What skills do we have in North America?
Waterfall is plan driven — fixed requirements, estimated time and resources.
Agile is value driven — fixed time and resources, prioritized features.
“Would you rather have 100% of your features 80% complete or 80% of your features 100% complete?”