Formality
Recently, we’ve been practicing what I like to call “project archeology.” Almost four years ago, I joined my current team to work on a rewrite of an old IMS/CICS based accounting system. We were designing a new data model, switching to DB2, and moving to a web based user interface courtesy of Java. Things were really cranking along until our senior executives do what they do best: they announced a “merger of equals.” Needless to say, our world hasn’t been the same since.
During integration (and some would argue its still going on) my project was essentially on hold. For quite some time, it sure seemed like my project would whither on the vine but for reasons that aren’t entirely clear, its back. Over the course of the year and a half that was integration, a number of things have changed – we’ve got new management and several team members have moved on. But as I said in an earlier post, abandon all hope for a better past.
So what does that have to do with project archeology? Our new PM is going through all of our old documents trying to answer two very interesting questions: what did we promise our customers and what do we have left to deliver. While its hard to answer the later without knowing the former, we really have a firmer hold on what’s left than what the target is/was. Anyway, its been quite fascinating to peer back and try to remember what someone might have meant by “Foo feature must perform better” (a real “requirement”) and figure out what features might have been tested.
But what does this have to do with formality? Over the years, my company has used a number of different methodologies with all the requisite templates and forms. Now, I never really knew what any of these documents were supposed to prove other than methodologists are the cockroaches of IS – you just can’t kill them. Seriously, it doesn’t matter how many reorganizations a shop goes through, they just don’t die. The tend to change names a lot though… OK, enough of that rant. I have to admit, I wasn’t on the project when much of what we are now dissecting was written, but it sure looks to me like all the “process” we followed at the time is doing much to help us today.
As I was sitting in a project meeting last week, I was reflecting on the difficulty we are having piecing our past back together and I was wondering if a greater level of formality would have helped our project. A friend works at a shop that is actively seeking CMMI level 3 and my first reaction was – why? I’m a big fan of agile approaches since they seem best positioned to deal with the inevitable change of software (and I can’t help but like the importance of people in these processes.) But you know what? After a few months (don’t ask) figuring out where we are and where we were trying to get to, I’m starting to wonder what the right level of formality is on a software project.
I don’t have any answers but I sure do have some questions! What affect does company culture have on the need for formality? Does the type of application matter? What’s the right level of formality? I’m not ready to run out and champion CMMI at my employer, but next time I join a project “in the beginning” I think I might try and impose a tad more discipline.
Good write up!
“What affect does company culture have on the need for formality?” I think that has a LOT to do with the need for formality. Some companies have a real CYA culture where its more about proving you did what you were told to do rather than solving the right problem the right way. Obviously in a culture like that having tons of formality allows everyone prove they followed the “letter of the law.” Regardless, its tough to be sucessful in that environment. In a culture of “trust” (IMHO) it is easier to adopt less formality.
“Does the type of application matter? What’s the right level of formality?” I’m sure it matters in some cases, but I don’t think its the significant factor. Instead I think it has more to do with the team and how it wants to work. Both Alistair Cockburn and The Pragmatic Programmers believe that your process (and thus the “level of formality”) should taliored to individual teams/projects adopting appropriate aspects of agility. I think the hardest thing is that experts always say “it depends” leaving you to figure out the right balance.
“I’m not ready to run out and champion CMMI at my employer” I hope not!
“I think I might try and impose a tad more discipline.” Discipline and formality are orthogonal. Most agile processes stress discipline.
I think the more interesting question is: After 18 months and a merger, are your requirements still the same? Is the project’s business case unchanged? If the answer is “yes” then I would say for your project… formality could be useful because you have very static requirements.
If not, I’d say… get the code building, grab some high priority user stories and write tests to prove that the feature is complete/there (green bar done! ) or needs to be developed.
John – couldn’t agree more. Culture is so key (and you and I have some shared history there!) The longer I develop software, the more I realize that people are by far the most important piece of the equation. Sure, you can have the best tools, the fastest computers…if you’ve got average people you’ll wind up with average software. I think its interesting that the people who know the least about agile call it undisciplined when in my mind, there’s more structure in a well run agile project than most of the fire fights I’ve been on!
Oh, by the way, my project has over 1400 tests – maybe that’s not much but we’ve only got about 600 Java classes. Needless to say, I like JUnit!
I definitely agree with you Nate. Obviously certain managers (*cough*) think everyone is plug and play. Its easy on a high performing team to say that all this overhead/process slows people down because we are disciplined enough to manage ourselves. But what do you think about a less experienced or not as talented staff? Does the BDUF and LOTS of process work better for these types of teams? Is there a relationship between the abilities of a team and the amount of process necessary?
Well, I’d argue you’re always better off with the best people you can find but certainly, if you have a bunch of average or below average performers, process and planning can help. Frankly, I think that’s part of what *cough* we’re seeing these days…and of course you can always ask yourself “why would people want to surround themselves with average?” Truth be told, coaches, managers, etc. can only do so much to improve a good team, however, there is no limit to the damage they can cause any team. The problem with using planning and process in lieu of quality people: you get what you “pay for.” In other words, if you treat people like imbeciles that have to be told *exactly* what to do at all times that is exactly what you’ll get. But then that’s just my opinion, I could be wrong. Given the choice, I’ll take high quality people over any process.