Have you ever thought about this? Everyone today in Software Industry knows the best practices in Software Development. Agile is no more a buzz word today. But, why do we see them, hear them only from some consultant’s presentations (either during a start of a project or when a project is in trouble). Don’t take me wrong. I also do consulting quite often and I also prepare presentations 🙂
Why they are never implemented?
I guess there is no single answer for this. I believe there are multiple aspects to this problem.
90+% of the time, a project is sized without proper analysis (from few liners of requirements to a few page requirements to few days analysis). Why does it happen? If you are in a services company and if you don’t do it, one of your competitors will say i do not need this initial exercise and get the project. If you are in a captive firm, always there is this feeling, I know it better.
Even doing the initial analysis has time and money associated with it. Then irrespective of whatever is the proposal, there is always a negotiation and the age old trick of reducing cost is the same. Cut the testing effort. Reduce some %age in development effort and we are good.
Reason, the priorities for different people are different at each stage. Money is the most important thing in the Business. For a services company, getting a business is important. For a sales person bookings are important. For a software company reducing cost is important.
This reducing cost, is it done using some parameters? In a RFP response, even though a company might be well qualified, but if their cost is high, the contract goes to the company which is quoted less. This evaluation, do they always happen analysing multiple parameters. Do we do ROI Calculation to take a decision? Not necessarily.
Agile has given a new way to look at things. The IRON Triangle has been reversed in Agile. True, but what we didn’t understand is that the IRON Triangle didn’t disappear. It will not till the time we this business. Scope, Time and Cost are proportional to each other. If there is a change in the scope then Time and Cost increases proportionally. Because the Triangle has been reversed, we are not completely out of it.
Let me explain with some examples:
If we do not have time to write requirements (In some form of Minimum Marketable Feature, User Story, Use Case or XYZ…), When will we move to capturing acceptance cases per requirement? If it is all about time, then this may require an additional person which in turn translates to Money. If we do not even capture requirements, capture acceptance cases, how can we think about doing Accpetance Test Driven Development or Specification By Example?
If you need to write Unit Tests, whether you want to agree or not, you are going to spend some additional time (Pure agilists may say its not going to increase time. But, in reality it takes some additonal time). Time translates to money. If we are still following the age of trick of cutting testing efforts, how do you expect this to be followed? If we do not have an understanding of the scope completely, given an estimate, in my opinion there is no way in the world you will do all this.
Take the example of Continuous Integration , You need to have build integration, maintain your builds and integrate your tests and run it everyday. Building, Maintaining have some effort involved which again translates to time and money.
If we are not in a position to do Continuous Integration, how will we do Continuous Delivery? We are talking about an utility which will take the build, automatically deploy it in an environment and run the test cases and say your code is working?
The point which I am trying to make here is any effort has time & cost attached to it. You cannot do 101 things with whatever limited budget and resources you have. Implementing these best practices has some work involved and it has to be considered within your scope.
There is no Free Lunch.
To start a project, it takes years. But the moment we are in, the schedule pressure kicks in. Scope Creeps, Team changes, additional integration happens. We continue to add Technical debts. Because of the schedule pressure, we continue to ignore them. Our product owners do not understand the meaning of technical debts, design debts etc. etc. We become either ignorant of all the issues knowingly or unknowingly. Teams becomes frustrated to fix, add features but continue to work on the same code base.
Because of all these, we are promoting a community who knows what it means, but don’t want to implement them.
Have you not seen these implemented in some place?
Yes, I have seen this implemented in some of the projects in my own experience. Companies like Thought works are doing it. I have seen this implemented in some small companies. I have seen an implementation of a Continuous Integration Server written by set of people 10 years back and they are still working on FoxPro. But, the point is they have spent considerable amount of effort in that, which in turns translates to money.
Secondly, it is about making it as an organization culture. If you look at how Thought works, Google and other companies have done it, they all have brought it inside their DNA.
What is this culture all about?
When you are habituated to a set of things, doing things in certain way, it becomes a culture. Again, I am not talking about 1 or 2 teams implementing in a 100,000 member company. I am talking about doing it as a whole.
Why is it important to do it as a whole? So that everyone in your company is in the same page. Your sales guy will not give gyan to reduce the testing effort. You do not have to argue on why it takes a longer time to hire a talented resource (I am sure you understand what I am saying here).
So, what are your suggestions to implement all these?
- Communicate the effort and cost involved in bringing all these practices. All these in Writing. Get an Approval or Disagreement in Email, before initiating the new project.
- Get the right level of leadership at all level (Program/Project Manager, Product Owner, Architect etc…). Understand that it’s not easy to get the right level of leadership. You cannot add people whoever is available. It requires a much more level of filtering.
- Start any project with a decent set of requirements. Track the requirements and document changes (I am not talking about bring our old Change Control Board here). Whatever we do, at the end of day we should know how much have we spent for any particular work and to track that you need to know what you have done in the project.
- Start the project with couple of resources who can implement all these practices (may be couple of sprints). Slowly add new members to the teams who can fit with your culture. When they come in, make sure they understand the culture and adapt to it. It becomes a habit. If someone is not culturally fit, do not hesitate to move them out.
- Slowly introduce additional practices.
- Track Technical, Design Debts. Prioritize them. If you don’t pay your debts today, you will end up paying them after sometime with interest.
- Review the 7 Software “-ilities on a regular basis. Not just at the time when the project is in trouble. Invest in tools which can help you get better statistics.
- Make sure you review with your stakeholders about the practices and efficiency of these practices throughout the project.
- Make changes as needed.
The whole exercise requires one thing. You need commitment from all your stakeholders on what you are doing and the willingness to spend.
Can these be done in Fixed Cost Projects? Agile Gurus (Ken Schwaber and others) have mentioned that fixed bid projects are always the way to get to lose-lose situation. If reducing cost is the only thing you are looking for, all these will definitely not work.
Finally, we are not in the business of making popcorns. How to make the best popcorn could be done in 7 steps, but not software development. In this whole business, every project is complex in its own nature. There can be no bullet points.
Doing all these, can they guarantee success? May be, but at least you will be in a better position with your code base. May be decision of getting to a “Look-a-Like” Migrations can be delayed for another 5 years.
Till all that happens, the best practices are always going to be only in presentations (at the start or end of the project).