I've worked in big and small companies and sooner or later every company I've spent time at started tinkering around with their SDLC (or their PDLC, or their ISO compliant seven stage development methodology, or their standard project template, or what ever they called it).
I put some thought into this recently. Why is it, I pondered, that organizations sink time and money into a second-order problem space with frequently dubious results? (As an aside, if anyone is reading this blog, I'd love to hear your experiences with "SDLC re-envisioning projects" via the Comments for this post).
Some of the emphasis on this meta-work may stem from deflection tactics -- Revenue is down because our process is broken...
Some of it may be a misguided attempt to scale -- We need to define our process tightly so we can double our team size and still keep the same great culture of innovation that got us here.
Some it may be a wrong-headed attempt to abstract people out of the project teams, and to treat people as fungible resources -- We need process uniformity so senior management can easily and quickly deploy resources to the most strategic projects, with the highest return on invested capital.
None of these reasons make good sense when you weigh them against the amount of work required to get five or six product teams to do their work with uniformity - on five or six disparate products, with disparate technology stacks, disparate maturity levels, and most importantly disparate people.
Plus, those reasons I came up with sound contrived. So I thought a little more about what's behind the contrivance. And I've since come to think, based on my experience, that organizations usually tinker with their SDLC for one of the following reasons:
- A new executive joins the team, with commitments for a quick turn-around, and with an a priori prescription for greatness
- An existing executive reads a new book on a new process tweak that promises a quick turn-around, and offers a ready-made prescription for greatness
- Things are going badly - Performance is weak, projects are late, revenue is flagging, customers are unhappy, productivity and morale are down, etc.
- Things are going well - Performance is strong, the numbers are up, and the team is undergoing massive growth - meaning that there is a dilution of the "core" technical leadership team
I haven't gone so far afield as to issue a fatwa against process orientation. But SDLC definition is not in any way the same as process orientation, and in fact it's a poor substitute.
Talking about and standardizing how you do your projects is a second order problem space, and tinkering here is almost always an inflection point. And not the good kind. It's frequently a zenith. An apogee. A high point before a precipitous decline.
The best teams I've worked with (and sometimes have been privileged to lead) could have produced great product with high quality, on time and per plan, without any predefined process, or in spite of an utterly broken SDLC. The worst teams I've worked on (or in some cases I'm reluctant to admit, that I've helmed) couldn't have produced great product even if they had a process framework that defined every step along the way, and all they had to do was code-by-numbers.
Again, in my experience it's common to look at that broken team and blame the failure on process. It's more interesting to look at the successful teams and figure out what it is about them that makes them work well, irrespective of process.
If you think back to the great teams you've been on, I bet one thing will pop out as common:
Yeah, I know, that's not a word, but I bet you get my meaning. Teaminess: everyone knows what they're doing, and why. There aren't any jerks. People get along. They have a shared fate. They know their jobs. They know how to do stuff, when to do it, and why. They have lots and lots of teaminess.
Maybe they have all their spec templates, decision gates, and feedback loops defined in advance, maybe they don't. But with all that teaminess, it really doesn't matter. Because as a team, they will sense if there is a breakdown, a weak spot, a risk, or a lack of definition. And they will fix it, as a team.
I wrote last week that I believed software engineers shouldn't improvise. I still believe that, even though this essay seems to be taking me in an orthogonal direction from there. Bear with me.
It's not import an to have all the SDLC steps, responsibilities, etc. defined externally. It's important to have them defined within the context of the team doing the work. That is, to extend the Jazz metaphor, your team (the band) gets together and does the composition -- they write the score, themselves. They decide the key, the tempo, how much they put on paper, what cadenzas they leave for which virtuosos. But they DO NOT spend several weeks or months fretting about how to make sure their templates and numbering schemes for their specs match the templates and numbering schemes for specs produced by some other product team in some other campus.
The best teams I've worked with developed their own understanding of what they were doing, how, when, and by whom, right in the context of the project. I argue that this is a lot better and cheaper than a meta-process definition, because it's closer to the work.
That led me to the notion that I think is clever -- rather than having an external process definition, and training people to use it, develop a concept of a project glossary. If people don't already grok why they need to do this, point out the obvious -- for people to work together on a team, they need to have a common understanding of (and vocabulary for) a few things. Off the top of my head:
- What problem are they trying to solve?
- Who are the beneficiaries of the solution?
- How do those beneficiaries want to interact with the solution?
- How will the team document requirements and decisions?
- What artifacts will the a team produce (specs, test plans, executable product, etc.) on the way to the solution?
- At what level of granularity or detail will those artifacts be developed?
- What are the commonly held coding standards and expectations?
- What tools (and what versions of those tools) will be used?
- When do you start tracking defects?
- What level of detail is required for defect reports?
- What specific project vocabulary do you have, and does everyone understand it?
- What things are required, and what things are "nice to haves" before you call this thing done?
But I think the big idea here is to define this in a small local context, very close to the work, with the involvement of all the people in the work. You write all this stuff down, you've got a project glossary. Put it in a wiki, and you've got a really powerful tool to help your team with its teaminess.
I worked with an executive recently who was fond of saying something like: "people will support a universe they help create". I suppose this project glossary approach is the logical extension of that notion.
You could try to define all this stuff in advance, externally to a given project, and impose it from above. But that would be second order work. It would be a waste of time. It wouldn't help the team; it wouldn't work for them; they wouldn't adopt it; and it would give them a ready-made scapegoat for failure.
A better, cheaper and ultimately more successful approach (that I've seen work many times) is to get the team together, the entire team, and spend the first several days (or weeks for big projects) of the project laying this stuff out, and getting everyone on the same page. It may seem like extra work, particularly when most projects in my career have seemed to be three months late to market on the day they started. But this approach will work, and in my experience, externally defined and mandated SDLCs or process models promise a lot, but deliver very little.
Like I said, I'd love to people's thoughts on this, so please offer your comments.