Non-Commitment, the new (or rather old?) Management Disease

Non-Commitment!

These days, I hear / feel / see this disease that seems to have plagued management of my organization.

Just to elaborate the point, Lets take a few examples… (of course the names are indicative and not real)

1. Rajesh is in a new responsibility of handling a few freshers below him. He has a few years of experience. At the start of development of new project, he is been consulted about the dates and plans. But, as it always turns out, there were requirement gaps and whole new additional functionality clarifications comes later in the project increasing his workload. Since, Rajesh has already committed on the delivery date to his seniors, he, along with his team, even-though-grudgingly, toiled through the weeks till the delivery to provide a feature complete module
2. Many people join the offshore IT services organization like mine in hope of going to another country (and possibly earn some extra money). Nameet was no exception. He was a brilliant programmer and a highly team-person, the one who gets gelled into the team nicely. But, to his misfortune, for all the commitments he made for completion and quality the work, he never got any commitments from the organization about his career progress. All he got was promises. There was no one (senior) who stood on the promises which were made. [All the years of staying the organization had also taught the seniors to not promise anything in writing!] … Well, outcome was obvious, my organization lost a good programmer and team person.
3. Sanjay, being in the organization for quite some time, had learnt a thing or two about how management works. He wanted a transfer and he started the process of talking to seniors around 3 month prior to when he really desired to get transfer. [Update: There is slang term for this, CYA.. go look yourself up if you do not know what that means]. When he was asked to work on some proposals, he committed for the work and did not care if that meant staying up till 3AM every other day for 15 days. But seniors, despite 3 months lead time, were not ready to provide any commitment on transfer for Sanjay. Neither was any response (positive or negative) provided in written communication. So much for soft-skills training that my organization mandates to everyone.
4. Everyone has likes and dislikes about jobs. Hari did not like maintenance work. He, being the bright and self-confident person, wants something bleeding edge. So when he was moved into maintenance project with low activity, he asked for change of project. Seniors, agreed after series of “discussions” but did not provide any commitments on when it will happen.

As I am trying to highlight, all these incidents involve different teams and different people but the theme is unmistakable. Juniors, are been asked for commitments and are providing commitment and are living upto it, even if that means lot of hard work and weekends, nights lost. But seniors, when it comes to reciprocating the deal, are consistently evading it!

I would venture to say, that a leader should provide a clear indications to his/her subordinates, about the responsibilities and time-lines to complete them. But he/she should not evade his/her own responsibility to provide clear time-lines / risk mitigation when it comes to fulfilling the subordinates aspirations. At the same time both need to attack their responsibilities with transparency to other party to boost the confidence!

I can clearly see few big benefits by not evading responsibilities:

1. Juniors are not in dark about when things will happen and if they do not happen, what are their options.
2. Seniors would be more esteemed personalities in their juniors eyes. At least, they would not be back biting A**holes.
3. Overall team spirit goes high when Seniors and Juniors join hands and transparently act on issues.

Pains of software project endgame

In last 5 years of Software development, I have always seen that almost invariably, the endgame of the project is the one which pains the most. Here are few of the things that I have been observing which went wrong in the project.

• Long Project lifecycle – Project life-cycle is too long. Its a already 4 months just the build (post design). This is taking toll on the team since the team is tired of looking at the same code and keep tweaking it.
• Perpetual Requirement changes – The long life-cycle of build phase has allowed customer to have sufficient time to see what was wrong in the current requirements. He is anxious to provide the updates to requirement so that its more useful. He would love to see the changes incorporated in the current build cycle itself. On the contrary, developers (and the manager/tech lead as well) are wary of any such changes since such changes often are not thought through and create more instability than value-add.
• Incremental resource loading – Addition of people in phases does hell lot bad to the project. (We added 3 people in the project almost one month after initial increment of 3 people was done). If you want the team to deliver the best, get everyone on the board at the start (need not be at the start of requirement) but at least at the start of design.
• Why one time resource loading? – For the initial team, inclusive of existing and the new, we had had a very detailed (almost like 15 sessions) walkthrough the requirements and the initial application framework design. It also gave chance to everyone (both new and experienced) to play around the app design to get the feel of it and press out any issues in the design. It also jelled that part of the team pretty good. Come one month down the line 3 new people, everyone is head over heals into their own functionality design and development, no-one is really paying attention to get these 3 people going. So ultimately these 3 people lose out on the great experience of playing with the framework. They also do not get basic requirement contexts as no-one has chit-chatted the requirements with them.
• Biggest failure of incremental resource loading – I did not realize it then, but it was extremely advantageous to the project that I returned from onsite for the design phase. I could relate the offshore team with the requirements in a better fashion since I took the requirements hands-on and had a business context of the complete requirement. I was knowing the answer to eternal ‘WHY’ of many many smallest requirements. I was knowing the background of any particular requirement as to why the requirement so. But to the new 3 people, there was no time for sharing these tidbits of the requirements. Lesson: Get whoever you want at the start and give them a ground up.
• Automation – Unit Testing – Despite my being supportive of it, I failed to make customer believe in advantages gained out of automated testing. We failed by telling the customers that it would take 1/3 the time of total build effort to create and maintain testcases for the application. It was probably a decent estimate of the effort, but what it hides is confidence that can be built due to the automated testing combined with continuous integration process. No customer would say yes to such addition to the project effort (and money) unless he/she sees the advantages that are gained out of it. How I wish, I should have had detailed discussion with my customer to buy his confidence then.
• Automation – Web Application Testing – Since Unit Testing provides you with just that – ‘a unit’ test, we need something which will smoke test the application end-to-end lets say, every 2 hours. This would have created a hell lot confidence in the working of my application. There are many tools which can help here. Commercial as well as free / open source. Rational Function Tester is a promising tool. So is open source tools like Sahi, Selenium and Canoo Webtest. As unfortunate as it is, I seem have not vested time in any one if it anytime. I must do that to find out which one is better than the rest and then make my customer and team use it.
• Lack of coherent requirement documentation – With a big showoff inside the company and also at customer location, we created multitudinous requirement artifacts viz. a usecase document, a ppt showing the part-by-part details of the screen and its possible changes in various flows, minutes of meeting with customer as well as with other application teams, and a mind blowing application look-a-like html clickable mockup. Amazing huh? I am still impressed with my own creation. But with so many artifacts, am now stuck with non-searchable subversion repository of all these artifacts. Now I feel the need of a wiki like structure which would be search-able, navigable, editable by everyone in the project (inclusive of customer!). It would have been so cool in the offshore scenario. Wiki would have kept the revision history, it would have just sufficed one single page for the things covered in usecase as well as things covered in ppt.
• Continuous Integration – Now that customer is changing the requirements frequently when he sees the application previews, I have started to see the correctness of points raised by Martin Fowler. He argues in favor of continuous integration that, if there had been automated testing and hourly build process setup, the team would have been so confident of the build that is been created that it wouldnt have bothered the team about changes in requirements. I admit, whenever I get a change in requirement, I wince and try to find out as many faults in the requirement. [Anyways, sometimes it necessary to do just that in order to get the complete requirement.]
• Agile Test Driven Development – The project with huge complexity like my current project, it would have helped to create a smaller development cycles with smaller and incremental goals. The agile mantra would have been perfect: You build some, you test some and you show some to customer. Again here, even though I am sold to this idea a long long time ago, I failed to make it believable to both my customer and my company. We could have taken a smaller (but COMPLETE) set of goals in hand and implemented them. Based on the success of them, we could have put on additional features. But this did not go down really well with my company and my customers. I also did not press a lot.
• Archaic Technology – All the technology that we use in the current project is something that was published at least 4 years ago. So in order to add the cooler features of web2.0 world today, it takes lot of pain with those old technologies which were never created for such task. Next project I must ensure that I start off with the latest versions of best tools of the market today.

Phew thats a lot of junk I managed in one project! So, does that mean this project is basically a big failure? I am kind of undecided on it right now. I agree that we messed up on lot of stuff but I also see that we still have managed to pull it off so far! With all the gems that constitute my team, I am very proud of my team and has belief that we will pull it through.

Amen!
VJ