Livescribe's Smartpen

I had the opportunity last week to have a live demo of Livescribe's Pulse SmartPen from Peter Hewitt, who is an advisor to Livescribe. What a great technology! The Pulse has a form factor of a large fountain pen, yet it contains a camera, a microphone, memory, and a USB interface. Think of it as a pen that can also record a conversation, seminar, or lecture. It syncs your notes with the audio, so once you're finished taking notes, you can point to a line in your notes, and it will play back the audio from that

Peter and I recorded an interview, where we talk about Macadamian's business model and the kind of work we do. He uploaded the notes to Livescribe's web app, where you can listen to the whole interview and see Peter's notes. You can even search on the text. Remarkable!

I ordered a Pulse immediately after our meeting. I could see it being incredibly useful in transferring knowledge throughout a project. How many times have you passed on your notes from a meeting to a colleague, only to realize you have no idea what one particular point meant, even though you're the one that wrote it? With Livescribe you can go back and listen to the audio at the exact moment you wrote the note. I'm starting to sound like an infomercial for the Pulse, so I'll leave it at that. Go check one out!

HTC Bets On Design

Interesting piece of news this week - HTC bought One and Co, a San Francisco-based design company. The iPhone has changed the game, and the cell phone has evolved to where features no longer differentiate. HTC, traditionally a very engineering-driven company. In fact, they have traditonally been a white-label design and manufacturing company for the OEMs - you wouldn't even see their logo on the phone. They sensed that they had a weakness, and didn't have the design culture to compete against Apple, so they bought a consumer-design company. This is one more datapoint showing that the technology industry is getting serious about design as a differentiator. I think it will help HTC leapfrog from supplier to a leading contender in the next couple of years.

One other tidbit in the article I found personally interesting - HTC is hoping that insights and ideas from other non-competing One and Co projects will make their way into HTC designs. For instance, One and Co's work with K2 may lead to new materials for HTC phones. I'm glad that they think that way, and I hope that thinking becomes pervasive in software. I always thought that this was a core strength of Macadamian - the lessons, insights, and ideas we gain in one vertical are applied to another, creating new opportunities, or simply better ways of doing things.

Macadamian named to the InfoWorld 100

A happy start to the week - we were awarded an Infoworld 100 award for innovative use of technology in our business.

To give a bit of context to new readers, at Macadamian we design and build products for other technology companies. We're a software consultancy whose mission in life is to help other technology companies create great software products. We want our customer's customers to be as passionate about our customer's software as they are about their iPod.

We've grown to over 150 staff, in 4 countries, and we're delivering over 100 projects a year - most of them on tight deadlines. Our methodology blends user-centered design and agile project management. Predictability is key - we need to deliver what we said we would deliver on the day we said we'd deliver it. Or else.

So to tie together a project team distributed around the world, with customers distributed around the world, our Process Improvement team, led by Sylvain St-Germain, developed ProjectTools. ProjectTools is both the glue between our configuration management (namely Subversion and Jira) and collaboration tools (Confluence and secure newsgroups), and a dashboard that collects data from all those systems and presents them visually. It manages tasks, tracks defects, and provides Wiki functionality so that team members and our customers can collaborate and share information 24/7. What's really killer though, is it gives both our teams and customers a simple, visual view of the health of a project. It provides complete transparency - everyone sees how the project is progressing versus the planned schedule, and the full status (defects, planned vs. unplanned work, and a host of other metrics), in real-time.

Sylvain and his team live the Macadamian values - Transparency, Responsiveness, Agility, Collaboration, and Constant Improvement. Customers love ProjectTools, so I'm thrilled that the industry has recognized his team's work. Congratulations guys!

Voice of the customer

If you're in Ottawa on Nov 13, check out this event on Voice of the Customer.

Figuring out what users really want is probably the biggest challenge product managers and designers face today. It's easy to fall into the trap of simply gathering user feedback and turning into product requirements. How do you create the game-changing breakthrough products that users can't even imagine? You've heard it said that if Henry Ford asked for user feedback, he'd have built a faster horse carriage.

We partnered with OCRI to set up a panel of three user experience experts to find out how they go beyond user feedback and discover the true needs of their customers, and translate that into products that will sell. If you're a product manager, software executive, or UX designer, you won't want to miss this event.

Business models to learn from

I was flattered when I read this post by Andrew Waitman about business models to watch. Andrew is a respected VC in the Ottawa tech community, and he cites Macadamian as one of the business models to learn from, particularly in a tight investment climate. Also nice to be mentioned along with some companies I really admire: Fidus, Pythian, MXI and Fuel Industries

Social media and user feedback

Here's something you would have never seen prior to social media - users banding together to critique your product, using your product.

This month Facebook redesigned their interface, with the aim of reducing the clutter, and a number of users joined in protest by forming Facebook Redesign Protest groups.

The redesign was well executed, but what really impressed me was the response to the protest by Facebook execs. They are very confident that users will love the new redesign, and they find it humerous that people are using their product to protest their product.

The immediate feedback loop of Web 2.0 can be your downfall if you're not careful. Some Web 2.0 companies only look at feedback, and things like split-testing (creating two pages with two different designs, and serving each to half of your users to see which gets a better response rate or better feedback). In chatting with one of our Sr. Usability Architects, Scott Plewes, last night, he related that any time you don't use direct observation as part of the user-feedback mix, you risk missing the context and misinterpreting the data. Bottom line - you need to understand the motivation behind a user's decisions or you are flying blind.

I don't have the inside line on the Facebook redesign, but I'm sure Facebook employed a number of testing methods to gather feedback on the design - things like focus groups, ethnographic research (observing users using Facebook in their natural habitat), and usability testing. Where a number of Web 2.0 companies would have hit the panic button and rolled back the changes when they saw the protest, Facebook execs were calm and confident that they did the right thing, no doubt because they did their homework.

How do you structure a team for innovation?

I had the privilege of attending the Forbes Leadership conference yesterday. If you ever have the chance to attend, it's a must.

The topic was innovation, and one panel was on innovation and teams. One panelist mentioned that he believed innovation was a team sport, an idea that I subscribe to.

We talked a bit about how to structure a team for innovation - what individual backgrounds, personalities, and roles make a great team that comes up with breakthrough innovations? Judy Estrin had a great answer - what's most important is not the specific backgrounds, but that the team has cognitive diversity. If you're trying to come up with a disruptive product, you need a team of people who each approach problems from different angles - who will challenge one another and help spark creative ideas by following brainstorming paths they might not have otherwise followed.

Visual Misinformation (and a bit about offshoring)

I tripped across an article by McKinsey about the changing offshore landscape (short registration required). The low dollar and rising wages in BRIC countries are eroding some of the cost savings of offshoring - something most of us already know, and further proof that you shouldn't hinge your entire offshoring and outsourcing strategy on costs savings.

I read the article expecting to come away with several interesting insights, however I got sidetracked by one of my biggest pet peeves - blatent misrepresentation of the facts by skewing the scale on a graph.

Check out Exhibit 1 in the article (graph: A changing environment for offshoring)

The graph shows trends in world wages. The Y axis - wages - goes from 1000 to 8000, then suddenly jumps to 40,000. The graph makes it look like the wages in emerging countries are about to overtake US wages at any moment.

People put a lot of stock in visuals, especially graphs, which are meant to convey the hard facts - the unbiased data from which you can draw your own conclusions. However journalists (or editors?) frequently skew graphs to make their point. A more common trick is to start an axis at 100,000 rather then 0 to make a trend seem more dramatic. This however, is one of the worst I've seen. A real disappointment coming from McKinsey.

Reader beware.

Living with a MacBook Air

I finally did it. After years of making fun of Macs, I am now a Mac owner and a member of the fully converted.

Not only that, but I went whole-hog and bought a MacBook Air, against the recommendations of my colleagues, and virtually every reviewer on the Web.

I LOVE this machine.

One of the things I admire about Apple is they don't succumb to design by wish-list, a very common antipattern. In many companies, the product manager is a requirements secretarys - they gather lists of requirements emailed by users (who are typically power-users), prioritize them, and mold them into a spec. What you get is a product stuffed with features that aims to please everyone and please no-one.

Apple got it right. Not that the reviewers are wrong, but what they fail to realize is that they are not the target market for this machine. Reviewers are power users. Reviewers are geeks. I simply need to get s**t done. Reviewers complain about the lack of DVD drive. I haven't used a DVD drive in 3 years. They blast apple for not including an Ethernet port. I have Wi-Fi at home. I spend an unhealthy amount of time working from cafes and airports with Wi-Fi. Most of the hotels I stay at have Wi-Fi, and for the few times I need Ethernet, I bought a little USB-Ethernet dongle. I travel once a week. It's light (nothing worse then carrying a 10 pound laptop around an airport), fits perfectly on an airplane tray, has a backlit keyboard for working on late-night flights, and darn it - this is one sexy looking laptop!

What can we learn from Apple? As a product manager, your job is to know your market and your target audience, and devise products that will fill their need - tools to help them get jobs done. Avoid the temptation to try to fit in every incoming request for features from customers who may or may not represent your target market.

Software companies becoming more concious of feature bloat

Interesting article about Symantec's Norton suite in the Aug 18 issue of Business Week. The article quotes Rowan Trollope, who runs (or ran) the consumer products group at Symantec - he discovered that his friends turned off most of the features in the Norton suite rather than deal with all the problems it causes. It was a wake-up call, and he set out on a mission to get the bloat out of Norton.

I've had the same experience. Friends and family ask me "Can you look at my computer? It's really slow accessing the web." Inevitably I find out they recently installed Norton and between the anti-fraud, anti-identity-theft, anti-virus, anti-adware, and anti-spyware it's grinding their system to a halt.

Kudos to Rowan to listening directly to customers, but I have to wonder - why did it take a directive from a top executive to embark on trim the fat in Norton, which for the record, is still as bad as it was two years ago? It's painfully obvious to customers, and should be painfully obvious to the support team, the product management team, and the QA team.

Thankfully, we're just at the cusp of getting beyond the GeeWhiz phase in the software industry, where everything is so revolutionary that people will buy it regardless of how painful it is to use. The software industry today is a bit like the car industry of 1920 - the sheer novelty of horseless transportation outweighed the fact that driving most cars was more complicated than brain surgery. Now that there's a computer in most homes, and "Photoshopping" is in the mainstream vernacular, we're very nearly at the point where ease of use, design, and simplicity will win over feature bloat. It can't come soon enough.

Unified Communications goes mainstream

I remember Fred once told me we dramatically overestimate the success of a given technology in the short term, and then dramatically underestimate it's impact in the long term. It's definitely been true for VoIP and Unified Communications - they hype was unbelievable, and VoIP pundits predicted the rapid death of traditional telephony, then as the promise failed to materialize overnight, and people suffered through the unreliability of early systems, they lost interest.

I remember having conversations a few years back with colleagues about how cost-reduction will drive VoIP adoption, but the true benefit of VoIP and UC will be business productivity and integration with other enterprise systems. I was happy to see an article today titled "Vertical Apps Drive UC Interest" in FierceVoIP . The article cites a report from Light Reading that finds that vertical market applications in finance and healthcare, as well as Fixed Mobile Convergence and Collaboration are driving adoption of Unified Communications.

In the next few years we'll finally start to see the true promise of VoIP - softphones for your mobile device that completely integrate with your office PBX, archiving and searching customer calls in your CRM system, and many things we can't even begin to imagine. The future is here.

Want to create software your users love?

Last week Lorraine Chapman, Macadamian's UX Project Manager, delivered a webinar on the right and wrong ways to get user input on design. Many software companies still go on "gut feel" and market research when designing new features, citing time constraints, budgets, or simply "we know our product-space best" as excuses not to get user feedback . Lorraine dispels some of the common myths about involving users in design and covers some of the techniques and best practices we use in design.

Click here to view the archived webcast.

At the Stanford Summit - What is Green?

Many of us at Macadamian are very passionate about green tech and the environment. A question we've been bouncing around Macadamian is what role does the software industry have in green tech?

I'm listening to an amazing panel on green tech. On the panel is the Chairman and CEO of Southern California Edison, and the CEO of New Energy Finance to name a couple.

The panel acknowledged that while most of the buzz is about solar and wind power, one of the biggest opportunities in the next decade is the digitization of the grid. The power grid will go through the same revolution as the communication grid. Look at your cell phone bill - every text message is itemized, categorized, and quantitized. Look at your utility bill - it shows you how much energy you used in a month, and if your utility is really sophisticated, it shows you how much was onpeak and how much was offpeak.

As we come online with Smart Meters, it opens the door for new ways of conserving energy. Imagine that your meter can negotiate with your washing machine, to tell it the best offpeak time to start the cycle.

It may not be as sexy as solar, but the impact is huge.

At the Stanford Summit - on usability of IPTV

I'm at the Stanford Summit this week, and last night was a great opening panel of media executives. While most of the Summit is panels of startups, it was great to hear from the established broadcast and media companies like ABC and Paramount about the future.

One remark really stood out, and the panel agreed - part of the success of VOD and IPTV hinges on usability. Tivo, for example, has great usability, and it's the only "independent" PVR that survived and thrived. On the other hand, the usability of most set-top boxes from mainstream cable companies is rotten. I can relate - the box I received from Time Warner is virtually unusable. Searching for a show is a pain-staking experience.

The panel was clear an unambiguous. What they are seeing is usability drives adoption. When you give consumers an easy way to find and consume video content, they adopt.

The Ten Faces of Innovation

I just finished reading The Ten Faces of Innovation by Tom Kelley. Highly recommended reading for anyone running a product development team or in a product development role.

What I like about IDEO's approach to innovation is that they don't subscribe to the Lone Designer in a Dark Room mentality. They beleive innovation can be a repeatable team process. Ten Faces talks about the ten personas you need in an innovating team:

1. The Anthropologist: Observes human behavior and develops a deep understanding of how humans interact with products on a physical and emotional level.
2. Th Experimenter: Prototypes continuously
3. The Cross-Pollinator: Explores other industries and cultures, and brings revelations back to the team
4. The Hurdler: Knows how to overcome (or outsmart) the roadblocks in innovating, like finding internal budgets for the project
5. The Collaborator: Brings this eclectic group together and leads from the middle of the pack
6. The Director: Gathers the talented crew and helps spark their creative talents.
7. The Experience Architect: Designs compelling experiences, beyond mere features and functionality.
8. The Set Designer: Creates the environment in which the team is going to do their best work.
9. The Caregiver: Anticipates customer needs and is ready to look after them.
10. The Storyteller: builds awareness and morale through compelling stories.

I love the way that Kelley starts the book - he proposes that we have too many Devil's Advocates in our organizations. You know how it goes: when someone proposes an idea that's outside the box, there are several people willing to jump in with "Well, that's fine, but let me play Devil's Advocate for a second".

What if instead of saying "let me play Devil's Advocate, and shoot down your idea, but mask it in my Devil's Advocate persona", we said "let me play the Experimenter for a minute, and go put together a quick prototype", or "let me play The Cross-Pollinator" for a sec - I saw something similar work in another industry - I wonder if we could apply it here?" Do you think that would make you a more innovative company?

Kelley's not proposing that your team have each of these functions, but that people on the team adopt these personas. In a small team, one person might be the Director, the Set Designer, and the Storyteller wrapped up in one. He's proposing that a high-performing innovating team has each of these personas somewhere in the team. If you see these behaviors, nurture them. Innovation is a state of mind.

Habits of top innovators - getting unstuck

I'm looking for a coach (a business coach that is), and so I reached out to a colleague who is at the top of his game, and he expressed that he too is looking for a mentor. I found this interesting - where do you go for mentoring when you mentor for a living?

Recently I had the pleasure of studying with one of the top bass players in the nation, and I asked him "who do you study with?" It turns out he doesn't study with other bass players - he's learned about all he can from other bassists. Instead he goes to the best sax players, and the best trumpet players, to learn how they approach solos and phrasing, and he interprets and applies that to his bass playing.

What does this have to do with innovation? Bear with me - I'm almost there.

When you think you've plateaued with your product or business, or you're fresh out of new ideas, one of the best ways to break through is to study a different industry. How did a completely different industry tackle similar problems? What can you learn from the trade journals of a different vertical? Let's say you're in software - instead of attending a software event, go sit in on a manufacturers luncheon. Can talking with a product manager at another non-competitive company help you approach things differently? People are usually more than happy to chat with you, or even give you a tour of their facilities if you just ask. Who knows what it can do for your business.

Good design and the top line

Typically, technology companies, especially those that sell to the enterprise, have not invested heavily in design. The most compelling and usable products today are consumer-oriented - products like the iPhone and Google, as great design directly translates to purchases and clicks.

In the enterprise, often the end-user isn't the buyer, and usability and design ends up taking a back seat in the purchasing decision to features and price. So companies that sell to the enterprise have traditionally found it hard to make the link between usability and the top line. They struggle to make the ROI link, and at best, can only make weak links between investing in usability and reducing support costs.

If you are building enterprise products, you need to read this article: The Mac in the Gray Flannel Suit. CIOs are being bombarded by workers who want Macs. Why? Because consumers are infatuated with iPhones, iPods, and Macs, and they want to use them at work too. Consider: Apple hardly has a corporate sales force. It's a struggle to get an Apple account rep. That's a dream situation for most technology companies.

What about software? Ask a sales team about their CRM system - 9 out of 10 will tell you they hate it, and reluctantly use it because it's been dictated from up high. Is it any wonder that Salesforce.com is growing so fast? They've made a usable application that makes it easy for small teams to sign-up and start using it. When Salesforce.com started, many were skeptical (and some still are) that they could penetrate Fortune 1000 sales teams. Take a look at Salesforce.com's press releases and you'll find many recognizable names. The SaaS model is empowering the end-user, and making it easier for end-users to discover and try products, and that's making it easier for companies who understand good design to leapfrog their traditional competitors.

Making Outsourcing Work

I attended a great conference this week called the International Software Development Outsourcing Conference. The panels comprised of engineering executives from companies like Symantec, Siperian, Intuit, OfferTap, and EA and discussed everything from Outsourcing in Startups to Choosing a Partner to Making Outsourcing Work.

I gauge the value of a conference or talk from how many notes I take, and how many actionable insights I walk away with. I have about 10 pages of notes from this one-day conference. Here are some of the insights shared by the panelists:

• T&M is a broken model and customers are starting to move away into a more balanced model, where both partners share some risk -models like Fixed Price/Fixed Time engagements, or a T&M arrangement with ratchets for meeting KPIs (Key Performance Indicators)
• The more partners are aligned on a risk model, the closer you are culturally - the more you have a common understanding.
• Waterfall methods in outsourcing assume that your partner is just like you - which is rarely the case, and why throw-it-over-the-wall outsourcing usually ends in overruns.
• One of the best ways to describe requirements to an outsourced team is through wireframes, storyboards, and UI mockups
• Five years ago, 50% of respondents in an outsourcing survey said they outsourced to India to reduce costs, about 40% said for quality, and less than 10% said they outsourced to India for innovation. 5 years later, those stats have flipped.
• You can find pockets of specialized skills all over the world. If you outsource to a large vendor, on the other hand, for a specialized skill - you are very likely paying them for on-the-job training
• CMM is no longer a selling point. When the customer is CMM level 0.2, working with a CMM level 5 company is somewhat pointless. There is also a healthy skepticism about CMM - being CMM level 5 doesn't necessarily mean that every person or ever team is folllowing the process
• One of the best-practices cited was to use T&M for the scoping and requirements gathering phase of the project, where there is a high degree of unknown, then a Fixed-Price/Fixed-Time arrangement for development and QA, then back to a T&M project for the user acceptance testing and integration, where again there is churn while the customer organization lines up the right resources.
• There is a growing backlash in Silicon Valley against being on calls from 7 pm-12 pm every night with overseas teams. Some new hires are making this a condition of employment - that they will not take a job where they will need to be on calls every night when they should be spending time with their family.
• Local, and on-site presence is becoming increasingly important.
• Take termination fees off the table. As an outsourcer, you have to earn the right to stay.
• The next generation of outsourcing arrangements will shift from bottom-line focused (how can I get there cheaper) to top-line focused (how can I get there faster, better, and smarter). Customers will expect outsourcers to work with high-level requirements, and are becoming less interested in paying for effort, which may or may not translate into value. Think of developing software like how Apple sourced the iPod - "I want it to be 2x3, weigh 3 oz, and have 40gb of storage - you figure out how to get there. I don't care of you use 1000 man hours or 10,000. And I want you to share in the risk".
• A successful outsourcing relationship comes from mutual trust. Trust is built on openness with information, competence, honesty, follow-through, and benevolence.
• If you want success with a distributed team, humanity comes first. It's not the Golden Rule, it's the Platinum Rule: "Do onto others as they would have it done". Not "as they would do onto you". If the team was all like you, they would be sitting beside you. Did you hire the guy sitting next to you because he was the cheapest you could find? Do you talk face-to-face with them once a year?

Why do people find innovation so difficult?

Maybe it's because I'm attuned to it, but it feels like there is more and more being written in the business press about design and innovation. Business Week just did a profile on innovative companies, and this week spoke to Eric Shmidt about innovating at Google.

The last section of that interview sums up my thoughts lately about innovation. After Eric has talked about some of their principals, like listening to employees, allowing employees to spend 20% of their time on personal projects (and how it's policed, to make sure managers don't override it), the interviewer asks "Simple, no?". To which Eric replies, "But not often practiced"

Innovation takes courage.

Everyone reads the same articles and books about innovation and design. So why isn't everyone churning out great products? Because most people pay it lip service. They have a hard time putting a value on doing things like letting employees spend 20% of their time on personal projects, and they chicken out.

Take Proctor and Gamble. To fuel their growth, and to keep their product pipeline full of new compelling products, they set out to get as many as half of their products from external sources. Sounds easy, but P&G is known worldwide as an R&D leader. Do you consider yourself strong in R&D? Imagine the internal conflict in your company if someone said "you know, 5 years from now, I'd like us to be getting 50% of our new products from outside the company - maybe even from competitors". I'm told that even today at P&G, it's still tough, and they have internal debates about whether it would be better to develop something internally vs. going outside, but they don't falter.

Take IDEO. They are known as one of the best innovators on the planet. In fact, Fortune 500 companies hire IDEO to help get them get "unstuck". IDEO lets their employees structure their own workspaces as they need to to suit a project. Most companies would see this as chaos. IDEO spends time thinking about how to create workspaces that stimulate creativity. Most companies would think this is a waste of time. They encourage fun and play at work. Some companies would fire you for that.

So you see, innovation takes courage. Or to quote one of my favorite movies of all time, Glengarry Glen Ross, "You know what it takes? It takes brass..." Never mind...

Go watch a user use your product

Great post from Francis Beaudet, our Chief Architect, about when he first became conscious of design and usability. It was when he first saw a user trying to use a product he helped develop.

Go and watch a user try to use a product you've developed, or a web site you've designed, and see what happens. Give them a task to do - something your product was designed for, and see how long it takes them to figure it out.

To riff on Francis' post, I remember my first revelation about good design, but it had nothing to do with software (then again, when I started using a computer, the height of human-computer interaction was Zork). I was in high-school, and we were tasked with raising awareness with town council about accessibility. So our team borrowed a wheelchair, and tried to get around town and do normal things for a day - go for coffee, go to the library, and so on, and film it. Even places that were supposed to be accessible were nearly impossible to get to, and for silly reasons - like a 4" height difference between the end of a ramp and an entrance. That's when I learned the importance of thinking about who will use your product, and how it will be used. It came together for me later in systems design class in university, where I learned that accessible design and good design often go hand-in-hand.

Whether you're building software, a sidewalk, or a space shuttle, good design is universal. I consider myself very lucky to be working with a group of people that are experts in design.

So go find a novice user and ask them to complete a task with your product. You may be in for a surprise.

Outsourcing for Startups - A Conversation with Dhanya Thakkar from Third Brigade

A question I get asked a lot is - "I'm a startup - should I outsource development?". I blogged some of my own opinions, but I wanted to chat with some colleagues in startups who had successfully used outsourcing as a competitive advantage.

In this post, I chatted with Dhanya Thakkar, VP, Security Center, at Third Brigade. Third Brigade is a very successful startup that builds Host Intrusion Detection and Prevention products. Dhanya and his team have taken a very novel approach to outsourcing in a startup context.

Matt: Thanks for chatting with me today. As a startup, at what point in your growth do you think you are ready to outsource? What structure needs to be in place?

Dhanya: It depends on the management team. Some teams are not comfortable starting off right away, while others will have this in their business plan from the very start when they approach VCs. This seems to be more prevalent in Silicon Valley – its part of the pitch, and part of what investors expect to see as part of the diligence.

We started a little later. Part of the reason we didn’t start right away is that we are a Canadian company, and there are tax credits for R&D done in Canada which work in our favor. There was also anxiety about setting up an offshore team.

Matt: Tell me about those anxieties, and how you overcame them.

Dhanya: We had three main concerns. First, you hear about retention issues, and we had to ask ourselves how we’re going to manage retention, especially from such a distance. You hear that people in most emerging locations, there is little loyalty and a lot of attrition. Even if you hire outsourcing provider, rather than setting up a captive lab, you hear from colleagues that you can expect the team to change often.

The second concern is about intellectual property, and how you protect IP when you have a remote team.

The third concern was about the closeness to the team – actually this is something that came up several times. As a startup you want to be able to react to changing market dynamics, move quickly – how will you do this if you are outsourcing to team in India? How will you shape the product in the right direction?

Cost, on the other hand, is not usually the main driving reason nor a main concern. Most of the issues we were concerned about were more the soft issues.

Matt: In the end, I understand that creating a remote, offshore team has been very successful for ThirdBrigade. Tell me about some of the ways in which you overcame these concerns and built a successful offshore team.

Dhanya: Primarily, it was the model, and how we set things up. One model people use is you go set up your own subsidiary in India - you set up a an office, go through process of registering a company, and find a general manager. The second approach is to outsource, and go with the vendor who will manage a lot of that for you.

We decided to take a middle ground. We didn’t want to go through the hassle of setting up a company – we had a lot of other things to focus on. But we wanted the team to feel like employees, and to connect with the vision. We outsource, but in a very open-book manner. The vendor found the office space, found the facililities (internet connection etc), but they were the ones who were responsible for getting it all organized. The employees are, on paper, the vendor’s, but there are no other real ties other than that they are on the vendor’s payroll. We try to make them feel like ThirdBrigade employees. And that’s the part we work on the hardest. And for the most part they do. There are always some growing pains, but I feel like we’ve been very successful. How do we measure success? Retention rate is one. Our attrition rate is way below the industry average.

Matt: You need scale when you’re in an emerging country, both to make it worthwhile economically, and to attract talent. Your team is relatively small in India, right? But You’ve found a way to make it work it to your advantage

Dhanya: we started out with literally two people and scaled it up. You often hear that if you work with a larger vendor, someone like WiPro or Tata, that you need to be large, or you won’t be involved in the process - you won’t have the leverage. We decided on a smaller vendor, we wanted one who will work with us and be flexible. There were times when we needed to change how we were working – tweak the contract and they were more than flexible. Contrary to popular belief, I think it’s better to start small. It was our vendor who suggested to start small, and in hindsight it was the right thing to do, it allowed us to build and tweak things along the way.

Matt: Can you share some specific techniques to retain talent in a distributed team when you’re small?

Dhanya: One is communication with the team and senior management. We’re very transparent. We don’t treat them as consultants. Even though we’re a startup, the amount of info we share about our progress is the same as with the rest of the team. I travel once a quarter to meet with the team. Our SR VP travels every 6 months to see the team. With any offshore team, you require more communication than you do with your local team – it’s always needed.

Two is how you reward and compensate the team. Even though they are consultants they have the same stock options as the rest of the team. The compensation structure is also highly competitive even though we are small. We do quarterly bonuses and objectives along with salary. We also have retention bonuses – you are rewarded for staying longer with the company.

You get what you put in, and that’s something we try to keep reminding ourselves. There are a lot of horror stories about an outsourcing vendor holding you by the contract – so we try to keep the relationship at a level of “Look there are things you will need to do, and we won’t have time to adjust the contract. Just do the right thing and we’ll figure out the contractual stuff later”. There are times we’ve taken advantage of their flexibility, not the other way around, but they realize in the end it will be a win-win. Here’s an example - you could have a contract that says we have one Internet connection connection. But cable gets chewed up in the Middle East, and we needed a backup – you want a relationship where the vendor doesn’t wait to ask – they get a second connection to keep things running, because they know you will make it right. Treat it as strictly a business relationship, and it comes back to bite you eventually.

Matt: Typically, people think Big Design Up Front (BDUF) when they think offshore. Most startups operate in a more agile mode. How have you made this work?

Dhanya: For us, even if you have people working remotely from home, it’s just like that. We don’t see it India vs. Canada vs. whatever – they are our employees working remotely. We use the same processes, we don’t tweak anything. I’m not in favor of doing that, though I’ve heard that doing a bit more design up front will help in the traditional outsourcing model. It just doesn’t apply to model we have

Matt: What do you use for communication?

Dhanya: Frequent trips, phone calls, and LOTS of MSN. Some people hate IM, but with my team it’s the best way. A lot of time you want to assure them that you are there. A 30 second MSN conversation once a day can do wonders as opposed to an hour long call every month. But we are also on a plane a lot – I visit once a quarter.

Matt: What advice can you give a startup that wants to outsource but is worried about IP protection?

Dhanya: In our case there wasn’t much of an IP issue because the remote team wasn’t working on core IP. It really depends. With India, most of the outsourcing companies have been working with IP for a long time, so in India it’s not as big an issue as it is in China. That problem has already been tackled by a number of people in India. I would be not be an expert. The type of work we end up doing in India is very high-end/non-standard. Allows us to keep this lab going. We didn’t think we would be able to build such a team in Canada, given the type of the high-end skill we need. We could see this type of skill set available.

Matt: To close, can you summarize the how to outsource as a startup?

Dhanya: People say “can we afford (in terms of risk, time, energy, etc) to outsource”? In reality, people need to ask the question “can we afford not to outsource”. If you don’t, your competition will, and they will have an advantage over you - with the same amount of money you can either speed up development, or spend the money somewhere else. For us, the type of team we could build in India very quickly and efficiently gave us a very quick time to market. Even in startups, people have started exploring how can your 2nd level support, services, can be done in India. Also for some people, India is a huge market, so having an engineering team is a huge advantage – they turn the office into a P&L unit – they have sales, and engineering to support that – it can sustain itself really nicely. You also have some very large Fortune 1000 customers located nearby with whom you can vet your technologies.. As soon as people ask the question “can we afford not to”, the light bulbs go on.

Congrats to Fidus

I was happy to see Fidus mentioned in the Ottawa Business Journal this morning, having acheived another solid year of growth. Fidus has grown by providing complex, high-value electronic design services to customers all across North America. Though we're in two different areas - Fidus in electronic design and Macadamian in software design, there are a number of striking similarities. They work hard at pleasing customers and delivering quality, and that wins them a lot of repeat business. If you're ever looking for an electronic design firm, I recommend them highly.

Congratulations on another great year Fidus!

Building global teams

There's a great article in Inc. this month on building and managing global teams.

The author talks to two entrepreneurs with global offices, and reminds us how easy it is to forget about your remote teams, how much work you need to put into building ties between your home base and your remote offices, and how quickly things can fall into us vs. them if you're not careful.

Some of the best practices they discuss in the article include

• involving your remote team in product decisions and putting them in contact with your customers, instead of throwing work over the wall
• using a VoIP system, so that you're dialling an extension and not a different phone number to reach your colleagues in different offices (a subtle change that can make a big difference)
• lots of face time

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.

Should reviews weigh into your product design?

In software we pay close attention to product reviews. Let's face it, reviews influence sales, but to a degree. I think good design - good in the eyes of your target customer - matters more. Let me give you a couple of examples.

I have laptop envy for the new Macbook Air. I've always owned a Windows machine, but all the cool kids here in California have Macs, and they're growing on me. Especially when the guy sitting next to me on the plane and I opened our laptops at the same time. Me on WinXP and him with his Macbook. He was crunching sales figures instantly, while I waited another 7 minutes for Windows to boot and Outlook to start. But I digress. What held me back from buying a Mac was that they are so big (I spend a lot of time on the road), and the battery life (I know people who carry 3 or 4 batteries just to keep their Macbook alive for a four hour flight). The Airbook is light, the perfect size for travelling, has a great screen, is strong, and is just so sexy!

But the Air is getting lukewarm reviews from the experts, who say the reliance on WiFi was a bad idea. Where's the DVD-multi-CD-rewritable-superdisk-burner? What if I want to watch a movie in flight? Apple is betting on a wireless world, and their target customer is going to be more apt to download a movie from iTunes than watch it on a DVD, or pick the download option to install Photoshop rather than trek over to Best Buy, and I agree. The DVD drive, and even the Ethernet port, will be an anachronism sooner than we think. Apple had a vision for building the slimmest laptop in the world, not a pretty-darn-close-enough slim laptop with an Ethernet port.

I found this great quote in Tom Kelley's book, the Art of Innovation - "We learned that the public and even supposed experts are often not he best judge of which features need to disappear. Refining products is not a popularity contest. You have to take risks and you will alienate some people. For example, a number of reviewers criticized Steve Jobs for not including floppy drives in iMacs and iBooks. But they missed the point. The iMac was designed to catch the Internet wave, and a floppy drive would have demanded extra space, fattened the price point, and focused on soon to be obsolete technology. Jobs wisely decided that the machine couldn't look like something from the Jetsons yet be weighed down with eighties technology."

That was about the iBooks, which were released several years ago. How quickly we forget, but obviously Apple remembered the lesson well.

Here's another example. Last week I had the chance to rent a Prius for $1 more a day than a Kia. I've never driven a Prius and had to try it - I'll try anything once. You have to understand I'm a die-hard car guy, and the Prius is not exactly a car-guy-car. It's loathed in the hot-rod circles and dissed by the "serious" car magazines. Now, I do respect the planet, and I try to do my best to be conscious of the environment, but I have a serious car addiction. I have a mid-70s Pontiac with a 400 and a 4bbl carb, and no cats. You can actually see the gas gauge moving when you drive it. Every time I drive it, I'm sure I make a dent in the ozone layer and further the war. But I digress...

What did I think of the Prius? I loved it! It's a whole other kind of car geek fun. After I figured out how to start it (here's a crash course, so you don't have to look it up like I did: step on the brake, stick the key-fob into the toaster-looking slot in the dash, and press the On button. If the dash says "Ready", you're ready to go), I was having all kinds of fun trying to maximize my mpg - watching the little screen showing me when I was using the electric motor, and what my mileage was. I remember the auto journalists, like the guys at Car & Driver (admittedly one of my favorite magazines), were pretty down on the Prius as being full of gadgets. They much preferred the more mainstream-looking Honda Civic. Well guess what? In 2007, Toyota sold about 181,000 Priuses. Honda sold 32,000 Civic hybrids.

What did Toyota know that the reviewers didn't? 1) People wanted to feel like they were driving an electric car with a small gasoline motor, not the other way around - the On button and all the gadgetry makes you feel like the Prius is really an electric car, and the gas motor is just along for the ride. And more importantly, 2) People who drive Priuses want the world to know it. Dammit, you're saving the planet, and guys like me chewing up 10mpg should feel ashamed for not driving one also. It should look and feel like a Hybrid, not like a Camry with a little Hybrid badge.
So take what the reviewers tell you and put it in the mix, but don't rely on it as the gospel, and as a substitute for observing users, prototyping often, taking chances, and failing quickly.

Why Silicon Valley is still the hub of innovation

Great article in the LA Times today called "Come for Brunch. Bring Billions", about the Founders Brunch a regular, invite-only get-together of deal-makers and entrepreneurs that takes place in the SF Bay Area.

Lots has been written about innovation and entrepreneurship in Silicon Valley. This article really nails what I think are the top two reasons why the Bay Area is still the center of the tech universe - a culture and climate that rewards risk-taking, and the network effect. I've done business (in technology) now in Ottawa, Boston, Los Angeles, and Silicon Valley, and I've never seen such a strong and open network, and such openess to taking risk.

People think BIG in Silicon Valley. They aren't out to start a company to play it safe, they start a company to change the world, or at least the way people do something, and grow exponentially. And some do, and others fail spectacularily - but the big difference is that's ok. Failing means you're thinking big and you're trying. Many of the ideas that take flight in the Bay Area (and many that become huge successes) would be laughed out of the boardroom everywhere else - dismissed as crazy. How many people said "no-one will watch user-generated video content - what a waste of time"?

I've also never experienced such a strong network. Groups of engineers and entrepreneurs have been meeting since the 60s here. Go to a networking event in most areas of the country, and people are cliqu-ey - reluctant to talk and reluctant to share their network. In the Bay-Area, everyone is keen to chat, if even only for a few minutes, as everyone's on the lookout for the next Big Idea, and everyone seems to understand that even if you don't have business to do today together, you might know someone who might be able to help and visa versa.

To echo Peter Thiel's quote in the article, there are lots of cheaper places to set up a business - that's why people still set up in Silicon Valley.