Software people say that software development is different than any other business. You’ll hear the same from marketing, sales and other businesspeople. Even as software has become such a core business operation, it’s still considered black magic.
The divide between developers and management has been growing since people started writing code. In the last decade, it seemed that new agile development approaches would bridge it, but we’re currently seeing signs that the bridge is not so stable. If we’re not careful, we’ll be right back where we started.
But I’m getting ahead of myself. Let’s go back to the beginning.
The “prehistoric” era
We’ve been conducting modern business operations for the last half millennium. We’ve had some time to learn how to sell, market, invest and manage people. We may not be great at all of those things. It may seem that these things changed over the last decades. Yet, the principles are still there.
Software is an infant compared to the rest of the traditional business practices. We’re still taking our baby steps. As IT and software have become important to organizations, we tried to implement the same management principles in software groups. Applying the “old” principles to “new” people has not achieved acceptable results.
We saw this in the first early CHAOS reports: Software projects were failing left and right. Features were developed but not used. Specification documents, too heavy to lift, were written for years before writing one line of code. Product releases were late for months and years, missing the market. Software has become the troublemaker.
As you can expect, businesspeople were not happy. Lots of money were poured into software projects (and went down the drain). The high salaries for top talent didn’t transform into company revenue. “What are we paying these guys for?” was thrown around a lot.
“These guys” were also not happy. Management kept changing their minds about what they wanted. Everyone had an opinion, and developers were pulled in many directions. There was never enough time to make sure the software worked, since the sales guy promised it to the customer last week.
And then it got worse.
#!
The secret society
We’ve had guilds before. We still have the equivalent for lawyers, doctors and other professionals. Software people belong to a club that looks a lot like a guild: Developers speak in terms that no one else understands, their expertise is something that is hard to describe to other people, and they charge a lot for their services. To make it more annoying, developers get a kick out of belonging to a secret society.
Managers don’t speak developerish. When developers talk about “pipes” and “transactions,” it sounds arcane. Developers have been using the secret language to conceal what they were working on. On the other side of the river, businesspeople haven’t taken the time to translate their motives and needs from business language. The two sides built a convenient smokescreen. Both have lost trust in the other.
Then came agile. Agile was supposed to be the answer, the bridge between the developers and business. Agile practices, like stand-ups and retrospectives, increase visibility, expose issues, and allow mitigating issues. The businesspeople saw what was behind the veil of developer secrecy. That was tough for developers to accept. But there was also shared accountability with the businesspeople, which developers embraced.
Developers got another bonus: iterations. Within the iteration, they were safe from the distractions from different parts of the business. “Can you just change that?” was no longer allowed within iterations. Less distraction meant less friction.
After years of delayed milestones and death marches, managers finally got real deadlines. They saw progress in a matter of weeks, not months. It was not the predictability they wanted (they really wanted to know everything will be ready on time and on budget three years from now), but it was much better than before.
Agile’s promise allowed the entire organization to create value with reduced risk. Everyone’s a winner, as long as they played by the rules.
The double-edged sword
Scrum emerged as the winner among the agile methodologies. In hindsight, it’s very easy to see why: Organizational change comes with management backing. Scrum talked about management ceremonies, so it was easy to get management buy-in. Since Scrum’s language didn’t include test-driven development or automated builds, managers got it, and therefore accepted it as the solution for their problems.
Scrum was a great sell for managers. But in some cases, managers kept the developers out of the loop. And that’s the problem. How can we have working software without developers?
Craftsmanship
Developers are a smart bunch. They understood they got shortchanged by Scrum. Some reacted by raising the craftsmanship flag. Craftsmanship doesn’t just bring software practices back into the spotlight. In fact, craftspeople see those techniques as the only way to solve real business problems. Automated builds are the way to early quality release. Refactoring is the way to put out maintenance releases in short cycles.
The new division between the camps brings us back to our starting point. The business thinks developers are at it again with their secret cult, and developers think the business is at it again with more managerial stuff. Mistrust has made a comeback.
Now what? If this continues, businesses that have accepted Scrum will lose to organizations that employ software practices. Software is produced by developers. Scrum-only won’t do. Organizations that understand this will be the clear winners. To them, the bridge between managers and developers is a stable one.
Agile exposes issues. Here’s an important one: If your company doesn’t involve developers in your agile implementation, you will lose the business and your developers.
Let’s not waste the opportunity agile has given us.
