Archive for June, 2008

Building a Team in a Start-up – Tuckman’s Theory

June 28, 2008

Having worked with more than half-a-dozen start-ups now right from the early days, I have had the first-hand experience in seeing how critical the initial team formation step is. Not only the quality of the team mattered but also the timing associated with getting them together was critical too. Once the team gets in place, how soon the team ramps up with the mission and gets going is another hurdle the start-up/entrepreneur has to worry and cross.

Having seen it closely, many start-ups tend to miss out the after-effects of the Bruce Tuckman model of Group Evolution. Per Bruce Tuckman, any new team on a project typically goes through four stages of evolution before we see them performing as per the expectations set on them. These stages are inevitable and in some sense they are all necessary and happen in the same order.

  1. Stage I – Forming: The first few weeks are spent in this mode when the team comes together. They are in the process of understanding what needs to be done but typically tend to remain and behave in an individualistic manner. The initial personalities of the individuals come to the fore in this stage.
  2. Stage II – Storming: A slightly painful stage wherein individuals push forward their own ideas for consideration and tend to resist any group pressure.  Typically numerous conflicts arise at this stage because of different personalities, roles, and styles which can make things difficult for teams to work together. Depending on the maturity of the team, these stage can persist for weeks and months. Storming stage is however considered necessary for the growth of the team.
  3. Stage III – Norming: This is the stage where the teams start putting their individualistic thoughts aside and become more keen in finding solutions by agreeing on guidelines, behaviors, methods, etc. Teams start trusting each other. Signs of increased motivation are visible in the team.
  4. Stage IV – Performing: Again, depending on the maturity of the teams, only few teams would reach to this stage where the performance levels are optimal. Teams start functioning as a unit. They are focused on the common goal and work out decisions/conflicts using a more collaborative style.

Depending on the team size and complexity of the group structure, this evolution of group can take weeks and months. In my experience, only few of the start-ups can afford this and any mis-handling in these stages can be disasterous.

I have always believed that for most of the start-ups, the process of achieving their first goal is like playing in a limited-over cricket match. There is a limited quota of time; constrained number of resources; and steady influx of surprises/changes which they need to tackle. And I am talking about this from business perspective. In all this it is very tough for many start-ups to afford their team to go through the above stages. Imagine the eleven players – unknown to each other – going out to play a limited over cricket match and going through the stages above. This team cannot afford spending time in solving individual conflicts or formulating strategies or the game plan while they are on the pitch. The team needs to start scoring from pitch no. 1.

So if Tuckman’s theory is true and considering the limited options in front of the start-ups to afford what is described in this theory – what are the alternatives? Well, in a simple scenario if the start-ups can afford it, they should include this time as part of time-plan and cost. If not, there are other alternatives too.  I will talk about it in one of my future post.

Add to Technorati Favorites

Convincing others for Waterfall or Agile Methodology

June 27, 2008

A colleague of mine sent me this email today. He mentioned about the dilemma which one of his client was facing. I have pasted his email below (I have changed some of the names to respect the confidentiality)

Hi Manish,

I needed some help on projecting Agile as compared to water fall. PQR product is getting implemented at ABC and ABC’s project head Dorothy is facing some challenge in motivating her team to work in Agile way, especially when it comes to UAT. I think it’s becoming hard for her to convince that ABC’s users can continue part testing for features released in UAT. ABC’s user’s team is more comfortable doing QA when complete product is rolled out for UAT. This approach will hamper implementation dead line (before <Month> 08 end). She was looking from us some kind of presentation / stats which clearly explains benefits of Agile over Waterfall and give some stats (if possible) on failed big projects using waterfall and successful agile ones.

Can we get some stats / figures etc around this request?

Having been in similar situations in the past, I can certainly understand Dorothy’s challenge. While I did respond back to my colleague (please see below), I thought about posting this email as a blog post to see if any of the readers out there can help Dorothy with their experiences and metrics. Also, I am sure there would have been many in Dorothy’s shoes and wanted to find out what they did to overcome the challenge. Please feel free to add your experiences in the comments section below this post.

My response to my colleague –


Software industry is littered with examples where the software failures (by failure I mean that it was not able to meet end-users needs) have occurred. However, most of the time it is very difficult to say that the failure occurred because of waterfall or agile or any other similar methodology. IMO, failures are always because of certain risks which could not be mitigated at the proper time. This article at the link below shows a survey results which lists why project failures have occurred in the past. When you look at these risks, it is fair to say that Agile Methodology is better equipped to mitigate these risks as compared to Waterfall.

Coming to your point of metrics – I personally do not have the project failure/success metrics comparing Agile vs. Waterfall. I can certainly hypothetically speculate, however I do not think that is what Dorothy wants. If I can understand what she is trying to look for is to look for ways to mitigate the uncertainties associated with the implementation deadline. If she lists these risks down and plans to mitigate that, she will very clearly see and convince people that Agile is probably their best bet.

I am slightly going on a philosophical note here – unfortunately we engineers many a times fall into a debate of one vs. other – Agile vs. Waterfall, Java vs. .NET, and so on as if they were two religions. I think achieving the goals is important as compared to looking at the rewards associated with selecting one vs. the other.

While I do not have a ready presentation on Agile vs. Waterfall (there are plenty on internet though which you can point to though). However, I would be happy to show and explain how we (in GlobalLogic) do it in Agile if Dorothy is interested. Also, please do note that the way there is ‘bad waterfall’ there is ‘bad Agile’ also 😉



As I said in my email, the success and failures of a project are typically not because of a particular methodology – but how the methodology helps to manage and mitigate the risks associated with any projects. There are good and bad implementation of all the methodologies out there. In my experience, it is not in the best-health of the project to get into the debate of goodness of one approach vs. the others. We should leave it to the ‘academicial-minded‘ to do that. The key is to take the best of all the approaches which would mitigate all the risks associated with the project.

Add to Technorati Favorites

Design/Development in Waterfall/Agile

June 22, 2008

I came across this post written by Kevin Barnes on Agile Processes. A slightly old post and I am not sure what exactly Kevin was trying to convey in this post. However, there was one picture on the same post which caught my eyes and to which I could relate completely.

Design/Development in Waterfall/Agile

(src =

The picture nicely describes how the two processes are loaded with respect to the Product Design and actual Product Development. Whether it is intended or not, there is typically a lot of upfront design effort in Waterfall. Whereas the Design process is more emergent in Agile. As they say, more important in Agile is the working code.

Add to Technorati Favorites

Developer Productivity vs. Runtime Performance of Programming Languages

June 16, 2008

Although we have been playing around with it for more than year and half now, over the last few quarters my company (GlobalLogic) has invested heavily in and adapted the new generation development platforms like Ruby-on-Rails (RoR), Adobe AIR, etc. One might term it to be slightly slow in comparision with the industry adaption trend. However, our adaption was also driven by the needs of our clients. In the recent few quarters, we have suddenly observed that these platforms have now become main-stream. RoR/PHP is becoming a popular option in building the modern web apps whereas AIR seems to be the current ‘cool kid’ on the desktop side.

Adapting a development platform at the early stages of its evolution is always a challenging decision which an Engineering Head has to take for the product. I have always believed that adaption of any new technology is driven a lot by the herd mentality. Just because of the notion that many others are also using the platform, many a times the selection of a development platform becomes a blind decision. On the flip side, if a choice is about selecting a new platform – the same ‘herd’ mentality also comes in. The onus is more on the Head to prove his/her choice criteria rather than simply using the regular proven and established ones. Also, it is one thing to build up an experimental system using the new platform. However, the decision to adapt the same platform for engineering commercial products can be a hair-pulling one. Many a times in the end one has to finally depend on the two G’s – guts and gamble. Also the decision-maker will have to be continuously ready to answer questions associated with the hypothesis as and when any bad news associated with the platform (e.g. Twitter’s challenges attributed to RoR) or the product (e.g. initial breakdowns of the product) trickles in.

Because of the nature of the products we have been developing in my group, we felt that RoR was a very good platform choice for the same. So far (and I am knocking the wood here) our choice of the platform seems to have been validated based on the results we are seeing. It is amazing that how much dramatic productivity-related improvements these new platforms have made over the years as compared to some of the older generation-ones. I have myself observed this in my teams. Probably one of the big reason for this improvement is that these new platforms have started becoming very specific (e.g. web in the case of RoR) rather than the general purpose language platforms like C/C++, Java, etc. Dion Hinchcliffe in his posting “Creating Open Web APIs: Exploring REST and WOA in Rails 2.0” refers to productivity improvement numbers in the range of 10 to 20 times. Considering that programming time (or the development time) is the biggest cost of product development, the savings because of these improvements can be enormous. The built-in practices associated with Unit Testing, Agile, Reusability, etc. also seems to have aided in the aspects of building a more quality product.

Lately, the news about Twitter performance/uptime related challenges seem to have raised a lot of speculation on the run-time performance capabilities of RoR. While nothing has been proven as yet, such questions associated with newer platforms is enough to keep one awake in the night. Before jumping into RoR, I had in my mind that the run-time capabilities of these new frameworks would be weak in comparision with the compiled software platforms like Java, C++, etc. The above post by Dion has a good explanation about the same –

One is that the more popular, older programming languages tend to be relatively low level and general purpose and were designed for a different, older set of constraints. This has given us baggage that is often not very applicable to the modern Web-based world. Second, we’ve become very good at understanding the idioms and “syntactic sugar” that makes developers more productive for Web development and we’ve put that into the latest generation of programming languages and Web frameworks. Unfortunately, the combined newness of these new Web development platforms and their preference for coding time efficiency in favor of run-time efficiency has conspired to make the results they produce relatively slow and resource inefficient compared to what is potentially possible. Newness in this case is also a kind of performance tax since we just haven’t had enough time learning how to make these new platforms perform well at run-time, similar to early versions of Java before the advent of the Just-In-Time (JIT) compiler.

Based on the above and my experience until this stage – I am more comfortable in recommending these modern languages towards Consumer/B2B products as compared to telephony/banking transactional products. For the preferred products, many a times it seems like the advantages associated with improved developer productivity far over-weighs the slight runtime performance disadvantage these modern languages bring in.

Also my opinion is that it is too early to start comparing the modern development platforms with the older programming environments. Increased usage will drive the initiatives associated with the strategies targeted towards improving their weaknesses.

Thoughts, comments, and suggestions are welcome.

Add to Technorati Favorites

Product Engineering approach for Startups (4): Estimating time and cost for Engineering of Version 1.0 product?

June 11, 2008

[This is fourth in my series of blogs about Product Engineering Approach for Startups. In my previous blog, I had talked about why it is necessary to implement a Goals-Driven Planning Approach.]

My group – Version 1.0 in GlobalLogic reached a very important milestone this week. Using an unique business and engagement approach, we successfully rolled out a Version 1.0 of one of our first client in the group. This was done in-time and within-budget with all the quality requirements which we had agreed with our client. Two more products are in its way to be completed within the same parameters in the next few months.

I would not like to claim that we were the first to finish a project on-time or within a fixed budget. However the unique thing about this achievement was the approach and methodology we took to reach to this stage – especially when we had to consider the driving forces behind rolling out first version of a product. (fixed time to go-to-market, changing or evolving requirements, and most important a fixed budget)

We are currently engaging with more than 8-10 organizations who are keen in seeking our help in soup-to-nuts aspects of engineering and rolling out their product to its Beta. While each of these organizations bring in an unique vision and passion associated with their products, there was one thing which was common in almost all of them. Almost all of them – in our first meeting with them – were keen in knowing a ball-park number associated with how much time it was going to take to build their product and how much was that going to cost them. We had to tell most of them that in software world there was probably no formula or a calculator which existed which could easily tell them that. Well, unfortunately, at least we did not have one!

Having said the above, we also do realize it was also important for such product entrepreneurs to get a feel of the time/cost numbers before they jumped into their mission. So to all of them we typically have been suggesting the following thumb-rules.

  • Regarding time required to build a Version 1.0 = This, IMO, for a product at an inception stage should be same as when the product should be taken to the market. So time estimates to build the product should be the same as the product’s pre-determined go-to-market date/s.
  • Assume that it would always take x amount of time for one person to build up a product feature. Increasing the number of people does not reduce the time. So for example in 98% of the scenarios, it is not possible to reduce the time to build a feature to half if you have twice the number of people working on it. This is a very important aspect to be considered in software engineering.
  • It is a risky proposition to build the first version of the product on a fixed cost; it should be always built on a fixed budget. So the best possible answer associated with how would it cost to build a Version 1.0 of the product is typically best answered by the entrepreneur themselves.
  • You can assume fixed regular cost associated with the raw materials required to build a software (intellectual property, human services cost, hardwares, softwares, etc.)
  • Only variable which remains is the product scope which the product entrepreneur wants to be part of the Version 1.0 release. This is an important variable which the product entrepreneur can use to optimize time and cost associated with Version 1.0

Hope the above thumb rules helps in some manner with the estimations. As Sachin puts it very nicely – “There are two things any product entrepreneur has in abundance – vision and passion. There are two things which he/she does not have in abundance – time and money.” Keep that in mind while doing your estimations.

Thoughts and comments are most welcome.

Add to Technorati Favorites

The Greatest Manhunt of World War II

June 1, 2008

Slate is carrying a very interesting photo essay on one Herman Perry – who was an African American World War II Soldier and became a fugitive after shooting down one of his white commanding officer. This essay titled as “The Greatest Manhunt of World War II” is based on a book – “Now the Hell will Start” written by Brendan I. Koerner. Herman Perry was positioned in Burma to build a road connecting from Assam in India to borders of China through Burma. After he shot one of his officer, he escaped into the jungles of Assam and took shelter with the Naga tribes. He infact became one of them and lived with them for many years (married the daughter of the head of the tribe) until he was caught.

The essay describes how much active US forces were on the Indian soil during the World War II. How many lives just get lost just to follow some fancies of the superiors. It is also so amazing that such unique historical stories can get so easily lost.

Add to Technorati Favorites

Fascinating African Wild Dogs

June 1, 2008

African Wild Dog at Bronx Zoo.Image via WikipediaAlthough I have never seen them in the wild and I have never touched the African continent as yet, I have always been fascinated by the African Wild Dogs (biological name: Lycaon pictus) (wikipedia link) whenever I have heard or read about them. Although they may not give the most soothing view to the eyes, may not be majestic, and have plenty of ill-founded myths going against them, there are many amazing things about them. IMO, some of them can be translated into some real practices in our real life especially in Software Project Management. But more about that in some future posts.

Follow the link to the wikipedia to read more about these African dogs. Quite different from many of their other cousins – these dogs live in packs in wilderness, are hunters by nature, and come very close to modern dogs. All types of wolves also fall in this category. Also, with whatever I have read about Australian Dingos, they also come close to the African dogs. However there are certain characteristics that are still unique to the African Dogs.

Some of the things which are certainly fascinating about these African dogs –

  • Ability of each of the dog to live and survive in a pack while maintaining a unique role for themselves.
  • Understanding the roles and strengths/limitations of others in the pack. These animals play to other’s strengths and complement wherever required for other’s weaknesses. For example, their ability to regurgitate to feed other pack members such as the sick, injured or very old is certainly unique.
  • They do not seem to be instinctive hunters as many other wild animals. They have evolved their hunting tactics with learnings over the years.
  • They have the highest success rate in their hunt missions probably because of the attribute mentioned in the above bullet point. More than 75-80% of their hunts translate into successful kills. Compare that with the big cats like lions whose success rate is less than 50%.
  • Cursorial hunting ability – ability to run long distance to get their hunt.
  • Recursive divide and capture style of hunting – ability to continuously break and capture their target hunt to maximize their success rate in their hunt.

Take some time to read more about this beautiful animal by googling around on the internet. It is sad that this intelligent specie is on an endangered list now. By the latest what I have read, less than 5000 of them are remaining. With a mortality rate of more than 50% and life expectancy of around 10 years only, that surviving count is not that much.

Add to Technorati Favorites