Know agile. Not habit. (जानामि Agile न च मे प्रवृत्तिः)

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

My last blog was about process in Agile project. Yes we need process which is agreed by the team. Similarly we need a plan which is agreed by the team. Do not confuse plan to a Gnatt chart or WBS structure with dates against each item (using a tool) . This kind of planning will not work in agile project (Probably in other areas where creative work is involved). SCRUM approach has a planning meeting called Sprint planning. This meeting involves the team members and items which are part of Sprint is decided in this meeting. Team commits to deliver these items by the end of Sprint. Be it 2, 4 or 6 weeks. Once Sprint is completed have a plan for next cycle. Sprint planning involves all the stake holders. Product owner and team. Without these two parties plan will not work. How the planning is done. Product owner does the prioritization of the tasks (items) to be completed. Ideally tasks which have high returns are taken on priority. Then the team discuss which items can be taken during the...

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

All hotels have a reception area. Most companies have a reception area. But most homes don't have one. Why? Because we don't need a reception at home. Then why do we build features which are not necessary in an application?  Below is the standish survey for state software projects. Even though this survey was done in 2002 this is still a good representation of feature usage. Most of the time this happens when a fixed price contract is given to a vendor. I have first hand experience in developing some features which I was sure will not be used anytime in the life span of the application. To give an example: Most applications have a master data maintenance section. This is to be used by system's owner or administrator. People spend enormous amount of time developing this. Out these master data administrator might use them once or twice to make some tweaks. Otherwise this data is pretty static. Why spend time on a feature which is not going to b...

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

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

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