06/10/2014

Cutting Corner Every Day - How we change that

I have been thinking about writing about this for long time. But I have been too much focusing on my startup, KareerTracker. But recently, I have been hearing about "cutting corner" almost every week in software development teams. Is that kind of "crap" built into our industry?

There are two problems that I often have seen:

1. When we fix problems, teams often take shortcuts and never look back and invest money and time on long term solutions. All our wish is that we won't have the problem again. But they will come back again.

To fix the problem, I have adopted post mortem and  the counter measurement board idea from Jason Yip. And we implemented monthly board review meeting to make sure that we are make progress on long term solution and prioritize them.

The outcome is really positive and we got several big improvement done with the help from the board. At start of my journey in a business, there are issues almost every week. After two and half years, there was only one issue for three months and impact was much smaller too.

The best impact of that is development team have more time focusing on improvement and innovation instead of fixing issue. That is bigger than anything else.

2. Teams mixed prototype and software development. Teams often either grow prototype into production without architecture design or we just write prototype into existing production code base. And in worse case, business people will sell the prototype as a product and we can't remove them even there is no market demand for that.

Another similar problem is that business people wants to experiment in production environment but there is NO proper architecture supporting that. Then we HACK and never clean because it has been hard.

You normally can have a sense of problem at story grooming and sprint planning sessions. The typical symptoms of the problem are that product owners use general word, such as customer, as user for story,  or hear "dont have enough money", "dont know whether they gona buy",  "there is one customer asking for this", "it will be a big success" without signup paid customers and others which propose there are limited number of customers or unknown number of customers in the coming 3 or 6 months.

The first thing that we have done is to develop an architecture which will decoupling code between features, "vertical slicing architecture" (I will write more about this in later posts) + feature flipping. Each major feature has its own component and we can easily  add and remove one feature from production. In experiment and explore stage, we can plugin a new feature / component in with quality just enough.

But there is another thing must be done. That is educating people about difference between prototype and production. Prototype will be used to discover customer needs, just enough quality is enough. But production code needs an excellent design and easy to use provision.

I often found that there are more effective ways to prototype without write a piece of software to test customer demanding. Product managers just need to change mindset and be more innovative. If you want to understanding more about prototype, you can read the wiki post.


No comments: