Sniffing out a smelly project
Recently I worked on a project which went awry in the early stages. When I say “awry”, I mean that after several weeks it suddenly became clear that we weren’t as far along in the project as we thought we were. It was a wood-for-the-trees situation where everyone was so busy and so involved in the project that we temporarily lost track of the bigger picture. Once the problem was identified we could plan around it and work on a way to resolve it.
In coding, “code smells” are things that you can use as an easy way to check code quality. Smells like classes or methods being long are easy to spot, while concepts like “feature envy” are more subtle. The beauty of code smells is that they enable you to step back from the code and look at it more objectively. So I wondered if the same principles could be applied to projects.
There are few articles on the web about project smells, but below are some thoughts of my own.
If you’re working to a tight deadline you will often need to start development before the project backlog is fleshed out. There might be a rough plan for the final product, but you might find yourself simultaneously building know parts while defining the remaining parts of the project.
This becomes a smell when development starts catching up with what has been defined in the backlog or when you start finding it hard to commit to deadlines because not enough is known about the work coming up.
The mitigation here is to have deadlines around how complete the backlog needs to be and ensure that resources aren’t all directed to the current work and attention is being paid to work coming up.
Work is “almost done done” / Work isn’t testable
The team feel the work has happened, but something has broken so you can’t see it. Or the work is there, but the content is missing. Or the work is done but (add a myriad of reasons here).
Problems that prevent work being testable or visible on CI environments can easily happen and can be perfectly valid issues that need resolving, however this becomes a smell when it keeps happening and isn’t a one-off.
The mitigation here is to ensure that only “done done” work which is tested counts towards your burndown. Identify where in the development chain things are getting held up and work on a solution.
People are unclear where to find documentation
As soon as people start having to search for documentation or are confused about what state the documentation for a project is in, then they might start ignoring it or it may frustrate them and slow them down.
This becomes a smell when you hear people asking where “the latest designs are” or “how should this work?”.
Mitigation here requires all team members to be clear on where documentation lives and what the rules are about how it is stored/tracked. Trawling around to find documentation isn’t really acceptable and probably means that one group is making their own lives easier at the expense of another group.
People are reluctant to do planning
Let’s face it. Most developers hate planning, they just want to get stuck into the code. Most producers and project managers hate planning because it can look like time is being wasted. However, planning is essential to a smooth project.If your team doesn’t want to plan, then it’s a smell which is covering other smells.
Perhaps planning isn’t effective so people are bored or find it wasteful. Perhaps other people are putting pressure on keeping planning short so people don’t want to do it. Perhaps the team hasn’t got enough information to plan.
The mitigation here requires some examination into what makes the team not want to plan and then addressing that problem. So this is a more tricky one!
“Done” does not match the expected level of quality
The team have finished a piece of work and it has been tested and passes the acceptance criteria, however feedback is received that “it doesn’t feel right” or “it’s too slow”.
Qualitative feedback is difficult to describe in things like a statement/scope of work. Often a client might not even realise that they’re asking for something specific and are expecting something different to what they get.
To mitigate this it is helpful to document a reference point for what’s expected. That could be another project similar to what you’re working on or better still some prototypes that demonstrate the level of finish being aimed for. This needs to be discussed with the team so everyone understands what’s expected from the start.
Work has had to be redone unnecessarily
Work is done and tested but feedback is received that it isn’t implemented correctly or that “actually, this doesn’t work for me – it should probably be more like…”.
Agile development embraces change, but change can be expensive. There’s no better way to judge if the idea for a project works than by using the thing you’re making so tweaks and adjustments after work is done are necessary and desirable. However, if change is required because simple requirements were missed or because things weren’t clearly documented then that is a smell.
The mitigation here is to be constructive when people get frustrated with change. Identify whether the change is something useful and unavoidable as a result of seeing something in action or an unforseen change in requirements or identify whether it was due to a problem in the process up to that point.
There are many more…
This list could go on and on and on… however, project smells are probably specific to each company and are probably indicative of the skills and experiences present in those companies. So it makes sense that companies look at their project smells continually and use those to identify problems in their company structure and on a project by project basis.
We’ve starting incorporating these project smells into a retrospective “questionnaire” which is a starting point for a retrospective discussion. Hopefully we’ll be able to smell out problems before they affect projects in the future.
Photo is the Amorphophallus Titanium from Wikipedia (“its odor … is reminiscent of the smell of a decomposing mammal”)