Agile Debates: On Distributed Development, Talent And Metrics & Measurements

I attended the 2011 NCR Agile conference a few weeks ago. This was the second such Agile conference I was attending within an year's time and what brought me back weren't the speakers or the interactive sessions alone. It was largely the debate & discussions on different ways of getting software done right and the networking sessions where you could actually discuss potential challenges & issues on your software development techniques with others in the practicing community.

There was one such discussion I got into with one of the speakers at the conference that was to do with distributed software development. In my 8 years at Tata Consultancy Services, I had mostly worked on a distributed offshore/onsite or a multi-shore model but always using the traditional waterfall method. In my 2 years at a product startup, we used agile and always worked out of the same floor and so we never had to face the challenges of distributed agile or scrum. However, from my TCS days, I recalled that the biggest challenges we had were to do with communicating enough, communicating correctly and ensuring enough visibility for all teams across locations. And we used different techniques to make this work. For starters, we tried to enforce an onsite/offshore rotation policy so that everyone on the team is acquainted with one another as much as possible. We also tried ensuring that all victories even the small ones are celebrated and that any sincere effort never went unnoticed. However, most importantly, what really made distributed software development successful were our onsite & offshore coordinators. These 2 people could make or break the projects and in no uncertain terms were their jobs the 8-hour-a-day type. These were almost cross-functional specialists in a sense and their skill-sets spanned across ensuring operational excellence and managing client relationships and team members. I found the ones who were more good with people to be much more successful than the ones who were simple more good technically. The gentlemen I were discussing this with didn't take it too kindly. For one they were both these coordinators on a not-so-successful distributed scrum project and they were both technical leads on the project. However, more importantly, they didn't think that specialists such as people managers or project coordinators had any place on teams practicing Agile software development where the emphasis was on everyone doing everything.

I could actually relate this to 2 other speakers at the conference where while one mentioned that one of the dangers of agile was that everyone seemed to be focusing on generalists and trivializing the importance of specialists and the other mentioned that agile is simply another process of getting software done and that the process is irrelevant given that it was the outcome that eventually mattered.

The other debate I got into was to do with if developers in product companies were better at their jobs than those at service companies. This is largely true at least from what I have observed. However, the real question  to ask is if product companies are as effective as service companies. I know a zillion more failed product companies than I do service companies. If we are really smarter than our counterparts in service companies, then we should be doing much better than them at making profits. I know that this could be an apple-to-oranges comparison and that the balance sheet isn't everything but the cash reserve our top 5 India-based service companies have could put some of the most famous global product companies to shame.

There was yet another interesting discussion on metrics and measure of performance of projects doing agile. For one, collecting even simple metrics takes effort and given that the real value is in the delivery of software, should one be spending time on data collection at all? I believe that it is worth the time and that it is also best kept simple and easy to measure. They have many advantages: they help us know where we are, on what we can make further continuous improvements and help promote this transition.

This has been a long post. At the end of it all, I just want to say that continuous improvement is at the core of all this and that the process isn't everything. The process is just an enabler and we should just keep it that way. From that perspective perhaps the philosophies across most software development methodologies aren't that different after all. Its just that some have more boxes and arrows on their diagrams than the others.

On Alliances

The traditional definition of an alliance has been the following: the pooling of resources and effort across multiple entities with the objective to achieve a competitive advantage in the marketplace. However, the ability of an alliance goes much beyond that. It is to do more with the the creation and the integration of new competencies out of the already existing stocks of prior competencies held by the organizations in question.

You could forge an alliance for a variety of reasons such as for marketing, R&D, technology. design and more popularly to create distribution channels. If one looks purely at brands and marketing, forging alliances have become critical because of changing trends. There are technological changes taking place at a rapid place with increasing globalization and constantly evolving consumer needs. In today's era of globalization, partnership with local firms to distribute and sell products under the local brand name achieves gaining a foothold in the market. In the case of evolving consumer needs, an important part of marketing then becomes identifying new consumer trends and the creation of products. Partnering therefore can not only reduce time to market but also make up for the lack of innovation focus within the company.

The most commonly cited example on alliances in classroom and various case studies is that between Microsoft, Intel IBM and Apple. When the PC industry began, competition existed between Apple and the IBM-Microsoft standard. IBM created and set out an open architecture standard that allowed any other computer manufacturer to build a clone of the IBM 'PC' itself and other software manufactures to deploy software to the IBM platform. This marginalized the Macintosh platform completely and the IBM PC became the de-facto standard. However, IBM and Microsoft fell into a dispute on operating system adoption where IBM was more interested in pushing OS/2 while Microsoft wanted to launch Windows. Microsoft then formed an alliance with Intel and launched Windows. Other PC manufacturers adopted this making Wintel the dominant standard thereby marginalizing IBM completely. IBM's open standard actually then worked against IBM's favor. IBM then went into an agreement with Apple to develop its new line of chip architectural design. Eventually, Apple realized that IBM support for it wasn't as good as they would have like it to be and adopted an Intel standard. The eventual implications of this are actually yet to be seen. It may be that the Mactel standards will be more aggressively pushed out by Intel in an attempt to marginalize the Wintel standard!

Alliances are about increasing the size of the pie rather than increasing one's share in the existing pie itself but they are not without challenges. What gets in the way more often than usual in establishing successful partnerships is to do with overcoming the 'proprietary mindset'. Partnerships require one to be willing to give something in order to get something and that requires a more 'collaborative mindset' than anything else. Also over 50% of all alliances have been failures. However, the average Fortune 100 company has over 60 alliances and given that these are Fortune 500 companies that we speak of, they must be doing something right.

SMEs and SaaS

Everyone is talking about the Small and Medium Enterprise (SME) and the Software as a Service (SaaS) space today. But is there enough understanding on what IT means for the SMEs and more importantly, if the market is really that huge, then why aren’t we seeing enough SaaS adoption in this space already?

For consistency’s sake, we need to define what a SME in India is given that there is no legal definition in the country to this yet. Let’s assume this to be an entity that has a turnover of under 1 billion (100 crores) INR. SMEs then by this definition contribute in terms of value to over 50% of the county’s total exports and account for over 95% of industrial units.  Secondly, they are growing in leaps and bounds across all sectors and have been instrumental to India’s growth story. Conservative estimates have put annual growth in the SME space at over 20% across all sectors for the last 2 years.

To serve this space means to play the volumes game. The typical client will require about 11-15 licenses of the software in question. Next, the SME requires a complete pay-as-you- go model with minimal upfront investment, minimal installation time, minimal training and a solution that is completely outsourced and managed by the software provider.  They don’t want the overhead of managing an IT department. Additionally the software should be able to integrate with third party customer software as required and data migration (both in-out and out-in) should be extremely simple.

Not enough IT players understand the SMB sector completely and therefore this also makes this an underserved market.  This is mainly because most players today don’t have a SME version of their software. Their version of software is the enterprise type that is traditionally heavyweight, expensive with large upfront fees and requires a try-to-implement-forever approach.  Also what is lacking is the SME’s ability to prioritize & understand what IT can do to facilitate their growth.  Therefore there is some amount of educating required in this space.

Of Contact Centers and CRM Evolution

A contact center’s objective is to combine all customer communications to provide a consistent and complete customer experience. Irrespective of the channel that the customer chooses to pursue: whether it is via a website or a discussion forum, a chat message, a short message service (SMS) or even a telephone call, the agent needs to be empowered to experience the customer request.

The contact center today is not there with this yet and will therefore have to develop multichannel capabilities that will need to be delivered as a standard feature and not as a complex customization. Online communities support need to proliferate. Blogs, discussion boards, social networking (with special emphasis on feedback management), wikis and collaboration tools to enable customer self service. And knowledge solutions, real-time analytics and decision support to enable the agent better serve the customer.  Customer data integration is an important requirement here that will enable a 360 degree view of the customer and her/his experiences.

Lets take a look at what technology, a contact center needs. A contact center has essentially the following components to it and some of them can be rather tightly coupled with the others.

   1. The Customer Interaction Management (CIM) suite of business applications that will manage the customer interaction process. Some amount of Business Process Management (BPM) will have to be inbuilt into the CRM for workflow management.
   2. Contact Center infrastructure, not restricted to Interactive Voice Response (IVR) systems, Computer Telephony Integration (CTI), SMS and Payment gateways alone.
   3. Optimization tools for the Contact Center such as call recording solutions, back-office software, training and quality assurance tools.
   4. Analytics tools to gather business intelligence and customer insight.

CRM applications are increasingly becoming more complex. Automated proactive alerts, BPM and integration support for multiple interfaces are now becoming standard features. While most CRMs today are primarily being used for handling service requests and as knowledge-base solutions, social networking support and predictive analytics are fast catching up.

Though it is a well known fact that any hosted CRM needs to have some sort of SaaS support for it to be successful, pure-play SaaS-based CRMs still have a long way to go before they can start dominating the CRM market. Today, Salesforce CRM is available only as SaaS. Microsoft Dynamics has now gone online and offers a cloud version as well. However, SaaS based CRMs have historically worked great for low-volume and simple contact centers and therefore there is a dying need for SaaS CRMs to have more complex and customizable features.

A paradigm shift is therefore waiting to happen with SaaS based CRM solutions. Gone are the days when the contact center was only about blended solutions, simple CRMs that primarily handled service requests, and IVRs. The market is out there and the future is waiting. After all, the objective of a good Contact Center is always to enhance the customer experience, isn’t it?

Why Do Indian Tech Product Companies Struggle?

This was in the news last week: technology product companies are coming of age in India. I was just wondering, we have been a software services powerhouse for quite some time and Bangalore is even known as India’s Silicon Valley. Hell, I even worked in one of the World’s largest software services company for almost 8 years. But how come, we don’t have a lot of technology product companies that are famous enough to be recognized worldwide? I then took up a stab at this and came up with the following:

The first and most obvious answer has to do with talent. While we have some of the best and brightest engineers all right, most of them would rather work at a large software services provider than work at a small unknown product startup. As if hiring wasn’t difficult enough already, the typical Indian mentality is to progress up to a non-technical path very quickly. After all, if I as a software programmer ever told my to-be in-laws that 10 years into my job, I am still into software programming and working for an unknown product startup, then it would simply be a matter of shock to them.  After all wasn’t I good enough to become an account manager or delivery manager at a TCS, Infosys or Wipro by then, or at least a project manager at one of these companies perhaps?

Having experienced and great software programmers in your technology product company is extremely critical to building good products. While not everyone has to be a superstar, you have to have the right mix of them.  Product companies also have a very strong engineering led approach that is missing in most service companies that typical have a very strong marketing driven approach.

Secondly, we never quite had the Steve Jobs, the Bill Gates and the Larry Elisions. These visionaries were extremely important in the advocacy that was required for a market to be created. The software services industry on the other hand had people such as a Narayana Murthy and a FC Kohli.

Thirdly, Indians also exhibit another typical behavior. We are more to do with think small and then scale up. We are true conformists to tradition. So therefore most of us have never been trained to think disruptively. This is essential to building a successful global products company and Zoho has done this so well with their SaaS strategy which they did much before Google and Microsoft could launch their office products online.

Fourthly, regulation and infrastructure has still catching up to do. A 512 Kbps Internet bandwidth connection is still un-available in some of India’s tier 2 and 3 cities and even if it is, it is either not extremely affordable or reliable. On the telephony front, regulations have been a constant inhibitor to inhibition. Coming from a customer services solutioning standpoint, these 2 stand out to me first: 3G is yet to take off on a serious note and VoIP calling to telephones are still a strict no-no.

However for people who understand all this, India clearly has the cost advantage. Much lesser capital is required to launch a product startup today in India than in most other developed countries. Also if you are launching a product company in India that Is specific to Indian requirements only, which is actually a great idea to pursue given that the Indian economy is doing better than any other developed countries currently, then you need to make the markets work for you in India by adding localization to your products.

Agile for Startups

This is a simple theory: A "process" is merely the way one does their tasks. A process improvement then simply is about doing them better. Agile processes simply put are ways of working better and the iterative process enables responding to changes quickly using a business approach that aligns product development with customer need.

However, this may not be as simple to implement in the startup context. For one, most startups have the single most pressing need when they begin: they need their first client. Money talks and revenues are the clearest evidence that the startup is tackling the correct problem. Therefore the early phase startup often struggles with innovation as building to sell often takes precedence over building it well. Secondly demo-able working software is damn important and therefore shorter the sprint cycle, the better it works. A recommended sprint cycle for startups is under a week where-in feature releases are done on a weekly basis at maximum. Longer sprint cycles have been shown to actually impact flexibility. Apparently pair programming doesn't work too well for startups either, simply because it’s too expensive. Pair programming for sure brings up the quality of code to much higher levels than without it. However this comes at a cost to startups given the apparent loss in productivity amid their desperation to ship out a product and recognize revenues as soon as possible.

The importance of communication in an agile process cannot be under-emphasized and this remains an issue even for small start-ups. More so, collaboration has been a challenge for the startup that isn't naturally ready to quite adopt the agile culture which brings us to another moot point: agile processes are being introduced in startups without any attention having being given to the fundamental need for a culture shift.

A mix of the following factors typically indicates the best environment for adopting agile: a team of mature/senior developers, small teams (there are potential problems to scaling agile) and a culture that thrives on some amount of disorder.  On the other hand, a waterfall approach is best where a project is mission critical, has huge teams with a large proportion of junior developers and where the working culture is such that it requires order.

Lean Startup is a new methodology typically being practiced by the new startup and this technique combines the offerings of Agile Software Development and Customer Development using already existing software platforms that are usually of the free-and-open-source-software (FOSS) type.

This technique falls back on quick prototyping that are designed to evaluate market assumptions, and uses regular and frequent customer response to evolve faster (by evaluating and avoiding erroneous market assumptions as early as possible). It is rather common to see Lean Startups deploy code multiple times a day, using a practice that has come to be known as Continuous Deployment. One startup out there does as many as 50 deployments a day.  Focus is then thrown on the minimum viable product which then is a collection of only those features that allows for a product to be deployed (and no more).

Organizational Design For Product Companies

A good and effective organizational structure enables an organization to function more effectively and with greater efficiency. Also organizational structure differs from industry to industry and per Edwards Demming, organizational design depends not only on what the organization is doing today but also upon what the organization will be doing tomorrow.
 

For software product organizations, the organization can be divided along 3 major tracks: the marketing track (market research & marketing analysis), the product management and design track (information architecture, interaction design, visual design & usability engineering) and the actual product development track (architecture, engineering, project management, SaaS delivery & even operations).  In product companies, there is also often conflict between the marketing/product managers group and the product development group. While the former typically pushes for early releases, the other focuses on the technical integrity of the product more than anything.  Therefore conflict is built into the design of the organization itself and the absence of conflict may actually give rise to sub-optimal results.
 

Startup organizations are a little different in that they are typically smaller in size and that the personalities and individual skill sets involved actually matter more than the organization structure itself. So therefore roles and responsibilities here are even more important than the right organization structure. In fact, with good intentions aka strong organization culture, any organizational structure is workable and the organization can be designed around the strengths of individual leaders.
 

An organization template I have seen for organizations with focus on innovation and problem solving (as it is with product organizations) is team based. The management style is participative, goals are set mutually and the reward system is in the form of a team bonus. In fact, organizations that go as far as to allow their employees to self-organize and form teams have actually become much more effective and efficient. One company I know of goes as far as to have uniform mobile workstations with state-of-the-art networked computers. People here are always mobile and their office has become an environment that maximizes collaboration and execution.  Remember the ‘skunk works’ concept whose origins lies in at Lockheed Burbank? This concept is now widely used in product organizations and describes an organization that is given a high degree of autonomy and is unhampered by bureaucracy.