Is there such a thing as a process smell?

Question

We're generally familiar with code smells here, but just as damaging if not more so are when the business side of things - as much as it falls within our domain - is going wrong.

As examples, the inverse of anything on the Joel test would be considered a major process smell (i.e. no source control, no testers) but those are obvious ones and the point of "smells" is that they're subtle and build into something destructive. I'm looking for granularity here.

To start off with here's a couple (which can be turned into a list as the answers come in)

---

• Writing code before you have a signed contract with the client

• Being asked for on-the-fly estimates ("just a rough one will do") for anything which will take more than a day (a few hours?)

• Ancient cargo-cult wisdom prevails (personal example - VisStudio sourcesafe integration is banned)

• You've stopped having non-project specific group meetings (or lack any similar forum for discussion)

---

So what are some other process smells, and just how bad are they?

Answer 1

The book "Antipatterns" by William J. Brown et. al. has a bunch of project-related smells. They aren't always disasters in progress; mitigating circumstances exist for just about any smell.

The Portland Pattern Repository also has a page on Antipatterns, covering many of the same topics as the "Antipatterns" book. Visit http://c2.com/cgi/wiki?AntiPatternsCatalog and scroll down to "Management Antipatterns." A few examples:

• Analysis Paralysis - a team of otherwise intelligent and well-meaning analysts enter into a phase of analysis that only ends when the project is cancelled.
• Give Me Estimates Now - a client (or PointyHairedBoss) demands estimates before you have enough data to deliver it. You accept the "challenge" and give out of the head estimates (i.e. guesses). The client/boss then treats the estimate as an iron-clad commitment.
• Ground Hog Day Project - meetings are held which seem to discuss the same things over and over and over again. At the end of said meetings, decisions are made that "something must be done."
• Design By Committee - Given a political environment in which no one person has enough clout to present a design for a system and get it approved, how do you get a design done? Put together a big committee to solve the problem. Let them battle it out amongst themselves and finally take whatever comes out the end.

Collect them all! :-)

Answer 2

• Back Dating - being given an end date and then told what needs to get done
• Inverse QA Coverage - QA focuses on the non-essential items (because that's all they know how to test)
• Environmental Alignment Issues - the various environments (Dev, Test, Staging, Production) are not in sync for code and data - therefore any testing prior to production is invalid
• Delivery Date Detachment - no one believes in the end date because: it was made up to begin with and 100% of prior projects never met their delivery dates
• Old Grumpy Code - old code is feared because there's no desire to refactor
• the evil pm triangle (scope, cost, resources and/or quality) - to adjust the project you need to add people, reduce quality, reduce scope, etc....once a project is in motion, most changes (even reduction in scope) will increase time and cost and reduce quality..once the train tracks are down, it's tough just hanging a left turn

Answer 3

One smell I have a real problem with (because I work with it): Not ditching tools, dev software, methodologies, or anything else that doesn't work.

Many times, there is one (or more than one) piece of software that clearly, blatantly, doesn't work and likely interferes with the development process, but which a project manager simply refuses to replace/upgrade "because it would cost too much {time, money, whatever} to replace."

Edit: This also extends to machines and other infrastructure too (examples: a build server that takes an hour to do a two-minute build, or a version control system - ahem CVS - that takes 15 minutes to find out whether there have been any updates on a 50MB source tree).

Answer 4

• Shipping a prototype - "we'll productize it later"

Answer 5

I suggesting checking out the Organizational section of the wikipedia page on Anti-Patterns. The I've had to deal with are 'Crisis mode' and the 'on-the-fly estimates' you mentioned.

Answer 6

You haven't had a post project review....when the project ended 6 months ago.

Answer 7

Some smells I have seen:

• Optimistic management, but they can't pay your salary this month. This is real bad. I left the company in time but it died a few months later.
• Extreme fanatic team building sessions. Focussing on how great the company is. But in the end it all goes down.
• Good new people are laid of because they tried to change the process. Real shame. I have seen some people that really tried to improve the company, but old habits never dies so it often ends in a big desillusion.
• The boss is always right mentality...

There is more but I won't spoil the fun for others.

Answer 8

Changes to process are made with no thought to timing or current deliverables, then immediately reversed when deliverables turn up late due to instituting new process.

Someone goes on medical leave and the team as a result is behind trying to pick up that person's work as well as their own and when the managers or clients or client sales reps are told things will be delayed as a result, they are only concerned about when things will happen and can you work nights and weekends in the meantime and never even ask about the person with the emergency and how he or she is doing.

When overtime for low level people is expected but the people who want this urgently leave on time and are not availble to answer questions. Or when they make you work overtime to be ready by 8 am and then don't look at it on QA for three more days. Hello I could have done it by then in regular hours.

Delivery of needed files (for data import for example) or information minutes before the due date and then blaming developers when due date is not met.

Answer 9

Interesting question and even more interesting answers. Thanks for those.

I have been in almost all roles of software development (Developer, QA, Tech Lead, Project Manager - even client) and I can safely list the following smells

• How quickly does the team react to new inputs (and how accepting are they of change)
• How many layers does it pass through to get things done (beaurucracy)
• How clear are the features/tasking - and are the goals SMART and do we have any KPIs.
• How serious is the team working on the project about it
• Is the team meeting regularly (read daily) to discuss achievements, goals and issues.

Most important, however, and the most evident (to a good nose) is the hygiene level of the project management tool being used (excel sheet, piece of paper, agile tools, email, whatever in whichever methodology you use). That is the first thing I notice while evaluating projects.

• Do I know where the project stands at the moment?
• Can I tell (Without asking the team) what needs to be done next?
• Can I tell what the team is working on right now?
• Can I tell when the next release is and if its achieveable?
• Can I tell if client is getting regular updates?
• Can I tell if client is giving approvals and if his feedback is taken care of in time?
• Can I tell just from looking the load distribution of the project on the engineers?

Obviously, all this is well covered if you pick any modern Agile methodology, but depending on the market and kind of work, the mileage may vary. So keeping myself methodology agnostic, this is the bare minimum set of smells that should be rid of.

Answer 10

What I call: NIH (Process edition), a.k.a. Choose your own adventure.

Evidence of this:

• you spend endless meetings debugging the process. And refactoring it.
• nothing really gets done, because no one knows what they should be doing.

I guess this is an antipattern, rather than a smell.