Effort effort everywhere, but not a bit of working software



“Water water everywhere but not a drop to drink”. This is a quote of ancient mariners. In most projects we see lot of effort being spent. Still there is no demo able software. Why is this happening? We are trying to use mass manufacturing techniques when the requirement is customized application.
Software development is an art. Building usable software is not an easy task. Yes there are many software developers who code. But this does not result in usable software. There is a life cycle after the delivery where application takes shape. It is funny to see many times most used features are built as afterthought during enhancement.
Let us see where is the waste in an application development?
Life cycle of an application development:


We spend lot of effort during these phases to maintain continuity. Typically there are some stages which can be avoided without big issues. Why to spend so much time in RFP and vendor selection. This can be avoided by selecting a vendor on the basis of quality. You can always fire the vendor if he fails to deliver. This can be done only when you can set short deadline for delivery.
There is a concept called touch time in manufacturing industry.  When the raw material is not getting processed it does not add any value. All the time when raw material is waiting is a waste of time. Same concept we can apply for software development.
In software development touch time is when the application gets developed. Only during this period value is added for the customer.

Let us list out wasteful tasks which do not add value.

Requirement document: You can give 1000 reasons why this is required and why it is futile to develop without this. Yes requirement document is required. But not in the form it is done today. Document information that is just sufficient for development. You can apply 80-20 rule here. You need to document only 20% of the requirement. 80% of other information will be covered elsewhere or it is not necessary. Typically acceptance test cases can be created which will cover this.
Requirement review comments: Another waste of time. Change the way you are working and review comments can directly go into the requirements. There is no need to document them. Rule of thumb is if anything is not going to be used after a week, do not spend a day on documenting it.
Design document: Why is this required in first place? Only reason for design document is breaking the requirement into technical document. Once this document is done then you can ask a coder to code a small portion of it. Problem is coder does not understand the big picture and codes only items what is asked in the design document. This is wasting brain of an intelligent person. Typical developer has much more potential. Instead of design document you can spend a week re factoring code. This will result in a much better application.
Design review:  When we do not need design review, we do not review on it.
Code comments: I remember my code being rejected many times for lack of comments. Code is more readable than the comments. Comments make code look bad and misguide the person reading the code.
Unit test cases: Write automated tests. Do not spend time writing test cases. Automated test cases can be used throughout the life of application. But unit tests are a waste as soon as application is integrated.
There are many more wasteful practices in many organizations. Many times they are followed with half heartedly.
What is the alternative?
Go lean with Agile:


Cut short the requirement phase. Make it in phases. This gives you space to work on the requirement. It is not hard to see what is absolutely necessary when you can see what is developed at the end of every month. This will make sure that what is getting developed is not something else and you have to live with it for the life of application.
Even if something gets developed which is not the same thing you had in mind you can change it at immediately. It is a month’s effort which is gone waste.
How agile cuts down on waste:
User story: Requirement is captured as user story. This has brief requirement and detailed acceptance criteria.
Automated test cases: Wherever possible test cases are automated.
Self organized teams: You do not need a person monitoring the team. Team is self organized.
Deliver what is committed: Team keeps the commitment. Since team makes commitment it is kept. In traditional models team is not a party when commitments are made.
Demo at end of each iteration: End user sees what is developed at the end of each iteration. This helps in course correction if there is any deviation.
There is time to develop changes: Changes are taken when they are required.
There are wasteful practices in agile also. It is due to lack of understanding of agile practices. When effort is wasted it is not agile. Keep in mind there is no rigid process in agile. It is just a framework.

Comments

  1. Is requirement review really a waste of time? Generally customer / product owner stays outside the team so keeping a proper track of requirement reviews and decision resolutions are very much useful for overall health of the project especially when it come to milestone evaluations. That's the key mechanism to effectively control any disputes.

    ReplyDelete

Post a Comment

Popular posts from this blog

Greedy computing with API

ChatGPT for cavemen

Event driven architecture for micro services