When Process Improvements Don’t Make Sense
Since I joined the team at TrackAbout, I have been rethinking some of my ideas about process improvement.
I have always been a big advocate of test driven development, static code analysis, and other best practices in software development.
A large portion of time at previous jobs I have either spent time explicitly or implicitly in the role of improving the development process. It’s not really a fun place to be, but I’ve always felt a compelling moral conviction to take up that job and make things right.
When process improvement doesn’t work
The team I am working on at TrackAbout is full of developers who are really some of the brightest I have worked with. They not only have vast experience, but a depth of knowledge, especially in best practices.
Applying the same blanket development process improvement steps just doesn’t seem to make sense here.
What I am talking about are things like:
- Code must have 90% code coverage with unit tests.
- FxCop must have no new warnings.
- You can’t be working on two backlogs at the same time.
- Backlogs must be broken down into tasks of no more than x hours.
On most of the teams I have worked, those types of “rules” were things that really helped improve the code quality the team was producing.
For the first time ever I am feeling like introducing “rules” into a development team would actually hurt the productivity and quality of the code.
Very good developers seem to have the judgment sense to make the right kind of decisions about how much code coverage they need to have and which kind of static analysis rules are important.
No set of development process rules can seem to capture the value of that kind of judgment.
I feel like where I work everyone is self-conscious about every line of code they write, they don’t have to be told to be self-conscious about it. It really is something I’ve never experienced at any other place.
Most places I have worked there might have been 1 or 2 other kindred spirits with my passion for “doing things right” out of all the developers at the company, but honestly here at TrackAbout, every developer shares that same passion.
So am I saying development processes are unnecessary?
By all means “NO!” But what I am saying is sometimes the level of rigidity of them is not needed.
When I have been in charge of setting up development processes in the past, I have often been asked the question of “why 90% code coverage for unit tests?”
Having 90% code coverage on unit tests is not magic. It won’t suddenly make your code good, but it will usually work to ensure a few things:
- You have a measurable, enforceable way of making sure unit tests are actually getting written.
- If developers are going through the trouble to get to 90% code coverage, they are more likely writing good unit tests to actually exercise the code. (Not always true, but definitely more likely.)
- It prevents the need for a judgment call by people who shouldn’t be making judgment calls. You can’t trust every developer to make good judgments, so by imposing an arbitrary rule, you are able to draw a line in the sand which is mostly the correct place to be.
There are other benefits and reasons why imposing development process rules can be beneficial. Honestly, for most teams I would highly recommend them.
What I am doing in this post is questioning my own thoughts about applying them to a team of over-achievers.
If not a rigid set of rules, then how do you improve process?
That is the question I am struggling with now. To be honest, I don’t have a great answer yet.
It seems like the principles in my Kanbanand Guide still mostly apply, even in this situation, but…
I am still pondering this question.
I feel like there always needs to be some kind of process improvement going on. Continual improvement is very important. No team is exempt from the benefits of process improvement.
The other problem with improvement process on highly performing teams, is that no one is sitting around talking about improving process. Instead, everyone is getting things done. Normally process improvement talks come about due to necessity, or because it is apparent there is a problem that needs to be improved.
I am sure I will write on this topic more as I find out answers myself to these questions.