Does anyone else remember CMMI? It stood for (or, I guess, stands for, since it's apparently still a thing) "capability maturity model integration." And yes, it was as enterprise-y as it sounds.
About a decade ago, when agile was just getting its sea legs, this was a big deal in corporate software development. You could get certified in your "maturity" on a scale from 1 to 5. Typically, a rating of 1 represented your quintessential cowboy coding shop. CMMI 1 folks didn't use the source code, made changes right in production, and wore 10-gallon hats while they did it.
But if you could get yourself a rating of 5, that meant that you were really mature. You were tracking KPIs, continuously improving, and putting all six sigmas into Six Sigma. CMMI level 5 represented software development nirvana.
I once met a guy who worked for a CMMI 5 shop. We were in grad school together at the time, and he explained to me what it was actually like to work in a CMMI level 5 shop.
Getting to CMMI level 5 means that you spend all your time figuring out how to get better at writing software. So much so that nobody in our company ever has time to actually write any software. In fact, we spend 10 hours on documentation for every hour we spend writing code.
Silos and a Historical Lack of Business Value
I give CMMI a harder time than it probably deserves. While it's hard to imagine level 5 actually making any sense, there was probably real value in moving from 1 up to 3. I mean, getting basic, table stakes practices in place really can only help you.
But the journey from 3 to 5 gets weird and incurs diminishing returns. And it does so for the same reason that agile came along and relegated CMMI to process also-ran status. The journey from 3 to 5 requires an awful lot of navel-gazing in a very specialized silo of software development.
These companies would approach writing software the way they'd approach a global manufacturing operation. Split everything up into an incredibly large batch, complex process that worker bees can execute. Then intensely optimize those worker bees for efficiency.
If one of these worker bees would ever wonder, "where do I fit into the bigger picture," the bigger picture had a clear message for them. Don't worry about that because it's 8 levels above your pay grade. Just inherit from the classes we tell you and implement the stubs we give you.
With this world as our legacy, is it any wonder that software developers don't always have a keen eye for business value?
The Importance of Business Value
Of course, we as techies are hardly blameless. Sure, outmoded methods for managing software projects tried to treat them like manufacturing or building construction. And sure, we endured an awful lot of pointy-haired bosses as this happened.
But we kinda liked it.
Go on Twitter and listen to developers talk. Head to a local user group or a national conference. Run in developer circles. You'll hear a ton of chatter about "getting into" this framework or "learning more about this language." Ask why, though, and you'll get a poleaxed expression. "Um, because it's interesting...?"
For reasons both cultural and historical, we tend to focus a lot more on our tools than on the problems we solve with them.
But one of the core principles of the agile methodologies that beat out CMMI is that we should remain focused on the commercial value of the software we write. And, frankly, that's also just good business. Everybody should have a sense for why the code being written is something anyone would pay for.
So how can you get a developer to focus on business value? Let's take a look at a few ideas.
Ask them to Focus More on Business Value
First things first. Software developers are not the caricatures of nerds that you see in movies, thinking, talking, and eating only in 1s and 0s and saying "does not compute" in robotic voices. That's a nonsensical canard that is, frankly, tiresome.
Instead, software developers are intelligent knowledge workers that tend to learn quickly and have good insights. So if you want software developers to focus more on business value, you could certainly, oh, I dunno, just ask them to do so.
Take Them Out of the Silo
If you're still segmenting developers from business discussions, they obviously won't engage. Even with the rise of agile methodologies, organizations seem to do this by reflex. Here are some things you'll see.
- Two distinct categories of personnel: technical and non-technical.
- Nobody from the business spends the time with developers as they work.
- No developers sit in "requirements sessions." Instead, these are just business analysts, project managers, and maybe an architect or two.
- Developers regularly push back on requirements, calling them "impossible."
Things like this are signs of an organization that makes it plain to developers that they have one job: to code. If the organization puts them in that silo, however gently, they'll remain there.
Get Them Interacting with Users and Customers
Some shops do successfully get rid of the silos, inviting developers to participate in sessions about requirements. Or, if they're Scrum/agile shops, they might have so-called three amigos meetings. And that's great -- it's progress.
But you should go further.
Get the developers working with actual paying customers/users. That can be incredibly illuminating. Let the team see people use the software. What do they struggle with? What do they love? And what do they never even touch?
All of that information not only equips the team to contribute more meaningfully to requirements conversations, but it also gets them invested. They're delivering things to actual human beings with an actual stake in the software. The days of saying things like, "hey, this is what the spec said" are over because the team knows what users actually want.
Share KPIs and Goals for the Software with the Team
If you want to take developer focus on business value even a step beyond that, you should include developers in the discussions about what you measure for success. For instance, are you building an e-commerce site? Then maybe success means conversions or revenue. An internal line-of-business app? Then maybe you're talking about labor hours (and thus dollars saved). You get the idea.
Good developers love to solve puzzles, build impressive things, and generally to achieve. If you don't give them meaningful business goals to chase, they'll invent personally interesting ones. And these may or may not matter to anyone -- they might spend weeks shaving milliseconds off some operation that no one ever actually executes. Or they might refactor an obscure bit of code to perfection.
But if they're engaged as part of the business, chasing the goals that matter to the business, they'll focus that considerable problem-solving dedication on the things that matter to you.
Forget About Traditional Roles
I'll close now with a general and philosophical piece of advice. You should deemphasize or even forget about traditional role designations.
The agile movement enjoyed so much success because it moved organizations away from hyper-specialized teams and into more adaptable, flexible units. More recently, DevOps as a movement has broken down barriers that used to exist between people who wrote code, people who deployed it, and people that monitored it in production.
I suggest you do the same kind of thing now with business and development. Forget about having "business people" and "technical people." Just build teams of "good people" and let them figure out the rest. When you do that, everybody focuses on business value.