What: Unconference for Agile Coaches, Scrum Masters, Agile Trainers, Leaders, Change Agents and Mentors.
When: 7th-8th June 2013
Where: Hotel Ramada, Bangalore
Theme: True Essence of Coaching

Over the last few months, multiple friends and connection from US have asked me to share my experience with pricing Agile related tools and services in Asia (specifically India.) Following is my perspective:

Disclaimer: Asia is the most diverse and dynamic continent out there. Any reasonable generalization is bound to have loopholes. Take it with a pinch of salt.

Since the topic on hand is pricing & positioning agile related services and tools, let’s focus on senior managers at software companies, who are interested & responsible for procuring (or at least recommending) a service or a tool for use inside their company. These folks mostly belonging to upper-middle class or above. Its important to focus on these folks because we can draw the following behavioral patterns based on their profile:

• 1. They are very value-for-money conscious. .i.e. while they are very price conscious these days they are also getting quite brand conscious. Feature-richness or “fully-loaded” appeals to them because they associate it with value-for-money.
• 2. Premium pricing model works well with them. .i.e. price the product or service artificially high in order to encourage favorable perceptions among buyers. Exploits the tendency in buyers to assume that expensive items enjoy
  • an exceptional reputation,
  • are more reliable or desirable,
  • represent exceptional quality and distinction
• 3. If they can’t bargain the price while buying, they feel they did not get a good deal.
• 4. In my experience, Freemium model generally does not work very well. People will somehow find a way to stay on the free plan. Software Piracy is still a notable problem. Things like sharing a license with others is considered wrong, but people will still go ahead and indulge in it. May be because they don’t fully think through the implications or can’t empathize with IP related regulations.
• 5. Price Discrimination strategy appeals to these folks. .i.e. pricing the product differently for different companies. Bigger discount for larger number of licenses is common. But doing something more like: bigger discounts for startups or discounts for specific verticals like Telecom can attract customers.

Based on my experience consulting and coaching IT companies in India, I would categorize Indian IT companies, who are interested in Agile, into the following 5 categories:

• 1. Large Outsourced Services Organization (InfoSys, Wipro, TCS, CTS, HCL, MindTree, TechM, etc.)
• 2. Large ODC (Off-shore development centers) for giant software product companies (Google, Yahoo, Amazon, Microsoft, Intel, McAfee, EMC, Philips, Dell, GE, Siemens, VMWare, Alcatel Lucent, Ericsson, Aricent, Huawei, etc.)
• 3. Large ODC for large non-software product/services companies (Banks and Financial Institutes [JP Morgan, Citi, RBS, Fidelity], Store Chains [Tesco, Walmart, Target], Transportation [Volvo, John Deere], etc.)
• 4. Mid-size product and services companies (Directi, SlideShare, ClearTrip, Cactus Global, etc.)
• 5. Startups (Eko, Interview Street, CommonFloor, HelpShift, OlaCabs, Olx, Zomato, etc.)

Category 1 is highly obsessed with process adherence & compliance. Typically they have an internal process & tool which all projects have to use. In addition, clients of most projects might have a different process & tool required. Teams end up using both. Most teams use different tools because there are concerns regarding how much transparency is healthy for an outsource client-vendor relation. They want only limited data to be shared with the clients. In fact in my experience, to ensure company-wide consistency and compliance, most companies even have their own home grown tool/solution to deal with this issue. If majority of customers are using a process/tool, its an easy pitch to the companies to use the same approach, provided there is an easy way to share limited info with clients. Using same process/tool could add to the company’s marketing/credibility pitch. These companies are price conscious, but if the value proposition (better customer acquisition) is shown, they have the budgets to buy the tool or service. Might require multiple rounds of negotiation. They are willing to commit higher numbers if bigger discounts can be offered. Fairly long sales process.

Category 2 is fairly process conscious, but certainly to a lesser extent compared to Category 1. For these companies majority of the process and tool decisions are made by their counter-parts from west. They do have a say, but are not going to make the buying decision. However they can sabotage the process/tool decision if it does not work for them. Because of the “distributed & off-shore” nature of work, their needs might be different from the folks making the decision. These guys appreciate higher attention/care to their specific needs. Sales process tends to be much faster than Category 1.

Category 3 is also very process conscious. They are predominantly cost centers. Any tool or process which can show clear cost saving, better accountability & tracking is a big hit. Buying decisions are jointly made, however offshore folks do have a big say. Typically these folks require quite a lot of customization to the service or tool to fit their specific needs. Sales process tends to be very long.

Category 4 is out of the startup mode, and are the “wanna-be-enterprise” scale. These are in my opinion the best companies to chase for process change and tool adoption. They have the right attitude to change. Typically they also have the cash and they generally don’t bargain much. They have a strong desire to scale and standardize. Perfect pitch for a Industry Leading Tool to come in and steal the deal. Again these guys don’t tend to bargain too much, but if you give them a discount it will help make the decision faster because they are still price conscious. These guys will do a very detailed market study & competitor analysis. If possible, they prefer to pick the best in category. Sales process tends to be either couple of days or 6+ months (extremes.)

Category 5 is the least process conscious. However are very efficiency & savings driven. They won’t even talk to you if they feel the product is priced and targeted at Enterprises. They would assume/feel the product is expensive and too heavy-weight for startups. A clear pitch for startups in your offerings is very important. These folks will hunt you down. Again very price conscious, but can be good brand ambassadors. Sales process does take some time.

Hope this helps. Also would be keen to hear your experience.

Agile India 2013 Conference hosted a total of 904 attendees over the 4 days. These attendees represented the following 195 different companies:

We had participants with 320 different roles at the conference:

Participants from 25 different countries participated in the conference:

They had the following Agile experience:

Number of Years of Experience

In the last couple of months, I’ve got several requests from top-notch product companies in India, asking me to facilitate a hands-on workshop on decision making using Lean-Startup’s hypothesis validation techniques for their Executive and Senior Management. I’m thrilled to know that companies are seriously exploring these options.

Following is a 1-Day workshop which I’ve successfully ran a few times:

Experimentation Driven Decision Making Workshop

Large number of products/services fail today, not because they cannot be built and delivered, but because the entrepreneurs building those products/services are disconnected from the people consuming them. This disconnect, leads to early assumptions about consumer’s behavior and motivations. To one’s surprise, these decisions can turn out to be based on stupid (read as: deadly and risky) assumptions.

Traditionally, entrepreneurs believed that the only way to test their product/service hypothesis was to build the best product/service in that category, launch it, and then observe user behavior. And of course the big bucks spent on marketing campaigns. Surprise! Surprise! This can be a very time consuming & expensive process; not to mention the huge opportunity cost.

(src: Kent Beck)

Luckily today, we know that many entrepreneurs are using Lean-Startup methodology’s Customer Development practices to help them make important product/service decisions (cheaply) based on Validated Learning.

This workshop will give you a hands-on experience to formulate and quickly test out your value and growth hypothesis.

Process/Mechanics

This is a group activity and the participants have to work in small groups.

In the first one hour of the workshop, each group has to come up a product/service idea, which they believe will really succeed. Then they craft out the elevator pitch about the product/service and put together a basic business model. Post that, the group has to clearly highlight what are their value and growth hypothesis.

The rest of the workshop is dedicated to the participants trying to validate their hypothesis. They can use phone and/or Internet to do their research and validation. The best results, of course, are got when the participants meet real people face-to-face to validate your hypothesis. I’ve seen participants wait outside restaurants, cafes, health-clubs, malls, etc. to run their tests. Some participants also get really creative and build some paper prototypes or fake products to validate their hypothesis. Using a fake credit card swiping machine to see if people will really pay is one of my favorite validation techniques so far.

It always amazes me how creative people can get during this process. Also it’s very fulfilling to see the “Aha moment” on the participant’s face. I can’t describe in words, the shocked look on their faces, when they spend the day validating their hypothesis and discover various hidden assumptions about their target user’s behavior.

Learning Outcome

• Learn how to decide which assumptions you MUST absolutely test.
• Understand why just marketing metrics won’t help you make a better product/service.
• Master the art of leveraging the Minimum Viable Product to create maximum validated learning for minimum cost.
• Learn how to systematically decide when to Pivot to a new strategy.

Workshop style

Interactive dialogues, case studies, hands-on group activities, and on-field exercise.

It’s easy to speak of test-driven development as if it were a single method, but there are several ways to approach it. In my experience, different approaches lead to quite different solutions.

In this hands-on workshop, with the help of some concrete examples, I’ll demonstrate the different styles and more importantly what goes into the moment of decision when a test is written? And why TDDers make certain choices. The objective of the session is not to decide which approach is best, rather to highlight various different approaches/styles of practicing test-driven development.

By the end of this session, you will understand how TTDers break down a problem before trying to solve it. Also you’ll be exposed to various strategies or techniques used by TDDers to help them write the first few tests.

Recently at the Agile India 2013 Conference I ran an introductory workshop on Behavior Driven Development. This workshop offered a comprehensive, hands-on introduction to behavior driven development via an interactive-demo.

Over the past decade, eXtreme Programming practices like Test-Driven Development (TDD) and Behaviour Driven Development (BDD) have fundamentally changed software development processes and inherently how engineers work. Practitioners claim that it has helped them significantly improve their collaboration with business, development speed, design & code quality and responsiveness to changing requirements. Software professionals across the board, from Internet startups to medical device companies to space research organizations, today have embraced these practices.

This workshop explores the foundations of TDD & BDD with the help of various patterns, strategies, tools and techniques.

As more and more companies are moving to the Cloud, they want their latest, greatest software features to be available to their users as quickly as they are built. However there are several issues blocking them from moving ahead.

One key issue is the massive amount of time it takes for someone to certify that the new feature is indeed working as expected and also to assure that the rest of the features will continuing to work. In spite of this long waiting cycle, we still cannot assure that our software will not have any issues. In fact, many times our assumptions about the user’s needs or behavior might itself be wrong. But this long testing cycle only helps us validate that our assumptions works as assumed.

How can we break out of this rut & get thin slices of our features in front of our users to validate our assumptions early?

Most software organizations today suffer from what I call, the “Inverted Testing Pyramid” problem. They spend maximum time and effort manually checking software. Some invest in automation, but mostly building slow, complex, fragile end-to-end GUI test. Very little effort is spent on building a solid foundation of unit & acceptance tests.

This over-investment in end-to-end tests is a slippery slope. Once you start on this path, you end up investing even more time & effort on testing which gives you diminishing returns.

In this session Naresh Jain will explain the key misconceptions that has lead to the inverted testing pyramid approach being massively adopted, main drawbacks of this approach and how to turn your organization around to get the right testing pyramid.

Is writing inline comments always bad? Are comments really evil? I keep getting these questions over and over again.

Often you see code like this:

// If the item is taxable, get the taxed amount using tax calculator
if( objItem.bTaxable )
{
	objItem.fTax = objCalculator.TaxForLocal(objItem.fItemRate);
}
 
// Additional tax is applicable if the item is an imported one
if( objItem.bImported )
{
	objItem.fTax += objCalculator.TaxForImported(objItem.fItemRate);
}
 
// Add tax to item rate
objItem.fTaxedRate = objItem.fItemRate + objItem.fTax;
 
// Return the final amount
double fFinalAmount = objItem.fTaxedRate * objItem.nNumberOfItems;
return fFinalAmount;

What is the real value of these comments?

When I see stuff like this, I usually tell people

When I was learning programming, I was thought that great programmers write great comments. These days I tell people lousy programmer write comments.

Immediately people who write inline-comments get defensive. And that’s completely understandably. I don’t think we’ve really explained our rationale for making such a ridiculous statement. So let me step back and explain the rationale.

Folks in the extreme-programming community will tell you:

Comments are often used as deodorant. Comments represent a failure to express an idea in the code. Try to make your code self-documenting or intention-revealing. When you feel like writing a comment, first try to refactor so that the comment becomes superfluous.

Most people will also tell you, that the biggest problem with comments is that they soon become outdated. The original intent of the person writing the comment was to help a developer who comes later to understand the code better. But unfortunately over a period of time, the comments get outdated and it adds more to the confusion. Speaking to many programmer, they simply delete or ignore the comments because they find them ambiguous. Even though the person who wrote the comments wrote them with a good intension, one needs to ask if it really solved any problem?

And then they question, why not put the same effort and time to write well-crafted code so that comments are never required? Is it impossible to do so?

While this argument is a good one, I find it hard to connivence people just based on this argument.

I’ve found the following approach work really well for me. First let’s understand why programmers write comments. Based on my experience, programmer write in-line comments for 3 different reasons:

1. To explain what the code does
2. To descrive how the code does what is does
3. Why the code is written the way its written

If you think about it, the “what” and “how” of the code should really be expressed by self-documented code. IMHO its simply a failure on part of the programmer if they cannot express the “what” and “how” in the code itself.

However the “why” is little bit more tricky. It’s a reminder, telling us: “Hey, you are doing something complicated and someone else will not understand why. Even if you wrote a comment, they might not necessarily understand it.” At this point I might stop and see if there is a better way to design/model/code this, such that the why becomes obvious via the code. This is certainly more challenging and time consuming than to write a comment and moving on. However this short-term hack might bite me back. Luckily, most often than not, I can find a way to avoid the comment. But there are special cases when I need a comment to explain the why. Let’s see a few examples:

• There is a bug in the underlying framework/library I’m using. Searching on the net, I found the bug report and a workaround. Looking at just the code might not help someone understand the need for the workaround. Generally I would write a small comment saying Workaround with the version number of the framework/library and add the link to the workaround and continue. In future, someone can remove the workaround & delete the comment if the issue is fixed.
• I’m implementing a complex algo and its not common that everyone understands it. I would add a link to the Algo description (rather than duplicating the algo description in the code. DRY principle applies to comments as well.) and continue with my coding.
• And so on…

So think again before you leave a comment