Author Archives: Mike

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.

Advertisement
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
Dec 06 2011
5 Comments
Offshore Software Development

Offshore Software Development in Eastern Europe (Part II)

Here is part II of my post on software development offshoring in Eastern Europe.  Let’s talk about some of these Eastern European countries in a little more detail.  Based on my last post, I think the following are the most interesting countries if you are cost sensitive, and are looking to locate somewhere with a good critical mass of software engineering talent:

Ukraine – Ukraine has the most developers of any of the countries shown in the table in my last post, and the costs are reasonable (although the costs have been rising continuously, with a few lulls, for the past decade).  I’ve been working with software development teams in Ukraine for over a decade now, and I’ve seen very good results.  Politically, it’s a flawed democracy.  They had the Orange Revolution back in 2004, and everyone was optimistic about the future, but there’s been some backsliding lately and people are generally pretty cynical about their politicians.  No shit, right?  OK, but I think people’s cynicism is even worse than in the USA.  I think it’s better than Russia, in the sense that they actually had a peaceful transition of power in the last presidential election, but there’s still some doubt about how it’s all going to work out.  And every couple of years there is some dust-up with Russia during the winter time, and the Russians threaten to shut off the gas and make half of Europe freeze.  (I was planning to go to Kiev one time when the Russians were threatening to shut off the gas.  I asked a Ukrainian colleague if I should be worried about coming over there during the dispute, and he said “Don’t worry, they’ll steal plenty of gas ahead of time from the Russians!  It will be fine.”  Sure enough, my hotel was warm during my stay.)  How does this affect you if you’re going to do some software development in Ukraine?  Not much, in my view.  In a weird way it might even be an opportunity.  With former PM Tymoshenko in jail, and Yanukovich in power, Ukraine isn’t joining the EU any time soon.  So rates for software developers should continue to be below those in Poland and other EU countries.  Unlike Belarus, the government doesn’t seem to have as well-thought out a strategy for attracting software-based businesses, but plenty of name brand named Western companies are doing development in Ukraine these days.  It’s a far cry from the early 2000’s when I first started visiting Ukraine.  There were not really any big shops back then and maybe I was deluding myself, but I felt that with 15-20 developers we were a “player”.  Now I hear that Luxoft has around 3,000 developers!

Belarus – For quality of developers, “critical mass” of developers, and cost, Belarus rates very highly.  If you compare it to, say, the most economically advanced countries in Central and Eastern Europe, Belarus is around 17% less expensive (see my previous post), and the quality of developers is strong.  People claim that Minsk was one of the top three “technology centers” in the old USSR, alongside Moscow and St. Petersburg, so it has a legacy of producing good technical talent.  (Interestingly, people claim the same thing about Kharkiv, Ukraine, so I take these claims with a grain of salt.  But, anyway, the point is that you can find good developers in Belarus, and in Kharkiv for that matter.)  Additionally the domestic IT market is relatively small in Belarus, so this leaves a good supply of developers available for the IT export market.  The only problem with Belarus is that it’s the last dictatorship in Europe, so this tends to make people nervous about investing there, since it looks like the place is sure to see some political excitement over the next few years.  If you invest in Belarus, you are hoping that they can have a “velvet” or “Orange” transition of power, with a minimum of violence and disruption.  Even though politically it’s a basket case, Belarus has apparently created efficient legal structures and a “Hi Tech Park” that facilitates the creation of software-based businesses.  Additionally, the tax system for IT companies is quite clear, and advantageous.  This means that companies can focus more of their energies on software development, and less on figuring out how to deal with the government, which is an issue in other Eastern European countries.

Romania – I know less about Romania but have heard some good things about it.  From the numbers, the cost is bit higher than Ukraine or Belarus, but still much lower than Poland or the Czech Republic.  But if you value the idea of being in the EU, and having legal and IP protections that are at the EU standard, you might be willing to pay a little more to get that.  Romania’s not quite the lowest cost EU country in the table—that’s Bulgaria –but it has a good combination of cost and critical mass of software developers.  So I’m going to put it on my “up and coming” list and try to check it out in a future trip to Eastern Europe.  The flip-side of being an EU country, though, is that we might see wages converge with the other EU countries over time.  And you need to adhere to EU labor standards, so it’s not as easy to dismiss bad employees.  The other issue is that the people in Romania are now more mobile, since they can take jobs in other EU countries.  So your key developer can leave and take a job in Germany tomorrow.  This risk is lower in Ukraine or Belarus, which are not EU countries.

OK so what about that other Eastern European country that isn’t on my list?  Lithuania?  Albania?  No, I’m talking about Russia.  Of course, Russia does have plenty of software developers (and credit card scammers, virus writers, zombie network owners, etc.) and has even produced some software innovations of its own (e.g., Kaspersky Labs), but right now it’s not as popular an offshoring destination as the other countries on my list.  For one thing, it’s more expensive than other Eastern European countries.  The oil sloshing around in the economy raises the prices of everything else—real estate, hotels, and software developers.  I’m sure you’ve heard that Moscow is the most expensive city on the planet to do business.  There’s also the issue of legal, IP, and property rights.  It’s doubtful that some Komisar could grab your IP.  What would he grab?  Your source code?  You’ll have that backed up in your home country.  Still, outside of the oil and gas sector, Western companies just aren’t interested in investing in Russia, since they don’t feel like ending up having their business stolen from them and ending up in a cage in some kangaroo court.  So despite the talent in Russia, it doesn’t make a lot of people’s lists as a viable offshoring destination.  Maybe they’ll get their act together one day, but there doesn’t seem to be much incentive as compared with other Eastern European countries that don’t have oil and need to spur investment in other industries.

Tagged
Dec 03 2011
Leave a comment
Offshore Software Development

Offshore Development – Eastern European Countries

I’ve been working with developers in Eastern Europe since about 2000.  Much of that experience has been in Ukraine, although I’ve had a chance to do a little work with a group in Belarus, and to benchmark software development options across Eastern Europe.  If you’re considering moving some software development offshore, here are some thoughts that might help you.

Central and Eastern Europe – Country Comparisons
(source: Central & Eastern European Outsourcing Association Report 2010)
Poland Hungary Czech Rep. Slovakia Romania Ukraine Belarus Bulgaria
Developer Rates (USD/hour)
Project Manager

40.45

37.62

36.67

34.1

38.24

32.02

29.14

32.95
Sr. Developer

37.19

37.62

36.67

34.1

31.7

27.71

26.05

28.11
Middle Developer

30.49

29.75

29

26.97

25.32

23.41

22.32

21.12
Jr. Developer

22.81

23.94

23.33

21.7

19.67

18.94

18.36

16.96
Blended Average

31.29

30.95

30.17

28.06

26.76

24.24

22.95

22.87
Number of Employees in IT Outsourcing

9,200

9,600

7,800

2,800

14,200

18,100

10,400

8,700
1 year growth in IT Outsourcing Staff

1,500

1,600

500

200

1,800

2,300

1,200

800

Take a look at this data, which you can find on the web site of the Central & Eastern European Outsourcing Association.  My experience is that this data is fairly accurate, which isn’t a given with secondary sources such as this.  It reveals a few interesting facts:

1)      The prices in the countries at the less expensive end of this table will look familiar to those of you who’ve done work in India.  Software development talent now exists in a global market, and it’s a pretty efficient market.  The Central and Eastern European countries that have their act together economically, for the most part, such as Poland and the Czech Republic are going to cost you more.  These countries are part of the EU now.  The costs are actually a bit higher than they look in those countries since you need to adhere to European labor rules and pay European-style payroll taxes.  But you get something for that, which is the relatively high stability of those countries and an improved ease of doing business vs. Ukraine or Belarus, for instance.   You also get court systems and IP protection closer to what you are used to getting at home.

2)      The highest concentration of talent is in Ukraine, Romania and Belarus.  The numbers of people in IT outsourcing strike me as too low (I think these numbers are probably just people working in offshoring shops, focused on the US and Western European markets, not captive centers run by US and European companies, or companies serving the local markets).  But they still provide a relative sense of which countries have developers and which ones are producing more each year.

3)      So assuming you want to be working in a country with a low cost and a high concentration of developers, and one which is producing more developers each year, you might want to look seriously at Romania, Ukraine, Belarus and Bulgaria.

Tagged
Nov 20 2011
Leave a comment
Cloud Software, Supply Chain and Logistics Technology

Cloud Software – 4 Step Plan

I’ve had a chance to do some thinking about what it takes to make a good cloud application, or even a good cloud software company.  Here, when I say “application”, I’m talking mainly about business applications, since I know more about those than about consumer apps.  But I also think that those of us who’ve worked more on the business applications side than on the consumer technology side can learn a lot from looking at consumer apps—this is where the trends are coming from, since all of your users are using iPhones and Amazon.com, so if your business applications don’t make sense for someone who has Amazon-like expectations, you’re going to have a problem soon.

So here’s a 4-step program for cloudifying your software company.  In short, you need to combat everything that sucks about traditional business applications.  Traditional enterprise systems are bloated with too much functionality, take too long to achieve value, cost too much, and take too long for the vendor to sell.  The implementation of these systems is akin to corporate root canal (I’m not the first one to say that—people seem to think the Wall Street Journal said it first, but I couldn’t find the article), and the risk of failure is significant.  This lengthens the sales cycle, and for a long time has been curtailing innovation in the software industry, since buyers wanted to play it safe and do what their colleagues were doing rather than be innovative, because the risks to their careers were too great if a major project failed.  So, given all of this, here are my four steps:

1)      Simplify the product – Ever used Basecamp?  The guys at 37 Signals took at look at MS Project and decided it was a bloated piece of crap that didn’t actually help you to…ummmm…manage projects.  So instead, they provided a bare-bones project management tool on the web.  They don’t provide fancy functionality such as letting you model the resources assigned to a project in order to “load balance” it.   (Ever tried to do that in MS Project?  Every time I’ve tried, I ended up determining that my project would get done in 2025 unless everyone worked 24 hours a day, in which case you could bring it in a couple of years.)  So your typical Project Management Office guy is going to think it’s a joke, because he went to the PMI course and they gave him a lot of fat binders that don’t look like Basecamp.  All Basecamp does is provide the ability for a team to collaborate over the web on a set of tasks.  That’s enough for a lot of people, and not just small company people.  Lots of individuals in larger companies use Basecamp too, and they just put it on their corporate credit card and expense it, completely circumventing their IT departments, who probably don’t even know it’s being used in the company.  So it turns out there’s a market for stripped down, simplified cloud services, and often times, less is more when it comes to business applications.

2)      Speed-up the time-to-value and remove barriers to adoption – A great example is Mint.com, the personal finance service.  These guys just nailed one thing, and as a result they sold the company only two years after its founding to Intuit for $170 Million.  What they did was to remove barriers to adoption (as compared with traditional solutions), and in the process reduced the time for the customer to see some value.  When Mint.com first appeared, their main competition was Intuit Quicken.   With Quicken, electronic banking was not supported for all banks, it was a pain to set up (as I recall, you needed to wait for something to happen at Citibank, so they could approve Quicken access to your account, and this could take a few days), and Quicken couldn’t access your brokerage accounts.  Even more annoying, you had to enter some transactions manually, and try to match them up to what was going on in your bank account.  Finally, the amounts Quicken thought were in your accounts would never quite match what was really in them, because you got some dividends from IBM and couldn’t be bothered to enter them into Quicken manually.  All of these things made it difficult to use Quicken and get any value out of it.  By contrast, if you logged into Mint, 15 minutes later you were staring at your total net worth on one screen.  Depressing, yes, but it was also amazing to users, who were able to see something useful right away.  With people using sites like Mint in their personal lives, users have little tolerance for applications that take a long time to show value.

3)      Think Freemium – Most great cloud services let you get started cheaply, or even for free.  This removes the risk for the customer that the damn thing won’t work as you expect, which is a very real risk with traditional enterprise software.  Dropbox is a great example of the “freemium” model.  They let you start out by storing 2 GB in the cloud for free.  They are betting that you’ll see value from the service quickly (point 2), dump a lot of files in there, and soon you’ll be paying for the service.  Well, it’s working.  I’m trying to figure out why I’d want to store things on my hard drive, rather than Dropbox.  The files look the same in Dropbox, except I can access them anywhere, which is really useful since I prefer to use my desktop at home, my laptop on the road, and sometimes a client gives me a PC to use when I’m at their site.  So anyway, back to my point—hook the customers for free and then charge them.  Just as in point 2, we want to remove barriers to adoption, and if we give the user a free trial, we’ve just knocked down one of the traditional barriers to the adoption of enterprise software—the high up-front cost.

4)      Rethink the Sales and Implementation Model – I need to credit Mark Benioff for this one.  The guys at 37 Signals also touch on it in their book, “Rework”, which is great if you haven’t read it.  In Benioff’s book, “Behind the Cloud”, he describes how the conventional wisdom in the enterprise software world is that you need a “bag carrying” sales force to sell the stuff, because it’s a big investment, the time-to-value is long, and therefore the customer is going to make the decision slowly, be risk-averse, and it’s going to go up to a high level in the customer’s organization for approval, which it turn further increases the lead time to make the sale, and not incidentally, the cost of sales for the software company.  And these high costs need to get paid by guess who?  In the end, the software buyer needs to pay for all of this, so it again reinforces the long decision cycle, with the sales process managed by “enterprise” sales people.  Benioff turned that conventional wisdom on its head, and found that “inside sales” (i.e., telesales) works for cloud apps.  It works because the up-front commitment the customer needs to make is low, so lower level managers can make a decision on the purchase, and since there’s little risk due to the ability to try it for free (point 3), and the time-to-value is quick (point 2).  So Benioff started out with telesales, and it worked, but a funny thing happened next.  Larger customers started buying Salesforce, and now with Force.com, you have a framework for customizing the platform.  So now you’ve got Salesforce Value Added Resellers (VARs) who are out there implementing customizations to Salesforce, which is a little like the traditional enterprise implementation model where VARs, consulting firms, and the vendors themselves would send high-priced consultants into the field to configure and customize the system for you.  But I don’t think it disproves the point—the sales and implementation models change with cloud software, and you need to move towards telesales and tele-implementation (a support team that works through a customer’s implementation issues over the phone and the web, rather than by using a traveling army of IT consultants).

The great thing about cloud applications is that they are opening up all kinds of opportunities to innovate, in a sector that’s been hidebound for the past decade.  Look at the supply chain software space—the companies that invented supply-chain software were innovators in the 1990’s–best-of-breed players who created the first transportation management systems, supply-chain planning systems, and warehouse management systems.  But in the 2000’s it was hard to be an innovator.  Customers were hesitant to take a chance.  “What if the system doesn’t work as advertised?  Do we really want to sign up for a long and tough implementation with an upstart vendor?”  Today, the cloud is changing that by reducing the costs and risks of going with an innovator.  That’s better for customers and better for software vendors as well (at least the innovative ones).

Tagged ,
Nov 17 2011
Leave a comment
Uncategorized

Blogging

I’m going to start an occasional blog where I’ll put out a few ideas on subjects that I care about and think I know a thing or two about: supply-chain technology, cloud business applications, technology strategy and software development (particularly offshore development).  Now and then I might also comment on random topics about which I know much less, such as why ITunes is a hairball (sorry, Steve), why Dropbox is great (but why it’s going to end up costing me a fortune one day), why I don’t “get” Groupon, and why I “get” Twitter (although I don’t care to use it).

Newer posts →