The Sherpa Project

It is easy to fall into patterns of practice in almost every profession. Software is arguably one of the worst when it comes to following stated “best practices” and looking for process frameworks or formalities that guide various stages of the software development lifecycle.

In theory, this is all great. In practice, it (mostly) sucks. The problem is that we try to be compliant with the wrong things and for the wrong reasons. There is no reason to be compliant with any framework, any process, or any certification unless it is results in creating value for your customers.

How many customers do you think know that you are CMMI Level 5 compliant? How many would care if they knew that you were? When it comes down to it, these certifications are useless if they are not working to make a significant effect on the quality of experience with your customer. For many processes or process frameworks, that’s exactly what they intended to do. Unfortunately, most of them ended up being a framework that is primarily concerned with building up huge amounts of waste.

I’m not sure when this all happened, but the one thing that I do know is that the majority of software projects that I have seen, studied, or have been involved with are obsessed with process and not with customers. This is one major reason that I began to question everything that I do on a day-to-day basis. When I started asking “Why?”, I started realizing that a satisfying answer was the exception. The majority of what we do, we do because we learned to do it that way.

So, what can we do about it? I think the answer is to look at things with Beginner’s Mind. Start to question your process, start to question your activities, start to question your intent, and start to think in terms of your customer.

Can you imagine what would happen if you took the time that you spent on “compliance for compliance sake” and spent that time with your customer? If we replaced the time we spent on a technical specification with having a couple of drinks with our customer then it would probably be for the better. If we removed the time wasted on the formalities and politics involved with functional specifications and put the effort towards understanding a day in the life our customer, or if we replaced change control formalities with a weekly game of golf with our customer then we might really get somewhere.

In short, I think there’s value in making the move to unlearn and look at everything with new eyes. Simple economics and common sense make me think that we might just have the ability to make better software.