Category Archives: Agile Development and Lean Startups

Feb 16 2012
Leave a comment
Agile Development and Lean Startups, Offshore Software Development

Best Countries for Offshore Software Development (Part III) – Cultural Compatibility

This is Part III of my post on a how you might think about determining where to locate your offshore software developers.

I started in Part I with the Gartner list of top 30 IT offshoring destinations, and have been critiquing the applicability of Gartner’s ranking criteria for software development, as opposed to more general IT services tasks.  Gartner has a criterion they call “cultural compatibility” that they use in rating the various countries.  It’s one of ten criteria they use, but I’m wondering about its applicability in a “flat world”.  Gartner doesn’t define cultural compatibility in much detail, but they say it involves “adaptability to multicultural approaches to support an international business environment”, and they also consider the time zone of a country, ease of travel to a country, and its proximity to the major home countries that purchase offshore development services.

Some of the potential attraction of South American countries (at least to a North American company contemplating doing some software development work offshore) is their cultural compatibility with the US (that, and the closeness in time zones to the US).  So what about it?  Should you consider cultural compatibility?  I think so, but it might depend on the software products you are developing.  I had a chance to visit South America recently, and one Argentine software development executive noted that “we watch the same TV shows”.  I don’t think watching CSI is going to make a developer more productive (but CSI Buenos Aires might be a show I’d watch!), but of course that wasn’t his point.  What he meant was that, with some common cultural understandings, Argentines could communicate well with Americans and more quickly gain a common understanding of what a project was about or, in Agile terms, what a user story meant.  That’s worth something.  What I’ve noticed is that when the project at hand is consumer-related, an Argentine firm might arguably have a better understanding of US consumer society than developers who live in farther-off time zones.   I met with the head of an Argentine software development company last week and it struck me that his client list is very strong in advertising agencies, social media, and other consumer-oriented work, although they do work on business applications as well.  In my case, I’ve spent most of my career developing business applications where developers learned the domain over a period of years, by working with their US counterparts.  They didn’t come with an innate understanding of the business processes related to that domain (logistics) any more than a US developer does.  So in cases such as this—business applications—I’m not sure culture is as important as training your developers on your domain, and finding a way to have a low turnover so you don’t fritter away the investment you make in training your people, whether they are your own staff or those of an offshore development company.

Let’s talk about work habits, which might be one aspect of “cultural compatibility”.  Something I’ve heard more than once from US senior managers is, “…those Eastern Europeans are still shaking off communism, so how do you get them to work hard and show up every day.”  Look, the Berlin wall fell in 1989.  That’s almost 23 years ago.  In Eastern Europe, your average developer is probably going to be about 28 years old.  So the residual effect of communism on the average developer’s work habits is going to be negligible.  Now, it’s true that bureaucracy continues to smother some of the less economically advanced economies in Eastern Europe (and for that matter, most major offshore destinations, such as India).   As an example, I pointed out in my last post how difficult it is to pay your taxes in some of these countries.  So bureaucracy is something you are going to need to deal with if you operate in those countries.  But in my experience it has no bearing on your developer’s commitment to their jobs and their companies.  If you can motivate them with interesting projects they’ll show up for work, try hard to understand your business and work hard to deliver (at least they will if you’ve recruited well).

In the long-term, I think it’s clear that the world is becoming flatter, and cultural factors may be less important when considering where to offshore, although it’s still a factor now.  If you travel in these countries, you’ll see that everyone is on smartphones, using LinkedIn or Facebook (or their own local variants of these networks), so people are slowly growing more similar, not more different (at least when considering the major offshore development destinations, as opposed to, say, Saudi Arabia).  Many years ago, I worked on a consulting project with IBM that involved some work with an R&D lab in France.  Over and over, cultural differences came up.  I think both the French and the US teams respected each other, but there were differences in how they approached development projects and in the processes they used to make decisions, and resolve issues.  Today, methodologies like Agile are providing people with a common language for developing software.  It’s a global language, and with more and more projects being developed across multiple sites and countries, people are developing a common understanding of that language.  An Agile “Product Owner” is a Product Owner, regardless of what country they are located.  Sure, people will bring their own cultural backgrounds to roles such as this, but I see the importance of these differences declining, as least as it pertains to software development.  Twenty years ago, the idea of developing products using mixed onshore-offshore teams was daunting.  Now, it’s commonplace.

Advertisement
Tagged ,
Jan 12 2012
1 Comment
Agile Development and Lean Startups, Offshore Software Development

Is there a US Developer Shortage? Why Going Offshore is Just a Matter of Time

If you have a small development team of a dozen people, or fewer, you can probably do fine developing all of your software onshore.  It might even be the right call, provided you can afford it, since at that point you might just be figuring out what your product really is, and it’s better to work with developers who sit with “the business” and are able to react quickly to what the business is seeing in the marketplace.  Or you might need some specialized skills that just aren’t available offshore.  Sometimes if you’re working with the latest of the latest technologies, or something a bit arcane, then you might have trouble finding that skill set offshore.  Or, if you need some awareness of the business or social environment in your home country, then people at home would have a better intuitive sense of what you’re trying to accomplish.  For example, if you’re building a social media product for bar-hoppers in US cities, you’re probably best to develop version 1.0 as a “Lean Startup” with 2-3 developers in a major US city, since you’re going to have a tough time explaining to offshore developers exactly what your product vision is.  And if you try to explain it, they’ll most likely give you a product that doesn’t fit the bill, and tell you that “you kept changing the requirements” (and they’d probably be correct about that).

But at a certain point in your company’s life, assuming you are above a certain scale and size, you’ve most likely got to do some work offshore.  Of course there’s a cost argument.  Loaded costs for developers at an outsourcing shop in India are around 50% of the costs for comparable people in the US.  And if you have the time and knowledge to form a “captive” offshore development shop, you might save more than that.  But apart from cost, it seems there just aren’t enough software developers in the US to meet the demand anymore.  There’s a contrarian point of view regarding this, and you can hear it from commentators like Ron Hira, who claims that actually there is no shortage of developers in the US, and when companies go offshore they are just looking for low costs and there’s no supply issue when it comes to developer talent.  In some of his other articles, Hira makes some good points about the H1B visa program in the US which, while generally positive for the US, has been abused by some of the IT outsourcing firms to bring in undistinguished talents, and pay them below the US norm.  But in this case, I think Hira’s work suffers because he lumps all IT workers into one big bucket.  I’m not talking about a shortage of generic IT workers.  But if you need to hire highly skilled software developers, who are current in the latest web and mobile technologies, and who are the best in the world at what they do, there is data that shows that there is a shortage in the US.

The Wall Street Journal recently reported that there are over 150,000 openings for software developers in the US right now.  Intuitively that sounds a bit high to me, but there’s no doubt that there are major shortages in some key areas, such as mobile development—who isn’t thinking about their mobile strategy these days?  And in certain areas of the US, there just aren’t enough people in the region engaged in software development, and if you need to hire a few experienced Java developers, it turns out to be quite difficult.  If you’re looking for these people in quantity in the US, and your company is not called Facebook or Google, you might be fighting a losing battle.  So you might be better off offshore, where you can raise your wages a bit above market and attract some strong talent.

Is that the future of work in the US?  Is all of the software going to be built offshore, while those of us living in the US will all be “idea people” (and burger flippers and retail clerks, I suppose)?  Do we need to encourage more American kids to study “hard” subjects like science, engineering and math as their college majors, in order to make us more competitive as a nation?  One would think that the market would signal the need for more developers through rising salaries, and more people would respond to those signals and would study disciplines like computer engineering and computer science in college.  Good luck with that.  The problem is that the dogs (students?) just aren’t eating that dog food.  A recent study reported in the NY Times found that students drop out of these “hard” subjects in droves.  It’s not exactly clear why this is the case, but it seems to have something to do with these courses of study being something like the Bataan death march.  It seems for most American kids, the prospect of $60K+ starting salaries for entry level developer jobs just doesn’t justify having a shitty undergraduate experience, just when they are spreading their wings and getting out of the house.   Apparently President Obama set a goal of graduating an additional 10,000 engineers per year.  But if you believe the experts (at least the one guy quoted in the Times article), that’s just not gonna happen.  Even if we got to 10,000 additional engineers per year, and we peel away the civil and chemical engineers, and others who can’t help us close our 150,000 person software developer gap, then it would appear that our gap wouldn’t close for years anyway.

I don’t really have a realistic “three-step plan” to solve this software developer gap in the US, and I’m not aware that anyone else does either.  But I think it’s a real gap, so for the foreseeable future the only way US companies are going to get the developers they need is through a mixture of offshore and onshore software development.  So we might as well just admit this and figure out how to be great at managing mixed teams of onshore and offshore developers, probably using Agile-type processes.  I’m not of the belief that there’s no future for US developers.  It’s just the opposite—there’s plenty of demand for them.  But there just aren’t enough developers with the skills we need onshore, so companies above a certain scale and size need to think offshore.

Jan 04 2012
Leave a comment
Agile Development and Lean Startups

Agile and Lean: Good Partners in Software Development

I’m a fan of Agile software development.  But there’s one big thing that bugs me about it.  The underlying assumption seems to be that the business knows what it wants, and can articulate the required “user stories”, and prioritize these correctly.  And that even before we talk about user stories, Agile assumes that the business people are pointing the business in the right direction, strategically, and that your product roadmap is more or less correct (at least at a high level), and so the adjustments you make at the start of each sprint are pretty incremental to the company’s overall product strategy.  Well, that ain’t always the case, and I’ve seen a lot more money wasted by the business being incapable of settling upon workable and consistent strategies, than by software developers who write bad code.  So using your product development efforts to validate the direction in which the business is driving is vital, particularly in cases where the business is unable to prioritize user stories correctly because there’s so much uncertainty about the business direction and strategy.

I like Eric Ries’ “Lean Startup” approach in cases like this.  Ries says that when you are in startup mode (and in his definition of startups, he includes any team that is trying to fire up a new business concept around a software product or service, so you could include teams working in larger companies who’ve been given this challenge) the business typically has little idea what’s going to work and what’s going to fail.  They may think they do, but the reality is they may be mucking around in the right area, but they don’t know what will work, and their chief assignment is to learn what works and what doesn’t, and what is important to customers and what isn’t.   In Ries’ view (and I agree with him), you don’t go out and do some market research to find out the answers (at least not right away), since if you’re inventing something very new the people you interview will have no idea what you are talking about and might mislead you.  And you don’t get senior management in a room with a white board to map it out either, since they may have known enough to get the startup funded, but don’t know all the answers either.  Instead, Ries tells you to perform a series of rapid experiments with customers (and prospects) and figure it out scientifically.  You test how users respond to a feature, and whether they use it.  If they don’t use it, then go talk to them–find out why.  Now you can have a useful discussion with them, not a theoretical discussion.  If nothing’s working, you might need to consider pivoting towards a new strategy that (hopefully) will work better.  But ideally, make any adjustments or decide to pivot as soon possible, so you don’t spend two years “perfecting” your product based on your own ignorant idea of what the product will be, only to have customers later tell you that you were way off target.  Even if your idea was mostly right, it will benefit from some contact with the customer as soon as you can get this.  If your idea was mostly wrong, it’s best to learn that before you waste a lot of time and resources.

OK so if you buy the idea that being a startup means you need to do the best you can to have a rapid feedback loop from learning something in the market, to implementing some changes in your product based on those market learnings, you’re going to need to invest to develop your product in a way that supports that learning process:

1)      Build an infrastructure for running A/B tests on users (Ries’ approach sounds a bit consumer-oriented, and not enterprise software-oriented, but we can take some inspiration from the idea and find ways to apply it to an enterprise world)

2)      Ensure you gather useful metrics on user behaviors, so you can analyze what they really did with the product, and have objective discussions about what’s working and what’s not

3)      Have a capability for frequently deploying incremental new releases (e.g., test automation is going to be critical here)

4)      Have a process that supports quick reaction to market feedback (in terms of feature prioritization)

When you consider these factors, 3 & 4 are provided by an Agile process, but 1 & 2 really aren’t.  Agile doesn’t provide an approach to figuring out your strategy, and quickly testing what’s working and what’s not when you are in startup mode.  And Agile doesn’t tell you that you need to do experiments on customers to figure out what they want, and what they are willing to pay for.  When you’re in startup mode, learning those things are the most important things you can do in order to apply your resources to what’s working.  Unfortunately, Agile doesn’t really tell you that.

So if you have a relatively mature business, and you’re not in startup mode, you don’t really need to be Lean.  You understand, more or less, what you’re doing, and you can run an Agile development process with a backlog of requirements, and prioritize user stories at the start of each release cycle, and be relatively confident that you’re going to add value with each release.  In fact, you’ll be much more confident than if you were using a waterfall-type process.  Even if you mis-prioritize the requirements in one release, there’s another release following soon after, so you’ll get to those requirements then, and it’s not a disaster.  But if you are starting up something entirely new, whether it’s an entirely new company, or a new product line for an existing company, and you can admit that you don’t know what’s really going to work, and whether customers will even buy the product you envision, then Agile isn’t sufficient.  A Lean approach and an Agile development process are complementary and support each other, and you’d benefit from using both.

Dec 14 2011
1 Comment
Agile Development and Lean Startups, Offshore Software Development

Agile Offshore

Everybody wants to be Agile these days.  And what’s the alternative?  Being hidebound?  Unresponsive?   Inflexible?  On Synonym.com they even list “stupid” as an antonym of “agile”.  All of the opposites of “Agile” sure sound like words I don’t want associated with my software development process.

When I first heard about Agile software development, it didn’t sound all that revolutionary to me.  While you still find pockets of waterfall software development processes out there, I think most forward-looking people recognized a few years ago that waterfall processes exhibit a poor reaction time to market feedback, and that these processes have a fundamental assumption that is demonstrably false: that you can know with certainty the requirements for a project at the very start, and that those requirements won’t change over time.

Most of the techniques used in Agile development have been gaining ground for the past several years–-incremental development based on a backlog of requirements, doing frequent releases of a web software product, being hard-nosed about the scope of a release since there is always another release coming soon afterwards (so new requirements can be accommodated then), and, crucially, trying to better connect developers with “the business” (for some reason this use of the term “the business” always bothered me, so I feel obligated to put it in quotes.  I guess my issue was that it wasn’t always obvious who “the business” was, and I often wondered why the business wouldn’t answer the phone and give me answers on how to prioritize projects.  It reminds me of Henry Kissinger’s quote about Europe: “Who do I call if I want to speak to Europe?”).

But I have to give the guys who coined the name “Agile” some credit for packaging up some good ideas that had gained currency, and creating a kind of rallying flag that developers, product managers and “the business” could rally around, and say, “we need to be Agile.”  So now you have a whole Agile industry: Agile books, Agile training (Agile Academy has some videos that serve as a nice intro to the Agile concepts),  Scrum Master certification courses, and job descriptions that say candidates need Agile experience.  And of course there are Agile conferences and all of the associated conference schwag (check out AgileEE in Kiev!  I’m too cheap to attend the conference but I’d love to get one of the t-shirts).

In the offshore development world, it seems that Agile has really caught on.  I had a chance to visit some South American offshore software development companies recently, and the CEO of one service provider really nailed what’s driving this.  He said that “wherever possible, we’ve moved to an Agile process with our clients.  This is how young people want to work these days and using Agile allows us to attract developers.”  So he wasn’t merely listening to his customers, who wanted to use an Agile process.  He was pushing an Agile process on his customers because his developers wanted to work that way.  Developers don’t like working on features that don’t get used, and it drives them crazy working on a large project that’s completely off the mark due to poor initial requirements definition.  So an Agile process offers developers some hope that their hard work will actually hit the mark.

Using an Agile process with your offshore software developers requires a few adjustments.  You can’t do an in-person scrum meeting each day, of course.  But Skype or teleconferences can be used.  While I’m not of the view that each and every offshore developer needs to speak perfect English, your team leads will need to speak good English to allow this daily communication between the various project team members.  One tenet of Agile that isn’t always followed religiously when using offshore development is holding a demo for the business at the end of a sprint.  When I asked my various Agile hosts in South America whether they really got the business to watch such a demo, the answer was often “no, but we do the demo anyway, for ourselves,”  and sometimes for a Product Manager located onshore who acts as a proxy for the business.   So connecting with the business is still the weak link in these processes, and it’s even more challenging when you are using an Agile process offshore.

Tagged