Agile global development - a conversation with Jeff Chang from Ariba

Many product development teams have adopted Agile methods, and many also highly distributed - with development spread around the world in remote labs, outsourcing partners, and people teleworking.

There's a lot written about Agile, but not a lot about how people have applied Agile with distributed teams, particularily large teams. So I set out to find out how product teams make Agile methods work with teams spread around the globe - how it works in practice. In my third interview, I talk with Jeff Chang, who leads the International Development team at Ariba. In this interview, Jeff talks about Ariba's long-term strategies for doing Agile with remote teams, how they deal with the high-cost of communications in distributed Agile, and how they've adapted Agile methods to their advantage.

Matt Hately: by way of introduction, it would be good to have you explain your role to the readers.

Jeff Chang: Sure. I'm the VP of International Development at Ariba. I wear two hats here at Ariba. One is the globalization function, which is internationalization and localization. The other one is as the executive sponsor of our India Development Center, which is our main offshore site.

Matt: Were you using Agile before you set up your global center, or is that something that came after?

Jeff: It actually came after. We were doing offshore before, and Agile came a couple of years later.

Matt: What did you find were the most challenging aspects of making the transition to agile, particularily with your global team?

Jeff: Actually, the way we cope with Agile - remote Agile or distributed Agile - in some sense is avoidance.

Matt: How so?

Jeff: Our theory about doing development offshore is it is a strategy for how you distribute work. And the way we look at it might be slightly different than how Macadamian thinks about it - we're not looking at necessarily just on a single project basis, but on the organizational lifecycle, over years’ time. We view offshore in three phases:

The first phase is the ramp up phase - typically a small project or design. Then, there's a co-development phase where you're going to have a lot of distributed Agile. Then, we get into what we call the encapsulation or ownership phase.

In our mind, where we're trying to get to is large enough ownership modules - ownership encapsulations - to reduce the communication cost, because we acknowledge that communication cost is high. So, that has been our long-term organizational strategy.

Matt: Yes. So, with your current team, What phase would you say they were at?

Jeff: It depends - it's a continuous process. Like most organizations, what we did is we started with a few small projects. There are two kinds of capabilities you are looking for with your remote team. One is obviously knowledge of the technology stack, and the second is domain knowledge. What is it that you're trying to build? That first stage is to try to get them knowledgeable about those two pieces.

Each organization is at a certain life cycle, so some will start with that phase one, then maybe after release two and release three, they're in a co-development mode. Then, you may get release four or release five, when they can take ownership for a smaller piece,then subsequently larger pieces. That's the evolution that we've seen.

There are certain teams that are mature and have a lot of ownership, and other teams are more in the co-development or just starting off mode, if we look across our organization at all the different product teams.

Matt: So, do you use Agile through all of those phases?

Jeff: Yes, we pretty much do. It's a modified Agile. Before we even brought Agile in, we looked at Agile, Scrum, XP. We took pieces of each. I would not say we're as pure, in terms of execution. For instance, we have milestones, but we also have a "back end" - a systems integration QA task at the back end. I would not say that we exit milestones as cleanly as we would like. (We call it milestones, as opposed to sprints). So, these are the aspects of where we may not be as purely agile as we would like.

Matt: Is that driven by the fact that you are distributed? Did you find some things that are very hard to do with a distributed global team in Agile?

Jeff: No, I actually think it's a little bit of our engineering culture. It's hard to get full attention to finishing everything in a milestone. We understand the agile principles, but in the actual execution we bring some of our own ideas in. So, I don't know if that's necessarily related to the fact that we're distributed that's caused the way that we've adopted the process.

Matt: So it's a legacy or a history that comes along with the way people are used to working, that makes it difficult to embrace a "pure" Agile process?

Jeff: I think so, yes. Again, this is an engineering culture aspect, but we're always trying to get better; a continuous improvement, and trying to use better tools, trying to improve process.

Matt: You know, I've been talking to a lot of people about this, and I find that most organizations "cherry pick" what they want from the Agile processes, some of which just do not work in their team.

Jeff: So, that's interesting. We've not done what you'd call a peered study or benchmarking in terms of our process adoption. There's probably something we'd learn from that.

Matt: That would be interesting. There are aspects that are common across most of the Agile processes, like self-organization, which can mean things like picking your own tasks. Is that something that you follow, or that you've adopted? Letting the team members choose their own tasks?

Jeff: I don't know if we do as much of that. Certainly, we have scrums where people talk about the burn-down chart and what has to be done.

Matt: How do you do things like stand-up meetings or daily scrums in a distributed model?

Jeff: That's where geography makes a big difference. And that's what I meant by communications cost. I thought a little bit about the Macadamian model. If I'm understanding it correctly, you have a live synchronization time, probably daily, that's sustainable.

Matt: That's right.

Jeff: And it's probably toward the tail end of the day and the beginning of the day for each team. With India, we don't think that's sustainable. We have tried that. So, there have been periods where there's been a particular project, which was a really tight deadline, highly collaborative, where you had people on both sides who had to contribute major components.

There's the classic 'follow the sun' that people like to talk a lot about, particularly in the context of India. I don't know if other organizations may do that well, but we don't think that's sustainable.

So, the worst case scenario, in terms of communication and synchronization, you might be at nine o'clock in the morning Pacific? You talk to India, that's their night. And then twelve hours later, you talk again. So, it's nine thirty at night U.S. time and it's the morning, India time.

In an extreme case, you can actually synchronize every twelve hours, and you are very productive. But, your team is likely to be pretty burnt out after a few weeks of that.

That's the most extreme form of synchronization. The reality is that we'll tend to have scrums on either side, and then, you'll have a synchronization point - typically the manager. That might be on a weekly basis, and everything else is more off-line.

We've tried many different models, but I think, sustainability is really the question.

Matt: That's a really good point. It's a very common model, but when your team is in India, you don't really have a lot of overlap at all, do you?

Jeff: There is really no convenient overlap in the most common scenario. One of the most common off-shoring models is California to Bangalore and there is no hour which is convenient ever. Someone has to sacrifice. And so, it going to be typically nine o'clock or 10 o'clock at night that someone has to take a call.

Matt: You mentioned some asynchronous communication or offline communication, what kind of form does that take?

Jeff: We have taken obviously email, and there is some IM'ing, but I don't know if we have as much of a pervasive culture around that.

And of course nightly conference calls - at minimum once or twice a week. And we use wikis, and are experimenting with Scrumworks. One of the big issues with Agile is "sticky" planning. The idea is that you want very lightweight planning. You write on the whiteboard saying, "Hey, this is what we are going to do." How is the team in India going to see that? The reality is that you need to have some additional level of more structured communications.

Matt: What do you use wikis for? Collaborative planning or for project information?

Jeff: Different teams have different levels of documentation. And so, some teams will actually write something more like a classic PRD. It is like a story, but it is not very detailed. That is going to be on the wiki. Other teams don't do that level of detail. So, it really varies by team, we are not so uniform in terms of that level of process.

Matt: Another thing that Agile promotes tightening the feedback loop between product management and developers. Can you talk a little bit about how you go about defining requirements and the interaction between PMs and Development?

Jeff: I will talk more generally about team encapsulation. The really good thing about Agile is that it really encourages cross-functional teams working together. We actually had that concept before we adopted Agile. We call them feature teams - we have a representative from product management, from documentation, from maybe usability, and QA and globalization on the team.

Where we struggled from a distributed standpoint is communication with product management. And what we slowly moved towards is essentially setting up full cross-functional teams in India, in the three phases: in phase one and phase two, you don't have that, but in phase three we do have certain teams where we have pretty good representation. But, the one piece that we are still missing is usability.

Matt: Why is that?

Jeff: That's a very good question. We were trying to set up usability in India. I do believe the usability industry is starting to mature.

Quite frankly, it depends a lot on geography and what level of maturity and availability of talent that you have. Product development is still relatively new in India. Trying to find all the talent at the right level of seniority is a challenge.Certain things we'll have to still do offline. We have usability in Sunnyvale. They will spec things and send it over to the teams in India, and then they will send their questions back. Again we can have collaborative discussion.

Matt: Another good point. In India, you don't have that heritage of design both in practice and in the schools that you have in some places in the U.S., canada, Germany, and son on. They have reknowned design schools.

Jeff: Exactly. But, in terms of documentation, product management, and QA we're getting there. There is obviously a lot of interaction between all those teams. The other piece is product management, which I think, is more problematic. And the reality is the technical leader will be the proxy to understand the requirements and translate them into features.

Matt: What about face-to-face communication. Does your team travel a lot?

Jeff: Definitely. That's necessary. Certainly, in the phase one when you've got to incubate a team from nothing and the team doesn't really have much background at all. We will typically bring the team out for some number of months - two to three months - and they'll be working under the wing of senior developers and QA . Then they will go back and they'll be leads for their teams in India. As the team is getting built out, typically the managers will go out and they will also do knowledge transfer.

The lot of the way we think about distributed development is around the knowledge transfer paradigm. How do you manage knowledge? How do you transfer knowledge efficiently? I think that in a single site you don't really have to worry about that.

Matt: Right. It just happens.

Jeff: It happens, right. It's very osmosis based. But something that India has done very well is create a core competency around knowledge transfer. Also face to face, people moving both directions, is pretty key to establishing the relationships.

Matt: Is there anything else we should cover before we wrap up?

Jeff: I will throw in one more process thing, around coping strategies for distributed Agile. One model that we worked on is the encapsulation model, where we believe that at the end of the day, co-location is good. We are trying to organize around fully functioning teams remotely. But the other dynamic behind remote development is that the reality is that you tend to over-invest in QA on the offshore site, because it's more cost-effective.

What that does though is that it puts a lot of development in California and lot of QA in India. And so, our coping strategy is a cascading QA model. The idea is that in an Agile milestone phase, one of the tasks of the QA person is to write high-level use cases. That will get sent to their counterpart, who then does a more detailed QA in a trailing milestone.

The key benefit is that it helps with knowledge transfer. Not everything is written down in Agile, so you're trying to figure out... what's the minimum level of artifact that I need to communicate effectively?

That's why the Agile QA person is writing these use cases. Very high level. And that would then be the guide for the person working on the next level of QA to drive from. So, that again, is breaking the model. The theory is that you've QA'ed everything by the end of that milestone.

Matt: To wrap up, what would you say, if you are going to pass on two or three pieces of advice, key best practices to making Agile work in a distributed model?

Jeff: Well, I will answer it the way I started which is, lots of times avoidance can be your best strategy - I don't know if that is the right answer - but we have looked at the cost of synchronization.

As soon as we started looking at it from a long-term perspective we took the approach of partitioning responsibility and growing capability on both sides, so that they can be fairly independent.

That being said, you actually have sort of the scrum of scrums, because now you have different teams which are still highly dependent on each other. And so maybe we are still distributed Agile but on a different level.

Matt: Right. So, to paraphrase, the long-term goal is to use Agile, but within local teams; rather than trying to do Agile across Sunnyvale and India, India will be using Agile and Sunnyvale will be using Agile, but within their local team.

Jeff: Yes, but the reality is that, at least the way we are set up as an engineering organization, is that we have multiple feature teams or Agile teams, which then have to integrate. So, we are still highly independent, but our dependencies are at a higher level.

Jeff: One other thing - I don't know if it is a best practice, but I think that the reality there has just got to be a little bit more documentation than some of the more pure models. And so, we tend to write down a little bit more upfront - not extraordinarily detailed PRDs or not extraordinarily detailed specs - but at least some minimum level of documentation. At the same time, with respect to planning and the burn downs, etc, and having very variable content and milestones, we use all those principles and we think that holds.

Matt: Jeff, I want to thank you for doing this interview with me. I set out to get a real-world view of how a large engineering team copes with doing Agile development with a distributed team. Thank you for giving us an inside look.

Jeff: You're welcome. I hope it was useful.

Guy Kawasaki interview with Steve Ballmer

I missed MIX - it sold out before I could register, but hopefully I can catch re-MIX in Silicon Valley later in the month. Anyway, they've posted some of the keynotes online. I never thought I'd see Guy Kawasaki interview Steve Ballmer. Watch the first half-hour. Guy asks some great questions, and I always get a kick out of listening to Steve talk - he's so energized. Many companies, when they get to the stage that Microsoft is at, coast on their successes. To see someone so charged up about building products and competing is infectious.

And the back-and-forth about Guy's Macbook Air is hilarious, especially when Steve tosses it on the floor...

And the award for documentary short subject goes to...

When OCRI asked us to put a short video together about Macadamian, and why Ottawa is such a great place to be headquartered, we were all over it. It so happens we have a very talented filmmaker on board in Jean-Claude Batista (aka JCB), with the help of Teresa Wilde's screenwriting and a host of Macadamian characters ;)

We had a lot of fun putting it together, though I can't claim any credit other than putting together the GarageBand loop playing in the background (it is funky though, no?). Let us know what you think about our first short film.

Design considerations for Medical Devices

At Macadamian we're working on a number of projects developing the software for a medical device product. I've noticed a trend lately, that medical device companies are increasingly more interested in usability and good design.

What's driving this? Part of it may be spilling over from other sectors, such as consumer electronics, where Apple is showing all of us how good design, and creating affinity for a product can make a product wildly succesful. Another may be that customers of medical devices are expecting more from device manufacturers, because human-error caused by poor usability can be life threatening.

A major driver is that there are more medical devices coming to market that are being purchased or used by the patient, in their home. For the designer of the device, the environment where the device is going to be used is no longer consistent (i.e. a sterile hospital), and the user no longer a trained professional. Design is now a key consideration, and now has a much greater role in the ultimate commercial success or failure of the product.

There's a great article in DeviceLink about the challenges of developing medical devices for the home, the keys to great product design, and an overview of the user experience best practices for designing a successful device.

Fixed Price or Fixed Budget?

Last week I was on a panel about distributed agile development. There were a couple good takeaways I wanted to share:

Fixed-price or fixed-budget? We talked a bit about agile outsourcing, and if it's possible to do a fixed-price contract in an agile project. One of my colleagues on the panel brought up a great point - most times, in new product development, you're managing to a fixed budget, but that doesn't necessarily mean you should do a fixed-price contract.

What's the difference?

Everyone has budget contraints, whether dictated by Finance or by your investors. But fixed price means you know exactly what you want, you can describe it to your development partner, and it's not going to change. Very few new product development projects work this way - things will change as we test our assumptions with customers, and in a fixed-price contract, change means friction - namely change orders or renegotiating the contract. Often, a better solution is to manage to a budget, but set priorities - working first on the features that will deliver the highest value to the end-user. This gives you the flexibilty to adjust as you go along, when you discover that a feature you thought would have high-value really doesn't resonate with users, or that a particular feature you thought was low priority turns out to be a differentiator.

My caveats: managing to a fixed budget means: a) working with partner you trust and who is transparent, and b) working with a partner with the systems and processes in place to know their development velocity at any point in the project, so that you know how many features you can develop in a given time-box

Does Agile mean no planning, or just-enough planning? I'm always surprised by how few people are actually using agile in product development, and how much misunderstanding there is about agile and the level of planning or documentation that happens in an agile project. Agile means just-enough documentation, not no-documentation. It's not just the waterfall-advocats who think that Agile means jump-in-without-planning. I've heard Agile zealots rebel against the idea that you could do some design up-front. A member of the audience asked a great question at the session - what if you are developing a system that needs to scale to a million users? Are you going to figure this out as you go along? Jump in to code the highest-value features first and figure out the scalability thing when you get to 999,999 users? No. Just-enough design in this case means doing some system design up front. This is what being a master is all about - knowing when a situation warrants what tools and which process.

Product Management Anti-Patterns - Why Products Fail

I went to an interesting event last week put on by the SVPMA. Marty Cagan from SVPG spoke about "The New Definition of Product Management". By the way, if you ever have the chance to hear Marty speak, or to bring him in for training I'd recommend it. I've heard others from product management teams say the same thing.

Marty's theory is that the main reason products fail to meet their objectives (and 50% of products fail to meet objectives) is poor product management, or more appropriately, the way companies define product management. Here are some of the anti-patterns he talked about:

• thinking that customer requirements = product requirements: 1) customers don't know what's possible and 2) customers don't know what they want.
• using product management for keeping track of which customer requested which feature
• definining product management's role as a spec factory, where either product marketing or sr. management define the high level business requirements, and product management's job is to churn out the PRD

In a nutshell, that kind of thinking will never produce a breakthrough product like an iPod or iPhone (Apple has set the bar pretty high for product companies, haven't they?)

Getting it right:

First, recognize that the Product Manager, more than anyone, is ultimately responsible for the product's success or failure. It doesn't matter how great the rest of the team is if they aren't given something worthwhile to build.

The job of the Product Manager is to discover products that are useful, usable, and feasible. To do that, they need to have:

• knowledge of the user
• knowledge of the domain and market
• knowledge of the technology (not the nuts and bolts, but rather they need to know what's possible)

Some other best practices he spoke about include building hi-fi prototypes, instead of a PRD, to define the product and refine it with users, and to create a strong bond between the UX team and the technical architect - you need to have those discussions between design and engineering early, where the architect can offer insights like "if we did it this way, it would be cheaper to build" and "with Flex we could do X Y and Z". These are two things we do at Macadamian and they've shown to be very successful.

If you're interested in digging deeper, SVPG has a collection of great articles on their site .

Interview with Nari Kannan on Distributed Agile development

This week I had the pleasure of chatting with Nari Kannan, the CEO of Ajira Technologies, about distributed agile development. Nari has a global R&D team, located in Silicon Valley and India, and has written extensively on Agile, global development, process improvement, and business intelligence. Nari's team uses Agile methods as a way of ensuring frequent, quality communication, and building usable, useful products that are successful in v1.0.

Tell us about Ajira.
Ajira is dedicated to innovating software solutions for Continuous Business Process Improvement. The Toyota Production System and Lean Six Sigma have traditionally concentrated on bringing Efficiency (Doing things right) and Effectiveness (Doing the Right Things) to Manufacturing. They concentrate in eliminating non-value adding steps in the manufacturing process and speeding up other value adding steps. For example, painting a car door is a value adding step. Filling out the paperwork after fitting a door to a car does not add any value to the buyer of the car. So why not eliminate it? Ajira wants to bring the same kinds of approaches to Business Processes through software products. So if the Passport Office says that it takes 6 weeks to process your application, can you ask the question, how can they do it in 3 weeks? How about 1 week? How about same day service? All of these are possible with relentless continuous process improvement!

Business Process Improvement starts with being able to collect and analyze process Key Performance Indicators (KPIs). These can be efficiency related like Claims Processed Per Hour or Effectiveness related like Value of Policies underwritten in a day. Ajira products help collect business process KPI information, store them in n-dimensional cubes, and slice and dice them for Process Insights. These process insights will help improve business processes by highlighting bottlenecks in the process and the right things to spend time on.

I understand your R&D team is distributed between Silicon Valley and India. Tell us more about how your team is structured.
We are a very small startup that cannot afford to waste even a second. All of the Engineering Requirements and Design are done in the U.S. The development teams in India are headed by project leaders in India who are totally responsible for translating quick and dirty requirements and design documents into software versions and builds.

When people think of outsourcing development, they often think of waterfall, or big-design-up-front. When does agile make more sense?
Simple, well understood, standardized functions like Accounting, Order Management, etc are very suitable for waterfall model since requirements are clearly understood, may not change much and are easier to put down on paper. Agile makes sense when the requirements and the designs are themselves subject to frequen change. Very new functions or highly innovative software products or applications where the requirements themselves are discovered iteratively, Agile is the only way to go. If there is an existing mainframe application and you are creating a Windows or Unix version of the same, Waterfall model is appropriate since you can specify the system clearly upfront.

Innovative software products are work in progress at least until V3.0 or V4.0. It is well documented that early users of Oracle or SQL Server database management systems did not have a stable predictable product until at least the third or fourth major version of the product, suddenly creating mass adoption. For inn,ovative software products you want to get to this stable product as quickly as possible, sooner than V3.0 or V4.0, and Agile methods provide you a way of getting there that much quicker.

What are some questions a VP of R&D could ask of himself and his team to know if they are ready for distributed agile development, or whether they are better off using more waterfall processes?
Agile methods are just one more way of increasing the Frequency and Quality of Communication. If the requirements are well understood and simple, waterfall is the more efficient and effective way to go. If you know that the application or the product is going to evolve over time, Agile methods increase the Frequency and Quality of Communication. If the developer knows fully well that the person providing the requirements is only guessing at what the requirements could be and could change his/her mind about it, Agile provides a way of getting something in their hands quickly. It is easier to REFINE requirements than to specify requirements clrealy upfront, especially when you don't know what is important to your client or customer. This is what Agile methods enable; ways of frequently getting something working that the end user can see and use, and provide feedback about.

What do you think are the top three best practices for making agile successful in a distributed team?

1) Rapid and Frquent Communication - Agile does not mean no documentation. It just means that you are very effective and efficient with your requirements and design documentation. Two or three pages. This also means leveraging a communication pyramid diligently - Yahoo or other Chat methods everyday, written quick progress reports every day or week, and face to face in-person communication, even if the team is 10,000 miles away - at least a week every two months.

2) Frequent Builds and Releases - Every week or every two weeks you need to have a build released and tested fully. You can leave out features if you don't think you can finish them in time for the next build, but a build needs to be done without fail. This enforces all code developed in distributed teams work together reasonably eliminating compatibility problems early on. If you postpone a build, you are just postponing addressing problems in different developers' code from working together.

3) Flexible Project Management - Projects need to be managed somewhat flexibly within the one or two week build timeframes. If a key feature needs to be addressed soon, a one week build can become two or even three. The idea is to identify what you think may be difficult implementaion issues and address them earlier rather than later. This way you don't postpone tricky problems till the last minute.

What are a couple of pitfalls or traps you see people falling into when doing agile in a distributed team?
Not understanding the deeper reasons on what makes agile methods work. The deeper contribution of agile methods are that they enable communication - the no.1 reason development projects fail. Agile methods allow the developer to say every week or every two weeks " take a look at this - is this what you meant when you said you needed feature X?". This way misunderstandings with requirements are dealt with early and periodically.

Agile rituals followed without understanding why they are needed and how they need to be practiced for them to work is the biggest pitfall in a distributed team.

You’ve mentioned that you’re applying the Toyota Production System to your development processes. That’s somewhat unique in the software world. What aspects of the Toyota Production System do you think are well suited to building software?
The biggest contributions of the Toyota Production System are Iteration, Elimination of Non-Valued added activities and involvement of everyone in the manufacturing process in decison making when changes are made to the production floor.

Iteration is the heartbeat of Agile Methods. You develop the right software by iteration - include a few features in each build and get feedback from users. Problems are eliminated slowly but surely. You converge to what is needed perfectly, quickly. The same thing with Toyota Production System - any new Toyota factory takes two to three years to come up to full production. They address each problem thoroughly!

Elimination of Non-Value Added steps - Requirements Documents need not be 50 pages long. Requirement Documents and Design Documents are necessary evils. To the end user the time you spend putting in validation routines adds value to the user. The requirements and design documents are only for the developer. They are of no use to the end user. Doing them as short as needed without sacrificing the Frequency and Quality of communication is the trick!

Involvement of end users in the development process is earlier on in agile methods than in waterfall methods. Agile methods enable end users to see the results of their communication earlier on and validate them with actual software use.

You’ve also mentioned Lean Six Sigma, and how there are some parallels to agile development, especially how they approach continuous improvement. Tell me more.
Agile methods can become dogmatic and ritualistic, and as useless as Waterfall methods if developers don't understand where they should be applied and where they should not be. For example a simple requirement can be just a single bullet line in a document. However if what you are designing a complex workflow, borrow UML modeling or State Transition Diagrams and capture the workflow accurately.

Lean Six Sigma and Continuous Process Improvement are useful in software development since every development project has its own characteristics with respect to complexity, solidity of requirements etc. Being able to quickly assess what is working for your development and what is not and making appropriate adjustments are what Lean Six Sigma and Continuous Process Improvement teach you!

What one or two pieces of advice can you leave our readers with who are thinking about moving to a more agile approach with their global team?
Software Development is 80% communication, 20% software skills, milestones, and everything else. Get the communication right. Everything else will follow. The end goal of software development is developing software that somebody can use to do something useful. Programming Languages, Specific methods like Scrum or other Agile methods are all tools in accomplishing that end goal.

A master carpenter will use his biggest chisel to fashion a crude toy for his child. He wil use the best of his woodshop to carefully measure, and use all of his powertools to craft a fine dining table. Becoming a master carpenter is knowing when to use what tools, and how much time a task deserves.

Brand - what's in a name?

I've been thinking about Brand a lot lately, and came across this great post "What's in a Name? Less than You Think" from the folks at the Silicon Valley Product Group. Brand is more than your name, logo, and color palette. In fact, I'd argue those don't have much to do with your brand at all.

Some of the best known brands in the world have mediocre names. IBM breaks the rule of never naming your company after an acronym. If you were starting a band, would you name it "The Eagles"?

Or how about Macadamian - who would name a company after a nut? ;)

Outsourcing development for startups

"Should I outsource development?" is a question I get asked all the time by founders of startups, along with "when, in the growth of my company, is the right time to start outsourcing?" So I decided that over the next few weeks I'll talk to some of my colleagues and publish their advice here in my blog.

In the meantime, here are a few of my tips on outsourcing in an early-stage startup:

1. Have a CTO: If you're going to outsource some or all of the development of your product, you need to have a CTO. Or, someone on your team needs to have a technical background and play the role of an interim CTO. Someone needs to have an overall understanding of how the product is being architected, so that there is some long-term "memory" of the product inside the company. Someone also needs to be able to judge things like code quality and quality of the design. You may get lucky and work with a great firm, or you may get burned down the road because the product worked, but some bad design decisions were made because no-one had the long-view.
2. Have a product manager: It doesn't have to be a separate role - the product manager could be the same person as the CTO, or, it could be the CEO, but someone needs to play product manager. It should be someone with an aptitude for translating marketing requirements into product requirements, and an eye (and patience) for detail.
3. Have internal QA: When I was on a panel about ramping up R&D teams in startups, about half the panel disagreed. This idea came from a colleague of mine who was building a development team at a startup, and I tend to agree with him. Again, you might not have a budget for full-time QA yet, but QA should be one of the hires you make around the 10 person mark. You could have QA on the outsourced team as well, but even having one person on the team who understands how to read a test plan, and can attest to the fact that the outsourced team is doing the right things when it comes to testing will go a long way to making the project a success.
4. Spend the time (and money) reviewing contract terms: As a startup, your IP is what you're hanging your hat on, so you want to make sure that you're well protected if anything goes wrong, especially if your outsourcing partner is working partly for equity. You probably don't want your outsourcing partner owning the IP to your product should you miss a payment. There's a story around Silicon Valley about a savvy contractor who owns a good piece of a very successful product for that reason. Not that anyone had anything to complain about in that situation - everyone was made very wealthy, but no doubt the founders cringe at the percentage they've had to pay to the contractor who developed the product.
5. Work with a firm that has worked with companies your size: Maybe this sounds like a no-brainer, but I've spoken with many early stage companies who were disappointed with the results after working with a "brand-name" IT outsourcing company. As an early-stage company, you are pretty low on their priority list if you are competing for attention with customers who have multi-year contracts for 50, 100, or even 500 FTEs. Getting face-time with their CEO or executive team if there are issues with the project are slim to nil. Moreover, the larger companies tend to have established processes, which is good in most cases, but maybe not so good if you're startup with very few processes, and you're expecting your outsourcing partner to be able to turn on a dime.
6. Find a firm with Agile processes: Chances are, your product is groundbreaking or you probably wouldn't have taken the plunge to start your company in the first place. And if it's groundbreaking, chances are it's never been done before, and no-one has worked out all the details yet. Things will change. Details will be left out. Many outsourcing companies expect a BDUF (big design up front), which can be problematic if you're not sure if it will even work as you originally envision. Agile processes are better suited to next gen product development than waterfall, as they are inherently better at dealing with change and unknown.