what good is a standard process?
The question came up in a Mary Poppendick's talk on Performance Appraisals and compensation presented by AgileAustin.
Performance review is usually presented as a standard process that is required of all managers and that applies to all employees.
Of course, there are other standard processes, that are just as popular - standard process for getting a project started,
standard process for ensuring product quality, standard process for product delivery.
What do these standard processes have in common? - Well, for starters, they work very poorly when applied by the letter.
The reasons for following the "standard process" are that the people involved don't care enough to generate their own ideas, working hard to cover their behinds, and/or are tasked with work well above their competence level. The reasons for asking people to follow a standard process are largely the same: whoever is asking does not trust these people to do a good job based on their own judgment, and is trying to create cover for himself in case the project goes south.
Another reason people create standard processes is to create a metric. It is often important to measure performance, but extremely hard to do it based on the outcome. A standard process gives a way to measure performance without any regard to the outcome. The project can fail miserably, but if all standard processes were followed to the letter, it is nobody's fault. There is no way to asses the quality of performance appraisals (at least in the short term), but the HR department measures participants on whether they follow the standard process.
I think the idea that a standard process can be used as a performance metric is very important. However, it is even more important to always keep in mind that this particular metric does not measure the outcome of the project. If we are interested in the outcome, and believe the people involved are both competent and motivated to do a good job, standard process is not the right tool.
But in the occasional scenario when outcome is not important (or not known or measurable in a reasonable time frame), and either competence or motivation is lacking, standard process can be very helpful.
- Jane Prusakova's blog
- Login or register to post comments
Comments
First, I agree with you, but
First, I agree with you, but I do think that while the comments on appraisals are pan-industry, the overall condemnation of standards might be more specific. Having a standard process to follow to get a drug approved, for example, may not be a bad thing. For software though, if you accept the premise that standard processes are bad, what can you do about it? The question was asked during Mary's presentation, if appraisals are so bad, why does everyone continue to do them?
Many reasons were cited, including several of the ones you note, but I think if we really want things to change, there should be the same two-pronged approach that Mary used a) show why they are bad, and b) show something better. If you are presenting this to a decision-maker, and you want to change their mind, then the discussion about why it happens in the first place is going to be counterproductive - no one wants to be told that they do something because they are scared or incompetent. Most people, even the scared, incompetent ones, want to solve problems (though some might want to do that simply for the recognition of having solved it, rather than the joy or elegance of the solution itself).
Now, if the discussion is between people analyzing the problem, then not only is the "why is it done" question interesting, I think another question becomes equally interesting - "where do they come from", because that question can often take you to the place where a good thing went bad.
Standard processes typically start as a knowledge capture and transfer device. Would OO[?] be where it is if someone hadn't written down and published what worked for them? These processes (let's not call them standard yet) tend to start because they *did* work - for someone, and probably that someone was not you. I don't view having a documented process as a problem - that comes later.
The problem then starts when someone takes a documented software process and makes it into a standard (can anyone say ISO9000 for software). The software process used for any given project probably needs to be tailored to that specific project, because you never do the same project twice.
I used to work in a factory up in Ohio. It was a subsidiary of ALCOA, and we made platters for disk drives. The goal of any of the data systems that we built for the production line, from robotics to verification was all about producing/proving the same level of quality across all of the product created, day after day. But in this case, every product started from the exact same place (a roll of aluminum), and went through the exact same machines to come out the back end.
In software, you never, ever start in the exact same place (knowledge, code base), and you rarely pass your code through the same people (equivalent to the manufacturing machines), and if you do, they are never the same people twice. At least one of the programmers will have some new meme infecting them, which will alter the way they work and think, so (and here is where I agree with you), how can a standard process be expected to work for all those cases? This, I think is where the process went bad. It's like teaching freshman a for loop, and then telling them that's all they need. Every good developer has a full toolbox of code syntax, algorithms & snippets, languages known, etc.
Shouldn't development be managed the same way? I have not yet read a single Agile article saying XP is the silver bullet, or DSDM will cure all the ills, yet I see organizations embracing these specific disciplines, not just Agile in general, with all the fervor of a 19th century physicker handed a hypo of penicillin.
So, I think that documented, shared processes are good, and I agree that standard processes are always going to fail over time (even if they are successful 16% of the time ( or whatever CHAOS is saying this year)), but to be more successful, more knowledge of available processes (and the ability to put them together, there's that darn competence thing again) makes sense. Now there's a book I'd pay to read - How to Pick And Choose Your Development Methodology.
Thank you for an excellent
Thank you for an excellent discussion.
A process to get a drug approved is a situation where the outcome is not knowable - there is simply not enough information before the drug is approved whether this particular drug should be approved.
So settle for the next best thing - follow a standard process, do the due diligence, and then take the risk of either decision on the drug. This is exactly the scenario where I believe standard process works well.
The software industry has had many "silver bullet" propositions, and so far every single one of those turned out to be a fad. The buzzword I hear most lately is "Scrum", however, on closer examination it turns out that people mean wildly different methodologies, systems and processes when they say that they use Scrum.
Jane Prusakova
Software Architect & Developer
http://www.linkedin.com/in/prusakov
I would tend to agree. I've
I would tend to agree. I've seen a ton of different fancy methodologies come and go over the years. While most of them have had some good ideas, none of them have been magic and worked for everyone. I tend to favor an eclectic approach that borrows from many of the different methodologies and is tailored to the particular organization it is being implemented in. In a simplistic way of looking at it, finding the right system is figuring out the least amount of formality necessary to keep things from descending into chaos. Generally the larger the group the more formality is necessary, unfortunately and I believe that has a lot to do with why it often seems that the largest projects are the most likely to fail catastrophically.