Our IT Process Wars
proc·ess, pro·cess/ˈpräˌses/, /prəˈses/
| Noun: |
|
(This is a four-part blog addressing Process and Tools within Software Culture. This third part discusses our misuse of process. Part 2 can be found here. Part 4 can be found here.)
We might be on the verge of an important evolution in Software Culture or another well-intended IT industry failure – depending upon how it's handled. Those who seem to have been able to run with this new philosophy are reaping the rewards, but unfortunately the rest seem lost. 
Kansas City yet again, is a late adopter.
Agile is the main Software Development approach in the world, and we're trailing.
Why is that?
For those who are stuck, it seems that our implementations and rollouts are followed by years of hand-wringing about the adoption failures. We have IT tearing ahead again as change agents, unearthing a maelstrom of business level problems.
Mostly cultural.
The problem is that we're successfully rebranding Agile as a process – an ideology – in order to gain adoption.
It's worked in the past. We parcel a concept as codified process so we can resell, evangelize, debate, certify, create support groups… position ourselves as subject matter experts… generate "healthy competition", and generally feel good about being the early-adopters of new toys.
What's wrong with calling Agile a Process?
Do you know the difference between a Philosophy and an Ideology?
This is an extremely important question, and I'm not asking this to engage in more IT intellectual debates or esoteric hair-splitting. It's at the very heart of why those who are "lost" are also stuck.
Agile is a philosophy: As such, it is a set of guidelines and thinking principles to understand the state of software development.
It is NOT a series of steps.
And this is a huge problem for many companies in Kansas City who are used to operating in checklist, process driven factory mode. Agile is a new way of doing business – not just "a new IT thing" or new set of steps, but a completely unrehearsed shift in business principles that allow for behavioral improvements. It is a highly collaborative approach to software creation and ownership.
Lest we forget?
I think we've forgotten that it was heavy process that caused us the pain that led us to the Agile Manifesto. And do you know why certain IT shops still prefer it that way?
…because they believe that Process has the power to mitigate or even eliminate the waste associated with human involvement.
In Waterfall, we were concerned with fail-proof plans – hoping to prevent errors in production. We were applying cost-accounting to our field and only measuring waste defined as errors. And IT departments were measured in total as a cost-center. We were incented to finely tune the process in hopes of making it idiot-proof. And that's the hallmark of a process – the degree to which we succeed in making human involvement idiot proof…
Process is an imposed limit on human ability – It caters to the lowest common denominator – not the highest.
There is no process that can force people to innovate, collaborate, adapt and openly contribute to the greater cause of a business. That takes a philosophy – a set of principles and values. In fact I'd argue that process actively crushes all sense of creativity and collaboration out of software development.
You can force someone to use a process or a tool, but you can't force someone to have skills they don't have. Processes and tools can be taught. The skills like the ones listed above cannot. This is why Agile is an important evolutionary change – that's why much of the push-back of "that won't work here" is heard in Kansas City.
The wrong model for Software Development
The Agile manifesto realized that while old-world process was a good model for production line factories it was a failing model for the knowledge work in Software Culture. We were being asked to innovate for our business and we had reached the upper limit of what process and tools could afford us. Process was getting in the way of better Software Culture, and in many cases hampered innovation by producing more waste over value.
It's important to note that the first line of that Manifesto addresses the issue directly by admitting that we should be valuing Individuals and Interactions over Processes and Tools. Classifying Agile as another process creates an apparent self-referencing contradiction or even paradox. Perhaps its just a safety valve to stop people calling Agile a process.
If business is looking to get the best out of it's people, PROCESS IS NOT what will lead you to a high-performing culture. This is why the Agile Software Culture shift is so important – and this is also why we're stuck.
But many IT people, and users alike, are not comfortable outside the security of a process based mindset.
"But we must have steps to follow…"
Must we? Looking left, then right, then left again before crossing the road, is not a guarantee that you won't be run over by a car. At some point, you graduate to the concept of paying attention to your environment – or most of us do. Perhaps it's Darwin in action. The individual who needs the "just tell me what to do" work approach, might be completely lost in this setting. So too the manager who needs the ability to tell her subordinates what they should do.
Agile mostly forces us to look at the goals – not the minutia. Sadly, that's where IT is derailing itself (again) in debating minutia. Debating steps. Debating which interpretation of Agile is the best… more religious wars over missing the point.
My Agile-fu is better than your Agile-fu.
There's ample evidence that many of our subject matter experts are stoking the religious debates over institutions. The danger is that they are leading people astray with their zealots addiction to processes and tools and missing the history lesson.
Recently, some were called out here. If you're yelling Agile, from an IT perspective only – you'll sound like a tech bigot – and for good reason. Agile lesson #1 – It's not just about you…
There are a couple of ways to spot the IT Ideology bigot:
- They have institutional names; names that must be fiercely evangelized against other institutions. ALL equally making claim to the Agile crown
- They are born from a common philosophy (Agile) that they can call upon for credibility or hide behind for validation
- They devolve into petty debates over institutionalized best-practices
- They present one-size-fits-all solutions to software company cultures they know nothing about
- They look, smell and act like old-school processes
Ideologues and zealots value HOW something gets achieved, and get hung up on debating that issue. They quickly dispense with WHY a company is going Agile. When you lose sight of WHY you're doing something, it becomes a dogma – it becomes a process. It's nothing more than ritualized behavior.
A process has no ability to describe WHY we want to develop software in new ways.
Rollouts, Implementations, Best-practices and Institutions
Let's line item the 4 statements of the Agile Manifesto – Note the items on the right are process…
Valuing Individuals & Interactions over Processes and Tools:
Working Software over comprehensive documentation
Valuing Collaboration over contract negotiation
Responding to change over following a plan
The items on the left, however, Communication skills, Creative skills, Soft skills, Team skills, Interpersonal skills, Adaptability skills… are not. Sound like any process you know? Didn't think so. So why are we calling it that?
We're calling it a process because many C-level execs don't recognize it. It's new. They recognize process – things that can be rolled-out, implemented… pushed into practice… institutionalized. All phrases I hear managers and execs using to describe what is really a culture and skills change.
Training has been replaced by mutual learning. Support is now replaced by collaboration. Answers are now being asked of business rather than IT charging ahead as change agents.
…and the responsibility of Software ownership is everyones.
This time, there are no steps – there is no codified process to follow – no process safety net for the human condition – because we're wanting to encourage it. To call Agile a process is to call it another codified dogma. And while that might assuage those who believe we should "give 'em something they recognize" or "that won't work here…" it's only going to add to the pain of change when they are outpaced by their competition.
Spot on! We do seem to be behind the curve here in KC, compared to the coasts in regard to Agile adoption and real cultural transformations. Someone told me recently that the only people who like to be changed are babies with wet diapers. I think there is real opportunity here but the management and executive level folks have to get it first. Then they must support and trust their teams to self organize. A big part of it is about trust. At the end of the day, competition and gravitational pull will weed out the companies that don’t deliver value and adapt to change quickly.
Mike – I’ve heard the same quote describing older developers… The real “change” has to occur at the leadership level. Management is not the same as leadership. Management here in KC believes that Agile is an “IT thing” which doesn’t affect them. It appears that they simply want some magical benefits of higher velocity from teams without changes from their end. I believe you’re correct in that the late-adopters (laggards if you will) will be addressed by the marketplace. Command & control structures are hard drugs here and Cultural realignment of trust flies in the face of anti-learning Cultures. It’s a hard sell. Thanks for your thoughts – we need more early adopters who are vocal!
Pingback: Where Culture meets Software | SilverFern Software
Pingback: Processes and Tools – IT’s Motherboard complex? | SilverFern Software