Let's make up an example. Let's say you have 2 processes, people have to: 1) check tests in with their code and 2) write their name on the whiteboard as the last person that checked code in.
Arguably process #2 might not be as useful. So people stop doing it consistently. Then it stops being done at all. New people come join the group and have to learn what processes are done, which ones are bent, and which ones are ignored. I think that this leads to a thought process of "well, if process #2 is optional, maybe #1 is as well". Ignoring one process is a broken window and will quickly lead to more being ignored.
If you have a process, there has to be some kind of audit or automated check. If there isn't, that means it has to really make sense why you are doing it so that it's not really a process, it's just "the way things are done". For processes without audits or 100% buy in, you have to question why you actually have it if it's not important enough to check that it is being followed.
I think that for all processes, every once and a while you should be asking yourself:
- does this process still make sense in our current env
- how much value does it bring
- how much does it cost
- could we be doing a different process for a greater ROI
If you have a process that is almost universally ignored, all that you are doing is weakening the other processes. It's a strange case where the whole is less than the sum of the parts. Back to our example, rather than having said anything about process #2, it's better to not have said anything at all rather than risk that people start to not check in tests with the code. But with that process, if there is no audit, no enforcement, that too will soon be an "optional" process. No matter how strong the process, there must be someone around to check for cracks starting before you have a flood on your hands.
If it is part of the process, you should be doing it 100% of the time. It doesn't matter whether you think it's important or not, you should still do it. You can complain, and try to get it removed from the process if you want, but while it's still part of the process, everyone should be following it.
ReplyDeleteThe word that you used a lot in your comment is "should". My whole point was that "should" isn't good enough. You need to have some test to ensure that it *is* actually being done. The same idea that my code *should* work, but I write tests to ensure that it actually does.
ReplyDeleteAnother point that I was trying to make is that every once and a while you *should* (yes, I'm using the word) look at the elements of the process and check that they are still valid. Just because it used to be the process (or part of) doesn't mean that it's worth while anymore.
When I say that you "should do it 100% of the time" that is the same as saying "you must do it". I'm also using should, because although it must be done, not everyone is doing it. I guess must would be a better word. Either way, if it's part of the process, you must do it. You can still try to change the process, but don't try to change the process by breaking the process.
ReplyDeletePart of my process is "coffee at 2 pm" so I guess I must follow that :)
ReplyDeleteI think that falls under the "the way things are done here" category. ;-)
ReplyDelete