If you want your process to be followed consistently…

…make your process easy to follow.  Seriously.  If I have to go out of my way to do some sort of bookkeeping that bookkeeping isn’t going to happen with the consistency that the metrics loving guy is going to want.  You really have to question whether elaborate manual processes add any value.


I took a linguistics class in college.  I don’t remember much (other than thinking the prof was a total clown), but I do remember that the evolution of a language is often just a constant erosion of sounds in a word until the word is easier to pronounce – especially words that are used often.  The evolution of a process should be the same way.  Anything that’s clumsy or manually intensive without adding enough value to pay for itself should get all of its rough edges sanded off until it’s easy to follow and smooth.


Of course I’ve got that Pollyanna idea that the people that have to follow a process should be completely empowered to change, adapt, and modify that same process.  Bad, clumsy processes are almost always the product of somebody that doesn’t have to dogfood their ideas.

About Jeremy Miller

Jeremy is the Chief Software Architect at Dovetail Software, the coolest ISV in Austin. Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy is the author of the open source StructureMap tool for Dependency Injection with .Net, StoryTeller for supercharged acceptance testing in .Net, and one of the principal developers behind FubuMVC. Jeremy's thoughts on all things software can be found at The Shade Tree Developer at http://codebetter.com/jeremymiller.
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://community.ative.dk/blogs/ Martin Jul

    Dogfooding your own process. What a great description – and really, your point about inspect-and-adapting the process, too, is really good. Even RESISTING the urge to create a process is often the best advice since processes tend to be like legacy software – in the way, and hard to change.

    I have blogged about that in the context of retrospectives in this article about using
    using retrospectives to adapt to reality.

  • http://digitallights.com dave thieben

    Jeremy, great article. I’m wondering if you could write a little about a practical example. I understand conceptually what you’re talking about, but it always seems hard to implement in real life. Also with continuous improvement of the processes…

  • http://blog.tieredsolutions.com Dax

    Pedantically I’d add that not only should a process be easy to follow but that the real reasons for following it should be known by the people being asked to do it.

    Sometimes a “bad” process exists for a very good reason.

    Also the very act of communicating the why can mean that a valuable dialogue occurs in which both parties may learn something new eg a better, easier way to achieve the same goal or at the very least a better understanding of how a business (or whatever) operates.

  • http://bloggingabout.net/blogs/dennis/ Dennis van der Stelt

    The same goes for your weblog posts. If you want people to read them, keep them short! :-)

  • Tim B

    Having been saddled with an endless string of manual (and undocumented!) processes in the year since our small-ish company was purchased by a behemoth, this rings especially true with me. Thanks Jeremy – I enjoy reading your posts.

  • http://codebetter.com/blogs/jeremy.miller Jeremy D. Miller

    @jdn,

    I know. To go Dr. Seuss on you, SOX is a pox. Someday we’re going to have to figure out how to make adaptive approaches play nicely with CMM, SOX, SaaS 70, and whatever else is out there.

  • http://www.e-Crescendo.com jdn

    When the processes you follow are dictated by an SDLC created to follow a strict interpretation of SOX, ‘empowerment’ is about the last thing people have.

  • http://www.peterRitchie.com/blog Peter Ritchie

    Not only should a process be adaptable but those who use a process *must* adapt it to their needs and use continuous improvement to ensure it is still relevant and that they’re not wasting time on artifacts or procedure that doesn’t add value to their particular project.