Friday, August 1, 2014

What kind of Software Development team you have got?

In IT world, if the most debated topic is anything, it's about why projects fail? There is for sure more failures than successes. Many successes which are there, at times are forced successes on end users. The end users are provided with no alternatives, and they are convinced or threatened to use the product, the way they are, the way they work.
Why projects fail? Very difficult to answer because there are so many things involved in it. Unfortunately, with software projects, it's difficult to visualise them and it makes the threshold to understand much higher. If we build a building, it's easy to visualise, as you can see bricks getting laid and the height gaining with time. It's easy to spot that it's going straight up and not becoming the
Leaning Tower of Pisa.
One of the major elements that I feel is important is the nature of IT teams and, which decide whether we are going to taste success or failure. It's the focus of the team. Fundamentally, it seems there are three primary focus that drives any team. The focus are:
  • Delivery focus
  • Technology focus
  • Feature focus
Let's assume the team is given the task of making Pizza. Pizza making is easier then software in terms of ability to identify in early stage itself, whether the Pizza is going to be good or not. The steps can be closely watched, before making more investments. If the dough has not come good, we stop right there. Let me also say that, making a good Pizza is still a very skillful art. So coming back to our IT team, let's understand how each team is going to approach it.
Delivery Focus
The delivery focus teams are fully driven by dates and deadlines. They will deliver on the given date and time, but the problem is what they deliver is most of the time is not in synch with what was intended to be delivered. The way the delivery focus people would read the requirement of Pizza would be as follows:
  • Pizza contains a thick dough layer on the bottom and lots of vegetables and sauce and cheese is spread over it.
The requirement engineering would decide that whether the types and quantity of vegetable and other toppings is detailed out to finest details or left to the discretion of the developer. Let's not get into that, as it will be another set of discussion.
We will focus on our guys, trying to deliver the Pizza. OK, so the team gears up to deliver the Pizza. A typical approach is to first calculate how much time the Pizza is going to take. So someone comes with Work breakdown structure. The work breakdown structure looks like
  • Making dough of base
  • Cutting vegetables
  • Getting sauce and cheese
  • Baking
A over enthusiastic manager might dissect and bisect these steps to a more details steps and steplets. So we have four major task. Four modules are created and four teams are assembled. A critical path network is defined where baking can take place after the dough is ready. I think this mentality of dividing the work in this fashion is taken from the humans rich and successful experience with the Industrial revolution. We try to apply the concept of Adam Smith's "Division of Labour" everywhere.
Now the team get on to the job. The team starts cranking things. To make sure that the integration happens properly, the diameter of the pizza is decided upon and everyone goes on to their task of building things around that diameter.The fun starts here. The team responsible for baking keeps waiting as they cannot do anything before the dough comes up. Meanwhile the best they do is to work out the oven so that the dough can be fit in to bake. As usual things start slipping up. The dough guys kept contemplating on how to make a dough and try all kind of flours. They get trainings done on various aspects of dough at the expense of burning the currency and hours. Th,e vegetable team cruises easily and they slice and dice vegetables. Still left with currency and hours they slice and dice more vegetables and keep doing that. The panic starts setting into the management as the dough team starts falling behind. The people of vegetable teams are now shifted into the dough team. Also the sauce and cheese team procured the stuff and then procured more and then again procured more till they are also shifted into the dough team. The baking team seeing the urgency of things building on their side decided to reduce the risk. So they started heating vegetables and cheese and sauce and started storing them so that when the dough comes, that's the only thing remaining to do. With so many people on the dough, it becomes a chaos. Luckily one of the guy from the sauce team was knowing about doughs and he helped the dough team to get the things done. It's another fact, that the guy was yelling in the beginning to be put in dough team, but he was placed in the sauce team. He being a new employee, and dough team was considered the critical part of system, the management wanted to rely on the old hands. So finally dough is done, and one of the guys from the Vegetable team walks away with the credit because he focused himself in updating the Management that the dough is coming up now. Finally the dough lands up at the baking team laps. By that time they have heated all the vegetables and the cheese and it has turned cold also. Now it's time to put the dough in the oven. However they realizes that the dough size just fits into the oven tray and no margin on the sides. The size of the dough is reduced and then put inside. Someone noticed that they have to deliver it in next 10 minutes, so the dough has to be baked in 5 minutes and topping and shipping done in next 5 minutes. A quick calculation yielded that the normal time is half an hour, so the over heating was set at 6 times higher. The dough pulled out after 5 minutes. There is no time for testing, to check how it tastes. And no one wants to test, as this will make the bugs to show on the top and no one has time to fix them now. Delivery is all that is important now. The vegetables and cheese and sauce are haphazardly put on the top of burned dough. The packaging team walks in, wraps it in nice packet and ships it off. God save the customer.
The delivery teams thrive on the notion that it is cheaper to say Sorry later on. The delivery focused teams are highly prevalent in the services company. In fact, they live and die around delivery dates. The patience levels are very low here.
Technology Focus
So before even learning about that the team has to make pizza, the team is already researching about the new breed of seedless tomatoes, that are successfully grown in the fields of Pithoragarh. There is usually someone at the top in such teams, who has focus towards delivery and understands that finally the currency has to be earned to pay the bills. So he goes to the team, where most of the people are busy with their latest gadgets. He stands in the middle and speaks loudly to get the attention of everyone.
"Hey guys, we need to deliver a Pizza."
It requires him to repeat the things couple of time before he gets the attention of everyone. And he walks away after handing a piece of paper to the team with the specification of the Pizza laid out. Soon the paper is divided into pieces and each piece being taken by individuals having interest in that area. No one talks to each other and everyone goes back in their corners.

The dough guy researches all kind of dough and finally comes with the exact recipe of building the best dough ever build in the history of human. He then goes ahead and bakes it also. The vegetable guy, gets the seedless tomatoes and the best of vegetables and sliced and diced them to the perfect precisions. The same story is repeated with the guys working with sauces and cheese. When everyone finishes the task, they put the thing in the center table and continue with their own work. The Pizza ingredients remain on the table. The guy with delivery focus walks in at the time of delivery and does not notices the Pizza pieces on table. He again calls everyone in the center and inquires about the Pizza. Each of the guy points to their respective work and also defends why it's the best thing that it was ever done in that field.
The technology focus companies are prevalent in start ups and the successful of them tend to become Feature focused in the future.
Feature Focused
Feature focused team are usually low on technologies and usually do not have a great sense of delivery. The team believes in more and more features, it does not matter whether they are useful or not. These traits can be seen in successful product companies, who are there in market for a while with a successful product. These teams usually start with a heavy technology focus in the beginning and able to survive by delivering something which is adopted in the market. Slowly the environment starts becoming dull and boring in these setups and the initial set of people are replaced with individuals who develop a strong notion of risk aversion with time. Also the technology starts falling behind as no one wants to upgrade and change for something that is working. Also the technology is further wrapped in utilities and tools developed in house, which makes the things much more easier for developers and promote more and more people to get into lazy and risk aversion mode. Also these companies tend to be very good paymasters, so you will find some of the very bright individuals in this environment and getting stuck into it. They soon loose their marketability being not in touch with the latest.
How this team will make a Pizza? So first they will run a lot of surveys and questionnaires to try to understand what Pizza the market wants. Usually for them a customer is a faceless person, who is typecast. They don't care about actual customers because they the customers are in any case invested in them and have no option to go anywhere. Also the surveys are done in such a way that it yields results, which are already decided. You can talk to any statistician to figure out how it is.
If the release cycle of the product is 4 months, then the team keeps discussing about the new features that needs to be added, for 3 months. The list keeps getting longer and developers keep waiting for the actual code to start on. Finally the team decides which features need to go, which is a long list. This list has no relation to what was surveyed and basically created in the corner offices of Product manager, who sits on the other end of the world from their customers. These are self styled product managers who carry an aura with them that they know all about the product. You dig them a little deep, and many of them fall flat. So finally the list goes to developers and the developers hit back saying that the time is not sufficient to develop everything. A round of negotiation happens for next 15 days and the result is a shifting of release date by 2 months and a trimmed list. The features that finally get are primarily more complex UI interactions in the name of usability. Product companies do more usability projects in disguise than any other teams, and still they make it more complex. Finally the product is released with big fan fare and cock tail parties. The customers usually do not have choice as they are fully invested on the product. They even do not need to migrate to latest versions but the licensing models force them to do. The customer still crave for that original taste which gets more and more layered with time.
End Note
Let me start the end note by saying that the above discussion might have painted a grim picture, but it is also true that there are many good individuals and systems which are successful. One of the primary reason for their success is the awareness to focus on delivery, technology and features at right levels. All said and done, we have a good number of success stories around and as the maturity of industry grows, hopefully we will see more successes. We rarely hear of construction industry failures for technical reasons. They might fail for financial reasons which is important but a completely different dimension. Hopefully one day we will see the same in IT industry also. The three focuses are like three legs of a stool and each one of them is required to make the stool to stand.

No comments:

Post a Comment