Old code, still running in production.

  Every chart went up except one The quarterly review opened with a slide everyone loved. Since the team adopted AI coding assistants in January, pull requests merged per week had gone from about 40 to over 110. Story points per sprint had nearly tripled. Someone in the room said "10x team" without irony. Karthik, our engineering manager, had the next slide. It showed what customers had actually received: one release every two weeks, the same as last year. Bit more features per release, give or take. Not 10x. The roadmap was still three months behind. Nobody had a good answer. The developers were clearly faster; I had watched a junior engineer build a full settings page, tests included, before lunch. So where was all that speed going? Karthik found me at the coffee machine afterwards. "You've been here longest," he said. "Have you seen this before?" I had. Many times. Just never this fast. Following one feature home I suggested we stop looking at dashb...

As a customer you need to spend lot of time during development with the team. Requirement from the customer Dedicated time for the project. Clarifications before it is late. Define requirement and participate in planning (assuming SCRUM model) Regularly participate and check the progress. Based on the working product define new requirement. Correct the developed product in regular intervals. This requires lot of time from the customer (product owner). Usually customer assigns a product owner who has other responsibilities. Project is secondary responsibility for this person. Time requirement for agile project will hamper the work of this person. Unless you have the commitment to see the project succeed do not go for Agile. When you have people who can decide on your behalf and they have the bandwidth to accommodate agile team's requirement only then project will succeed.

How a demo can improve the quality of the product. It will not be significant if the demo is at end of project. But it will improve by leaps and bounds if it done every week or two weeks. A demonstration of application is show of confidence in the product. It requires courage to stand at the center stage and show the application to customer. You need to be 100% sure things are working fine when a demo is given. This brings in a discipline of delivering what is promised. Not to over commit on delivery. This itself is a huge achievement for a project. As a customer never hesitate to ask for a demo. If a demo is planned do not skip for any reason. If you skip it you are wasting your money. Other benefits of a demo are you know what is developed and how it works. You can correct the course of the project at this stage only. If you find few things not necessary you can scrap them right away than spending more money on them. Giving a demo requires some supporting work from the ...

Agile development offers many benefits. Wherever it is followed it gives huge benefits. Still it is not used wide spread. There is lot of resistance for adapting agile. What are causing resistance? Courage: It requires courage to adapt agile. You are going to work in a environment full chaos (controlled chaos). You need to stand up for your work. You are responsible for the teams goal. You cannot escape by telling you did your part. Agile is a team work and you are responsible with the team. It is very scary for many people to describe their work. SCRUM flavor of agile has meetings every day to talk about what was done yesterday? What will be done today? and Issues to be resolved to achieve it. More than 70% in the industry cannot do this. Ego issues come into play. You are not safe till test team finds issue. You are exposed daily. But this very factor contributes to the success of the project. This brings the team closer. Non performers are forced to move out. Tea...

Any time you mention Agile you hear it is applicable in Product development. It is true agile is used more in product development. This might be due to the reason it is easy to follow agile in product development. It is also due to product development requires more agility to compete. Let us compare few aspects of product and an application (services). Product development Software Services Requirements It is in discovery. You start with an idea and develop it. Never frozen. To survive in market need to be two steps ahead of competition. Requirements are clearer. Before the service provider comes into picture customer spends lot of time defining the requirement. Quality High quality is desired. Buggy product is not liked by any customer. Support cost is part of product price in many cases. High quality is desired but not achieved. High quality costs more. Budget There is comparatively more money ...

“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...

Many projects do not become completely agile. They start by telling we will use SCRUM for this project. A small training is provided and team goes agile. There will be some benefits in the beginning and some short comings. But definitely project is not a huge success? What is going wrong? Trigger happy top management will pull the plug telling we tried agile and it is not working for us. When following SCRUM for the first time it is better to check whether SCRUM is followed to the full extent. As the old say it is the traditions which allowed humans to survive and evolve. It requires wise and old to tell what the tradition is. You can decide how to follow agile once you become expert on agile. How do you decide whether you are following agile to the full extent? Jeff Sutherland has developed a scoring system. This is called Nokia Test (or SRUMButt test). You can read more about this in Jeff Sutherland’s blog http://jeffsutherland.com/scrum/nokiatest.pdf . Most of the teams claiming to ...

There are many projects which follow few of SCRUM framework like continuous integration, daily stand up meetings, short iterations, customer demonstration etc. They do not follow the agile manifesto or not even aware of it. They follow these as best practice or learnings from a successful project. Most of these do help the project to deliver a better product. Then why am I cribbing here? It is the same issue of SCRUMButt. Even if these are followed as best practice or SCRUM it results in local optima.  I will bet many managers and customers are pretty happy with these. But they are missing one important point here. Local optima causes disillusionment, frustration and fatigue which is bad for any project. It demoralizes the team. After all the hard work and beautifully done application customer coming back and telling, see here I cannot use this without these changes. Now the manager comes and tells the team, guys you have  done a great job ti...

Traditional project's cost of change. What is the cost of change? Above diagram will tell you it increases as project progresses.This diagram is from PMBOK which tells cost will grow exponentially and stakeholder influence will reduce as time progresses. Probably this is not a good thing as stakeholder should have influence throughout the project. In any dynamic business changes are inevitable. Business is dynamic and will require change in the project when the project is progressing. This model puts a high price for the change which cannot be avoided. Now let us see why the cost increases in the traditional projects. Traditional projects are executed by a plan. Plan is used to reduce the cost of the project. There are no reusable (automated) tests. Team need to work as a plan. If plan is not followed there will be wastage of effort. This is blasphemy for a traditional project. Since there is a separate testing phase whatever is developed is not tested or not ready for delivery. Th...

What is the incentive for the vendor to deliver good quality product in lesser time? Most of the time agile projects have time and material contracts. This does not give good incentive to the vendor to perform well. If project gets closed early vendor looses billing. There are benefits of earned goodwill. But this does not last for long time. Customer organization can have changes and all the good will is lost. There should be additional incentives for delivering early and better product. How to quantify these benefits? This is a tough job. One way out is taking average time taken by industry for a similar complexity project. Based on this number incentive can be calculated based on the ROI expected. This will be a win win situation for customer and vendor?

Nobody wants their work go waste. But most of us would have worked hard to develop something which is definitely not going to be used. It is like building a igloo in Sahara desert. It will just melt away as soon as it is done. Many times there are situations where we have to develop some features in the application which we know are not useful. Customer also knows it cannot be used. But it will be part of the agreed requirements to be developed. To meet the contract you just develop those small things and spend time testing those are working fine. It sounds funny. But it is very cruel and waste of money. And it happens in most of the projects. No developer likes his work go for waste. They would have got paid for doing it. But to develop a good software it requires more than coding. Only when the team puts their mind and heart together good software gets developed. If you need good software then do not waste the effort. Wasteful effort is usually result of contracts. Otherwise no perso...

Companies which use agile development for development are usually product companies. There are few odd companies which use agile for software services also. They are successful but they are not in mainstream software service business. I want to analyze why agile is not adapted in most of the offshore companies. Some reasons attributed for this are: Communication is difficult and agile requires daily communication. Agile is not suitable for offshore (outsourced) projects. Agile is for product development. Developing in agile is expensive and not cost effective. Etc…. All these do not hold good. Without communication you cannot achieve end results in any kind of development. It is proper application of agile which will prove otherwise. My reason for non adaption for agile by outsourcing companies is lack of trust and lack of understanding. To understand this we need to check the conflict of interests for customer and vendor. Developing in agile will result in these be...

Ant and Lion story: I am not the creator of this story. I got this as an e-mail forward. There are many things I can relate to with respect to process inclusion in organizations. Before I blabber a lot let me write the story. There is a link to the story in slide share. Ant and Lion fable Lion was the king of jungle. There was an ant in the jungle which arrives to the work early everyday. It will start the work immediately. Ant will do the work without any supervision. Ant was also happy with the end results of her work. Lion observed this and started wondering if the ant can do so much work without supervision how much it will be able to accomplish with a supervisor? Lion hired a cockroach who claimed to be a good supervisor. Also cockroach was very good in preparing reports. Cockroach was working in a big organization. It decided to implement a attendance system with time. Cockroach also wanted a secretary to type his reports. He hired a spider to archive the documents and attend all...

Last Sunday morning I went to gym. After working out I came out to find one tire was punctured. Just out of the gym and with the macho spirit I replaced the tire. Then reached home some 15 minutes late. My wife was waiting for me and she was angry. We are going to be late for the function we were attending. I started telling her all about punctured tire and how I replaced it. I was expecting some appreciation for my effort in replacing the tire. But all I got was “You could have called me? I could have picked you up and later we could have fixed your car.” This also happens in projects. We do lots of things for the customer. But if there is a small delay customer is upset. Same happens here. Missing item is communication. If you just mention to the customer we just added this feature. But it is breaking your main function. Customer may not be upset as much. But no communication and missing delivery will definitely upset the customer. Any gold plating will not smooth the rough edges. On...

Is refactoring code worth the effort? I know many project managers equate refactor with rework. They not even ready to hear this word. I will share one of my refactoring experience: I was working on a fixed price project. We were following some agile practices. But managers were not in favour of following complete agile. In their words you do whatever you want as long as it follows what I want. Still we had SCRUM meetings, SCRUM board, test driven development. Again no SPRINT planning. SPRINT was derived from the project plan and product owner was the business analyst. There were two pages which had price calculation. Over time lot of functionality was added to these two pages and they had started acting cranky. As usual commander had called a meeting and started to blast everyone in the visinity. During this process I uttered the word we will refactor the page. All the hell broke loose. Top manager (commander) and his deputy started to look at me like a intruder. Then after some t...

I had the opportunity (?) to be closely associated with a sinking project. This project was grossly underestimated by an aggressive manager and architect. Technology combination was unique and not a usual combination. A team was formed to execute the project. As usual aggressive manager put in a very tight schedule. Unfortunately team was not ready with required knowledge and team did not had the time to get normalized. First blow to the project was architect who had full knowledge of the application and was involved from the very beginning met an accident. At this time top management also realized there is an issue in the project and schedule will not be met. External people got involved with the project team. Initial recommendation was to scrap the code written till that point, change the design and embrace technology which is proven. This recommendation was shot down somewhere in the management labyrinth. More people got involved and things started getting worse and worse. ...

Agile manifesto tells Individuals and interactions over processes and tools . People often mistake this as no process in agile projects. Some agile practitioners (!) also believe this. They also miss first part of the manifesto Individuals and interactions. Wikipedia defines process as "Act of taking something through an established and usually routine set of procedures or steps". There is value in process and Agile projects also need process. What agile tells is process should not undermine Individuals and interactions. It is people who create software. They need interaction to understand what is required to be developed. Any team needs some time for forming. Till team is normalized it is better to take help of a process. Take precaution not to force a process on to the team. Team should form their own process. Let the team decide a time for the stand up meeting. Let the team decide the iteration duration along with the customer. Team should decide  Once this process is defi...

In general many projects fail because information is not properly distributed among team members. Customer's intent is not known to the team. This is a major project killer. Everyone agrees it is good for project team to know all the information about their work. But practically it is not the case. Why does information is blocked? There can be multiple reasons for this. Way to hell is paved with good intentions? 1. Work more efficiently: Lean theories explain this in a very nice way. Many times product owners start to think making everyone work is more important than completing the sprint. It is myopic vision but people to succumb to it many time. Who is ready to contest the theory 1 + 1 = 2. So if a person is idle for a day then that effort is wasted. Why waste time with a team meeting discussing the sprint. People will spend time on items which they are not going to work. Isn't it waste of time? But this results in rework. As lean ideas tell concentrate on the goal. What is d...

W e were having a two-week sprint. We calculate the capacity of the team and reduce a factor based on previous sprint data. Then we come up with a capacity number based on which we plan. This should work fine. But we always had an end of sprint rush. Everyone will be working hard to complete the commitment. Last two days of the sprint is hectic with fixing bugs. Last minute fixes too require testing the full story. There is a high chance something slipping through the eyes. Even otherwise it should not be like this. We had the capacity and still some struggle to meet the sprint commitments. What is going wrong here? It is the bugs eating your capacity. When a developer completes a task it is handed over to the QA. Developer moves on to another item. This is normal scenario. Qa may not get onto testing the item immediately. It might be picked after a day. If the task is complete and works perfectly no issues. But if there is a bug then it is different dynamics. Turnaround of the task is...

What is cycle time: It is time needed to complete a function/task from start to finish. If some one tells you "you can complete the feature faster by writing unit tests" what will be your reaction. Probably you won't agree to it. It is counter intuitive for someone not initiated into TDD. How come writing more code, reduces total time for development? Let me start with the cycle of TDD. Write a test first. It will/should fail since there is no code which will make it work. Write code to make the test pass.  Refactor to make the code readable. Repeat the process till you complete the feature.  If you have observed a brick layer laying bricks. He will put little cement. Then he will lay the brick. Then he will adjust the brick to make sure it is laid right. This process is repeated till the wall is complete.  If you take the parallel to software development then you should make sure each line performs as it is intended in the overall feature. As a brick layer will not put a...

Why do you people buy noise cancelling headphones to use it in office? Simple answer will be to get work done. It is a polite way of saying do not disturb. You are hanging a virtual DO NOT DISTURB sign for all people in office who want to disturb you. It is like marking territory by hunting animals. Moment you put on a headset you have an invisible shield protecting you from all the distraction.   How did we end up in this mess? Agile was supposed to be savior of software development.  " Individuals and interactions  over processes and tools" I think we are overdoing the interactions part of this. When manifesto stated interactions in was in a context. That context was for the scope of the product being developed. Probably at that time it was right because people were assigned cubicles. New generation of software programmers may not be able to visualize this. These people had work space which had good isolation from others. There was no instant messaging. If you wa...