Fact 2: When Jeff Bezos started operations at Amazon.com, ‘get it up and get it out’ was the motto. Function preceded style and editorial content. Low on graphics and animation, the site loaded fast and excelled at the basics – making it easy to search and buy books.

What can we learn about building software successfully, from the above seemingly straight-forward facts? Quite a few things actually.

A decade ago, many software startups would be in stealth mode for ages, building the perfect product, burning huge amounts of cash – without actually getting users involved. The “build it and they will come” mentality was all too prevalent.

Today, the concept of MVP or Minimum Viable Product is gaining importance. (MVP is not a very new concept – in fact, it’s a core tenet of modern product marketing) Many software companies have started to realize that building software without customer validation and feedback can be a complete waste of resources. Tech start-ups, especially, can really benefit from building ‘just enough’ features that (a) make the software functional (b) enable early adopters to sign-up and pay (c) help bring real feedback from the market.

Most ideas don’t play out the way they were envisioned. Very rarely can you get the right product out the first time you try. By scoping right, startups not only burn less cash but increase their chances of success by being able to take their products to actual customers, fail fast and continue to iterate quickly based on regular feedback.

NOTE to regular readers: We’ve been dormant for a while on the forum now – our apologies – but we’re back, along with a minor update to the forum and we hope to keep the momentum going! Come join the discussion!

Image credit: liftarn

The Panel discussion hosted by Aspire Systems on “Bootstrapping a Technology start-up” evoked a very good response from software startups across the globe and a few consultants/ecosystem partners as well. We had 3 eminent panelists participating (Prakash Narayan, co-founder and CTO of MiCello; Ted Finch, Owner and CEO of Chanimal and R S Ramkumar, Managing Director and founder of MangoDVM) and Bhoovarahan Thirumalai, Board member and co-founder of Aspire Systems, moderated the panel.

It was an interesting & lively session – we had four broad themes, around which each of the panelists shared their views.

Perfect Vs Quick and Dirty Product

The first theme was on the conundrum of getting a perfect product out Vs a quick and dirty product. One view was that if you’re an engineer, you want a perfect product but from a marketing perspective, you want to show something to your customers as soon as possible. As users are much more ready to give you feedback nowadays, you need to get your product to the market as soon as possible.

The importance of iterating early and iterating often was also stressed upon. Another good point brought up was the use of analytics – measuring how your customers are using your product, which part of your product they are using the most etc.

On the question of who is your first best customer – one of the panelists mentioned that if you are a startup, and if you have a customer, you should embrace that customer – whether it’s a marquee customer or someone (who may not be big) but believes in your product. The point was that when you do approach professional investors, they certainly want to know who believes in the product apart from you & it adds a lot of value to have a MoU with a company willing to use your product.

Another panelist was of the view that a customer who requests your product to be custom-built is your first best customer, as your product is paid for. While this product may not meet all the market needs, it could possibly meet 70% of the needs and can get you started.

Time, Budget and Scope

The question of where does one start when developing the product idea evoked different responses from each of the panelists. Prakash’s view was that it was a good thing to have some protection (read: patent) around your core idea and to use existing frameworks and tools to reduce the time-to-market. Making crucial decisions in terms of the trade-off between features and time/budget are also extremely important.

Read the full summary here or register to view the Recorded Version of the Panel Discussion

Entrepreneurs who bootstrap typically go through trying times. Yet, bootstrapping your software business – being frugal and resource-constrained – has its own advantages. It can help you focus and prioritize, and get your product validated by customers before you consider other funding options.

However, bootstrapping comes with its own set of challenges that need to be understood and addressed early in the business cycle. Come join a Panel of experts, including Vijay Anand (Serial entrepreneur, Founder of Proto.in and Incubation manager at RTBI), Ted Finch (Hi-tech marketing expert & Owner of Chanimal.com) and Prakash Narayanan (Co-founder and CTO of MiCello, a startup in the mobile content delivery space) for a discussion on what is takes to bootstrap. Some of the themes to be discussed include:

• The importance of getting a working product out quickly
• Are customer insights a part of the product development process?
• Identifying when you need to bring in professional investors
• Engaging with external consultants for business planning, market development and sales from an early stage

Bhoovarahan Thirumalai, co-founder and Board member of Aspire Systems, will be moderating the discussion.

Since it is a telephonic panel discussion, all you need to do is call in. To ask questions, you can login to the live online meeting, your questions will be taken up for discussion (time-permitting) during the event.

Date: September 30th, 2009; Time: 11 AM ET/8 AM PT/8.30 PM IST

Entrepreneurs bootstrapping or planning to bootstrap your software venture, do join us for a thought-provoking session!

Calculating the return on investment (ROI) for any planned automation can however help one understand the actual returns that will be obtained from your test automation investments, which can be weighed against the benefits you will gain from automation.

Here is the rest of the article, written by my colleague – Ajay Semwal – at Aspire, that was recently published on the Sandhill.com blog that talks about the need for performing an ROI before taking the automation plunge. Or if you prefer, you can directly compute the ROI of your automation efforts at http://www.aspiresys.com/testautomationroi/ – go ahead, try it out and get a free sample ROI report!

Here are some excerpts of the interview:

In the recent past, you’ve built engineering teams for 2 startup SaaS companies – what do you look for when building these teams and what were the major challenges you’ve faced?

John: I have been very fortunate in my career to have worked with a lot of talented people. Early in my career I worked at Lotus Development on products like 1-2-3 and Lotus Notes and was able to learn a lot about how great teams are put together and, equally important, how energy, excitement, and motivation is maintained while working on projects.

Putting together a great team in any company starts with having a clear understanding of your goals, looking out from 3 – 24 months. From this understanding you build an understanding of your needs, enough to recognize the skills required. From an individual perspective, the keys are character and skills. The key attributes that I look for include:

• An expert understanding of the skills required for the job. If I need a C# developer with 5 years of experience and knowledge of MVC I expect to hire people with those skills.
• I look for past examples of flexibility in their job roles. In startups you will be challenged to fill many roles, not just the one you were originally hired for. I love these challenges; you learn a lot and become a much more rounded individual. However, not everyone thrives under these conditions.
• I look for ethics and honesty. I want to work with people who can be honest about their failures, their shortcomings. When I ask people if they agree with a course of action I expect honesty. I will never know all the answers and I want people who are unafraid to speak up for the betterment of the team.

The most difficult thing in a startup environment is to bring enough attention to team and personnel development. I preach the importance of these things, I believe in these things, and I do better than many people I know. However, I find it very difficult to meet my own personal standards on this front. The challenges are varied, ranging from lack of money for training, lack of time for focusing on individual goals. At the end of the day this is an area where I know I want to focus more energy.

Is software usability a true differentiator when it comes to enterprise products?

John: Yes, and no. Many enterprise products are more difficult to use than they should be. Businesses will often have usability as a single item on a long checklist of features, and will sacrifice it over some other critical features. As some Enterprise products are commoditized, however, you see a stronger emphasis on usability arising, as it becomes more important when product pricing brace to the bottom.

From a software engineering perspective, what are the key things you would focus on to build highly scalable software?

John: As with everything else you need to understand the corporate goals and expected growth patterns for your software. While there are no one-size-fits-all rule that I would provide I would always urge focusing on database scalability first. It’s easier to scale web servers than database servers. From a performance perspective, however, I often see the biggest performance bottlenecks arising client-side with an over-use, or incorrect use, of AJAX capabilities. It is easy to bring the browser to a crawl if you are not diligent in your coding and testing efforts.

Read the full interview

Moving beyond bugs: Testing solutions for optimizing product quality

Changing business environments need mature testing processes & practices that can guarantee success rather than just cut costs. While Testing has traditionally been regarded as a curative solution, the reality is that it is a preventive medicine that can enhance product capabilities and help meet business objectives.

Join us for a webinar to know how Aspire can help you:

-> Handle quality challenges at every stage of the SDLC using our IQA approach

-> Optimize testing process and accelerate releases leveraging our Test Automation Framework – PropelQ

-> Transform QA processes to plan your budgets effectively

-> Identify appropriate processes and tools

-> Gain an insight to our expertise through our success stories

Presenter:

Ananth Krishnamoorthy
Head – Independent Verification & Validation Services at Aspire Systems

Date : Thursday, August 27, 2009
Time : 11:00 AM EST

Register now

For those of you who can’t make it but want to attend, I will put up a link to the recorded webinar here later.

Initially, agile techniques were targeted only at small, co-located teams usually, but now larger teams that are geographically distributed have adopted agile. How has that change come about and does distributed agile really work?

Siddharta: Right, so agile always talks about co-located teams and even now most people agree that co-located teams are always going to be more productive than distributed teams. But there are a whole lot of other things which can decide to make you go in for a distributed team – for example availability of skill sets or strategic decisions by the company. There are many things which tell you, you need to go in for a distributed agile project. We’ve seen over time, distributed agile has been becoming bigger and bigger. In fact, there are a lot of things being distributed.

Jeff Sutherland, one of the scrum founders, talked about teams in the US and Russia doing distributed agile and how productive they are. So there are a lot of people who are really succeeding in doing distributing agile. But the thing is to succeed in distributed agile – you need to make a few changes. Obviously, communication is not going to be as good as if everyone is co-located; similar bunch of practices which ensures that you try to maximize the amount of communication available, it might be a shorter iteration so that you can get further feedback.

You try to split groups not amongst teams – so you don’t want to have developers in one location and testers in another. But along functions or bits of functionality. So you might have developers and testers working on one part of the system in one location, and developers and testers working on another part of the system in another location. And you want to maximize the amount of communication bandwidth that you’re going to build through chat, voice messaging or through cameras and things like that. If you make these kinds of changes you can succeed. I know a number of companies, not just out of India, who are doing distributed agile and are successful.

Selina: Ok. So if you look at it, the nay-sayers of agile say that agile practices don’t give too much important to design, or the design aspects. But design is vital to a product’s long-term success. What do you have to say on this?

Siddharta: This is something that you hear very often – that agile teams don’t do design, there’s a similar thing that agile teams don’t do documentation. But these are kind of misconceptions. A lot of people understand agile to be coding without design, without documentation and equate it to adhoc development. And nothing could be further from the truth.

We need to make a slight distinction between not doing design and not doing Upfront design. So the term used in agile circles is Big Up-Front Design (BUFD). What agile does not do is to get all the details upfront and do a BUFD. So we don’t have a design phase like your typical but agile teams do do design.

As and when they keep incrementing features they revisit the design. And design is something that you look at throughout the project, it’s not technically something at the beginning alone. At the end of every iteration, it is re-evaluated; re-factoring is done constantly to improve the design. This is something which happens continuously. So agile does continuous design and evolving design, but they don’t do BUFD.

So it’s not to say that agile doesn’t do design, in fact it does it right through out the project development. Constant evaluation and redesign.

Selina: So how is design planned? In every sprint or whenever it’s required, you take a look at it?

Siddharta: Whenever someone is recommending a feature, they think about whether it fits in the existing design or not. If it doesn’t fit in, then assuming you are all co-located, you can take a few people and decide these are the kind of changes you need to make and then go ahead and implement them. So it happens on a day-to-day basis, week-to-week, sprint-to-sprint basis.

Read the rest of the interview here or listen to the audio here

Agile has its own advantages and people who vouch for it. So does a completely different way of doing things – the CMM (Capability Maturity Model). What are the compelling reasons for a person who is practicing CMM processes to move to agile?

Siddharta: I’d say there’s only one compelling reason – and that is, if what you are doing currently is not working for you. If you’re following CMMI and it is working for you, that’s great, then there is really no need to change. You don’t have to change because it’s the in-thing. That’s something which I’m quite against.

But a lot of people do have problems when it comes to CMMI when requirements are unstable, because of the way it is structured, and with testing and user acceptance right at the end, which creates a lot of issues with respect to changing requirements. Or cases where you’ve not got the requirements exactly or there’s also the case where the customer sees a product and then gets lots of ideas on how it can be done. So when you have a market like this, then you find that CMMI tends to cause issues because you get bugs right in the end, you get change requests right in the end. It can be difficult to cope with it.

Whereas agile is perfectly suited for those kinds of project. You make frequent releases, there is a lot of feedback is involved, there is a lot of collaboration involved. So in these cases, agile is well suited for these kinds of projects. If you’re doing what you’re doing, and its working then fine, I’d say continue with it. But if it’s not working, then agile could be an alternative.

Right, but is it true that agile is more applicable for consumer kind of applications and products compared to enterprise-class systems?

Siddharta: No, I wouldn’t say it’s true. In fact it’s kind of interesting because where agile originated from – if you look at it – a lot of it is from enterprise applications. If you look at extreme programming, it developed out of a project at Chrysler. If you look at feature-driven development, it came out of a project in Singapore and so all these projects are enterprise projects. The history of agile is actually quite the opposite – it’s come out of an enterprise background, where if you look at it, in an enterprise setting – requirements can change often and things like that.

Now of course, if you really think about agile, it started a lot before Web 2.0 came into the scene. So that’s the background from which it has come and it just so happens, now that we talk about web 2.0, it turns out that agile its perfect for those kind of applications as well because you have releases going out very quickly. But I wouldn’t say that that’s the only type of project that it is suitable for because the history of agile is really coming out from the enterprise group. Even today if you look at it, most agile projects are Java oriented enterprise projects.

That’s a very interesting take. Can you outline some of the biggest challenges you see when people try to make the transition to Agile?

Siddharta: Yeah, there are so many. The number one is getting into a mindset and cultural change. You know, agile is not really about processes if you think about it. What agile promotes is a set of values and process is something which just comes out of a value and that’s why we have so many different processes that can all call themselves agile.

The values we are talking about is like, for example, collaboration between customer and developers and management and testers and so on, we are talking about self-management, about being adaptable. These kinds of values are quite the opposite of what traditional project managers have been used to. They are used to plan-driven projects, they are used to command & control hierarchies, they are used to contract negotiations with the customer. So coming out of this mindset and coming into the culture of agile – that’s the biggest stumbling block.

We see a lot of people who try to adopt agile without changing the values and it runs into some dysfunction or the other. For example, instead of having a self-organizing team, they do iterations but the manager tells everybody what to do. So they think they are doing agile but actually speaking I wouldn’t really call it agile. So you come across these kind of dysfunctions because the cultures as a mind-set change has not been done and that’s really the number one issue. Once you do the mind-set change then you can pick on any number of practices to do what ever you need to do but if you do practices without doing the mind-set change, you could be in some trouble.

Silver Stripe Software is a startup based in Chennai, India. They specialize in agile project management tools that ease the pain in making software deliveries. They believe that project management is as much about communication and social aspects as it is about numbers and metrics. Hence, their goal is to make software delivery a little less hard with elegant solutions to difficult problems.

I decided to break down the interview questions into a series of posts to make for better reading. Here is the first part.

There is a tendency among some of the folks who practice agile to interpret the “Individuals and Interactions over processes and tools” in the Agile Manifesto to mean that Agile software development does not require any defined set of processes. So what is your take on that?

Siddharta: This is a good question, because the Agile Manifesto actually says individuals over processes – so why are we all talking about agile processes? There are two parts to this question – one is about processes and another is about defined processes. Now, what agile says is when you have different projects running, they all run in different conditions. You might have one project which is composed of a lot of senior people, you might have another project with a lot of junior people and a couple of senior people.

Now what we say is that we can’t have the same process for both the teams because the team structure is different, so some practices that work for the senior teams will not work for the mixed team and so on and so forth. So while they will follow some practices, they might follow different set of practices. Now that’s a process, but then it’s not a centralized defined process done by someone sitting in an ivory tower who then enforces it among all the projects in the company…that’s something which people are genuinely against.

Now, what we say is have a process – but have a process which is suitable for your condition. And that’s where agile comes into the picture because there are numbers of practices within agile. If you look at Scrum, there is a retrospective which encourages teams to take their own process decisions to introspect about what they feel and decide if they want to things differently. And that’s all under the idea of evolving the process to suit your own conditions.

So you have to see and adapt accordingly.

Siddharta: Inspect and adapt – that’s the core word here. So while you may follow a process – it’s not a centrally defined, enforced process among all the projects – that’s bad.

Let’s move on to how the tool market is doing. The agile tool market has well-known (enterprise market) players like Rally, VersionOne, TargetProcess and a host of other lean agile tools – so where does Silver Catalyst fit in, how does it compare and how do you hope to make an impact?

Siddharta: The strategy followed by Rally, VersionOne is slightly different from what we are doing. Rally and Version One are really targeting big enterprises who are transitioning to agile, so apart from the tool they provide a whole lot of other services, for example coaching, certification, training. So you can take a tool or company which is not agile and move them to agile, and the tool is just one component of it. So they are looking at companies that are transitioning to agile.

What we follow is targeting teams who are already following agile and the difference is – if you search the internet about what people think about these tools, you’ll find Rally, Version One etc are targeted a lot towards management because they are the guys who are pushing the adoption and change, so there is a need of reports. But the people that are actually using the tool are developers and testers. And a lot of them find it too complicated and too cumbersome to use. It’s not really suited from their line of thinking – what they need to do on a day to day basis.

So Silver Catalyst, because we are targeting teams who are already agile, we are really focusing on how we can make a tool that’s easier to use and better for the developer. We want to make a tool such that you can get your job done in 2-3 min and get on with your work. We don’t want you to spend half a day or one day just figuring out the tool and grappling with it. That’s just a waste of your time because you could be doing a lot of productive work on your project in that time. So that’s kind of different markets which we are targeting and different mindset with which we started when we developed Silver Catalyst.

That’s a very interesting take. But like I said there’s a lot of lean tools in the market, is there any key difference that Silver Catalyst brings to the table?

Siddharta: When it comes to lean tools, I disagree that Silver Catalyst is only a lean tool because it’s got lot of integrations with 3rd party software which many lean tools don’t have. And we have hosted as well as onsite versions. Again, many of the smaller, lean agile tools tend to be hosted only.

There is a difference when you talk about enterprises. One of the key factors which they look at is security of their data – they don’t want their data stored on a 3rd party server and so lot of these companies actually want onsite server versions which they can install and use. Enterprises also want integration with all their other tools, where as smaller companies may be ok – it can be pure project management. But an enterprise or the bigger company will want integration between the parties and between the tools that they use to provide an integrated workflow.

So that’s your key strength.

Siddharta: Yes, we have a server version as well as integration with third party tools that many of the smaller tools don’t have.

I’ll be posting the next few questions shortly or you can LISTEN TO THE AUDIO of the full interview right now.

A quick introduction about Collabnet: The leader in application life cycle management platforms for distributed software development teams. With more than 1.8 million developers using their platform, Collabnet supports more than 800 companies in their distributed development, offshoring, outsourcing and partner co-development efforts. Founded upon open source principles, Collabnet is also the company behind Subversion, the next-generation Software Configuration Management (SCM) solution. Subversion has more than 5 million users worldwide.

Subversion was ranked as the sole leader in the standalone Software Configuration & Change Management space by the Forrester Wave report in May 2007. However, there are many SCM tools in the market from reputed software firms like IBM, Microsoft, Borland and Serena Software. Do you think Subversion will retain its current market leadership position?

Karthi: Yes, Subversion is the sole leader in SCM space. We have more than 5 mn users worldwide using it. They have made Collabnet-sponsored Subversion as the new standard for version control and Software Configuration Management (SCM). With its recent release 1.5 and 1.6, subversion has all the features which an enterprise customer looks for in any SCM tool. Subversion adoption commands 40+% of the market share and it is growing very rapidly. SVN community is also working towards every 6 month releases to bring in new features into the market. So with all of these things, I’m sure, it will not only help Subversion to retain its market leardership position but also consolidate it further.

Collabnet has distributed development teams located across several continents and also leverages open source communities for its product development efforts. How do you communicate between these teams?

Karthi: CollabNet has distributed development teams for its core product development across continents. The teams use our own product, a distributed development platform (CollabNet TeamForge) to develop and communicate amongst various teams and partners. We have also open sourced a few of our products and integrations. We leverage open.collab.net as the collaboration platform to communicate to open source teams and customers. This site contains pretty much all the information related to all of our products – like features, downloads, faqs, roadmap, etc. It also has free and open forums where customers and users can join, and ask questions and interact with the developers and as a community help each other out.

As a product development company, can you just give us quick insight about the top 3 best practices that you enforce among your development teams?

Karthi: Sure. As a company, we follow a hybrid approach. We are founded upon open source principles, we are an enterprise company also. So we follow a hybrid of open and enterprise development cultures internally. We support open communication and discussion on public forums as against one-on-one emails. That’s one of the best practices we have. All important issues and decisions get discussed on public forums. This is very healthy for the organization and creates an opportunity for people to learn, you can just be a silent spectator on the forums and learn from that, or also contribute effectively to the discussions and the decisions. I find this to be one of the best practices that’s helping Collabnet.

We have also adopted agile methodology for our development. Agile methodology’s user-story based approach helps developers to understand and develop to the exact requirement of the story – we always hear about scope creeps and doing more but with Agile approach, you want to deliver to the base requirement of the story, nothing more or nothing less. That keeps the focus better.

We also do code reviews. That is another important practice we follow to make sure that the code is of high quality. It is not only for quality aspect but also helps to share the knowledge.

LISTEN TO THE INTERVIEW

READ THE TRANSCRIPT