robjam.es

Often we find the challenge of turning an idea into reality quite daunting. And rightly so, its not easy. But the fact is, if you apply a) a process, and b) the discipline, you can get this done.

The discipline is difficult and really up to you, but the process can certainly be challenging, and this is something I can hopefully help with. Before we get into a process (which I am going to keep simple for this first post), there are some principles that you should also keep in mind. If you have ever heard me speak, these are the principles that I always go on about, and here they are in an abridged version;

• Keep the idea simple, you may have grand plans for it, but what is the simplest thing you can do to get into the wild. I call this your Minimal Success Set. Which is the minimum amount of features that you can apply to your product for it to be called “a product”
• Don’t worry about problems you don’t have. You will start thinking into the depths of the different challenges you might have, but if they are not holding you up now, don’t worry about them. In fact, this is the best time you don’t have to worry, and you can start building, because you are starting from a fresh slate.
• Can you operate or support the application when you go live? Think through the details of what happens once you get it into the wild, will there be human processing that will need to occur, even emails that will need to be processed. You need to consider what the impact of this would be. I once worked on a project that required human intervention to process every subscriber’s content on-line. Seemed like a great idea, and the impact was 30 minutes for each account. But when we analysed this, I could only process 16 subscribers per day, but that meant I was just processing subscribers, and the costs were not significant enough to hire someone. So I had to re-engineer this concept real damn quick!

There are many other important principles, but these three are the good ones to consider when starting out. The next step is to have a process; and by the way, the process will help you with your discipline, because you will see a solution to deliver a product.

The below process is based on a more detailed 9 step process (which I am going to publish in the next few days). This subset is a great start. The first 6 stages focus on the areas that a product manager would be concerned about. The last three are more technically driven. All-in-all, this is what I call a top-down or user centric process, which not only works really well, but is also accepted as best practice these days.

Here are the 6 user centric steps in the process, with some detail;

1. Brainstorm to firm up the concept.

You have an idea, now you have to make sure that it is valid. I am assuming that your idea has a commercial benefit, so you therefore need to make sure that it is commercially viable. This is also the time that you want to try and take the steps where you minimise what you are going to deliver, and start doing some thinking about how the customer will interact with your application. Start to answer the questions like; what will this thing do (and NOT do) in the first release? How will it make money? How much of my time will it need after it is launched? What kind of customers do I want, and therefore, what is my product’s personality? Minimise, minimise and minimise again, until you get down to what the absolute basics of the application are.

2. Write a scenario

Earlier this week, I wrote a post on how to write scenarios, they are extremely useful at this stage. They describe your users and the process they would go through on your site in plain English. It is essentially a creative writing piece. You come up with a model for your user, you then describe in a step-by-step format on how the user will accomplish their goal. A scenario models only one path, usually the most common path a user will take. And often can include the intention of multiple users. Don’t omit this step. Scenarios are fun to write, and because they are usually not constrained by technology are generally going to be the best experience that a user can have in the application. When doing the next steps, you always come back and compare it against your scenario.

3. Sketches

Use paper, whiteboards or software tools if you are comfortable with them. Start to sketch out how the screens will work. Try and put as much detail as you can, but also try and minimise as much as you can. Don’t skimp out! It is so easy to say “and after the user clicks the submit, they see a confirmation screen. We don’t need to sketch that – its straight forward!” No its not!!! You are a) leaving yourself open to interpretation and b) not apply consistent behaviour. If you assume that the confirmation screen is just another screen, what purpose is it really providing? Just another screen? What can the user do here? How do they get back? Can we just show the same form with a confirmation message? Can we show a details page with a confirmation message? Could we simplify with Ajax? until you actually do it, you don’t know. Remember, it is easier to screw up a piece of paper than to refactor code, and change application behaviour. This is also a good time to take a friend (you trust) through your application, and get a second opinion.

4. Design

I find the design really important. This is where you start to get a feel for your application, particularly its personality (Something I think is very important). Work on a template design, something that you are going to apply to all your screens, then start working on a couple of screens. Try to use the correct copy instead of Lorem Ipsum. You will start to get a feel for the application. Think about the personality of the application based on who your potential customer will be. If you are targeting a youth market, then is your app look-and-feel ‘youth’ like? Does it come across as a 18-35 year old? Do you envisage the customer and the application having a relationship with each other? Work on the design until you think you have nailed this. Although with style sheets, you can always change the design, getting it as close as possible at first, means that you make lighter work later.

One thing that I will also add here that I like doing, is that I like to make sure that I leave some flexibility in my design. Things like size of titles, colours etc. The reason I do this is twofold; firstly, you just don’t need this detail, and secondly is for psychological reasons. As you go ahead to build and test your application, you are looking at your screens day in and day out. You quickly get bored of them, and start asking yourself the inevitable questions of “did I get this design right? Seems stale now, what can I do to improve it?” By adding the missing design elements, you tend to find that you keep it fresh and stop second guessing yourself. Again, just something I like doing.

5. HTML Screens

OK, once you are happy with the fundamental design, it is time to start building screens. This is where, if you didn’t cut any corners on Step 2, that you will find this to be an easier process. Mainly because you start to identify similar screens. Again, do your best to not cut corners though. Build every screen that you need, as it will make your coding experience much more pleasurable. If you can walk through your scenario using HTML screens, you are doing quite well. And you are half way there.

The interesting thing here is, how far do you take your Ajax at this point? With frameworks such as Rails and Grails, many of the Ajax functions are available out of the box, so you may not want to hand build everything in the HTML. I use grails a lot and what I like to do at times, is when I have taken my HTML screens to the point that I am writing Ajax code, I now start writing the HTML within the Grails framework, which means that I start building the actual Ajax around the framework tools, and also start putting real links without any real logic behind the scenes. This should be pretty straight forward, and again, make lighter work for you in the future.

6. Write the code

This is where you start finishing the project. Notice I say finishing, and in some ways you feel like you have just started? That is because we often get caught in the trap of writing apps from the bottom up; design the database, work out functional code and then the design. But that is wrong. DB admins aren’t the users of your application, its people that are interacting with the UI, so you should take the top down approach. And that is exactly what we did with this process.

Now that we are writing the code, we work out what the actual stories are from our scenario and start writing the code by writing the tests first etc. I am not going to go into what a purist Agile, Test Driven development tirade is, but I think most coders know what best practice is these days, and should strive to get as close as possible to that (even though it is not realistic to do so at times).

So there it is, a process that you can clearly follow. I haven’t gone through the details of how to launch in the market, but that post will come soon. There are so many ways that you could run this process, and find a more optimal way for you to work, but this is what works for me that means I can get a running product much quicker than fumbling over myself.

Recently, I have been having various conversations with people about Offshore Development Centres (ODCs). Offshoring was quite popular some years ago, and it has become a standard practice by many development shops these days to be able to leverage a (diminishing) development budget.

I have worked with various development teams, many of which have been offshored, and last year, whilst CTO of Aegeon Corp, I was responsible for moving much of the development of Aegeon’s products to an ODC. In the selection process, I screened dozens of companies and ultimately travelled to China to make a final selection.

In recent discussions with people, I realised that many people (developers and managers) are quite uninformed about the issues of outsourcing. They tend to get quite hung up on items that have become redundant, or at the very least, are issues that are quite common that many ODCs have more than adequate mitigation in place, and overlook some of the more important issues.

In this blog posting, I intend to uncover some of the myths that are being spread around when managers plan to set up an ODC.

1. You must stick with the Major Tier 1 Cities

When sourcing offshore providers, we tend to go to the major technology hubs in popular offshoring countries such as India and China. And although there is a certain advantage working with companies in these countries (since they have now reached a certain level of maturity and experience in the industry), you do not necessarily need to put your teams together in cities such as Beijing, Mumbai, Shanghai or Pune. In fact, doing so means that you are likely to be paying a premium rate for little business benefit.

When travelling to these countries, you soon realise that many of the resources that are working in the capital cities are actually sourced from many of the Tier 2 cities. Since cost of living in the tier one cities is higher, rates for resources are higher. For example, in China, you will pay 10-25% more for resources in Beijing and Shanghai, than you would for the same calibre of talent in Dalian, Chengdu or even Guangzhou.
Remember the talent pool to choose from in these countries is greater than the entire population of some countries.

2. Beware – any IP developed offshore is going to be pirated!

This is always an issue regardless if you offshore, but there is a certain amount of uncertainty knowing that it may be difficult to prosecute any pirates in foreign countries. But in reality, there is a lot going on both abroad and locally to combat this.

For example, any technology parks, and any half decent companies are very stringent and provide a high level of control an police this quite effectively. For example, when in China, I discovered that technology parks in Beijing and Dalian had their own prosecutors and courts to administer fines and even jail terms for any individuals that are accused and convicted of piracy (particularly in ODCs).

Additionally, you have to consider what the real risk is. In some instance, if you are developing an autonomous desktop application, you may want to be careful how to approach this. But if you are developing a web application, remember that the technology is only a small portion of the product. The strategy, go-to-market and marketing in general is what is going to make the product a success. Do you really think the pirates are going to have the wherewithal to successfully pirate and market such a product?
If there are certain aspects of your application that are unique that is sensitive to the success of the product if it were to be pirated (such as algorithms or particular workflows), you may want to consider ensuring the development of those aspects locally.

Finally, you have to accept your ODC partner exactly as that, a ‘partner’. So there needs to be a certain level of trust. You have to accept that ODCs are not in the business of pirating your software but developing software for clients like yourself. You will be one of many, and the best reference for this are the testimonials you will receive from their other customers.

The quality of the code is going to be poor

This is one of the most prominent myths I come across, and sure it may have been true several years ago, the reality is that most of the resources working on the projects are going to be quite senior. When you talk to the companies running the ODCs, you realise that they have extremely stringent resource acceptance criteria, such as high IQ, top percentile of university graduates and high expectations of English language.
In most cases, the quality of code I have seen is as good and sometimes better than a lot of the code developed locally.

But don’t let this myth get mixed up with the reality that sometimes, your ODC does not clearly understand your requirements. So you have your requirement, you believe that you have documented and described the requirement to the n’th degree, and then when you finally get the code, it is not what you expected. This is a communication issue (which could happen to your local team if left unsupervised as well), and does not mean that the quality is rotten.

It is not possible to run projects using Agile methodologies with an offshore team
Because of the fact that your team is remote does not mean that the team cannot be run using Agile methodologies. In fact, I believe ODCs lend themselves quite nicely to Agile development, particularly if you select an ODC that is in a relatively good timezone as you.

You can have daily stand-ups, write your requirements as stories, manage them into sprints and allow your remote team to use disciplines such as TDD and pair programming. You just must accept that the team is remote, and the biggest challenge is communication and interaction with that team, particularly when clarifying requirements. So make sure you pay close attention to the communication aspect (hence why timezone helps). But see point 7 below for more detail.

Stick to the large ODC providers

Sure there is more security and better processes with the larger ODC providers, but there are 2 downsides that you will have to take on board (in my opinion outweighing the benefits). Firstly, you are likely to pay 25-50% more for resources from larger ODCs as they have greater overheads, and secondly, if you are a start-up or smaller organisation, you are not going to get the top class developers or attention from these companies. They will be reserved for their blue chip clients. Remember, companies such as Microsoft, Cisco, SAP amongst others are outsourcing as well and pumping millions of dollars into these companies, and those customer will get the top notch service, no matter what you think.

As long as you shop wisely, and do your homework on your ODCs you will find some great smaller ODCs where you will be one of their premier clients and will receive the attention you deserve. The quality of resources are still going to be fantastic, and you will be able to screen who works on your project anyway.
I cannot recommend enough the benefits of physically visiting your team and ODC. The cost to travel there a couple of days will probably be the equivalent of a few days of development time from that team, should be budgeted in the project and is money well spent.

Language and Culture are a huge barrier

Sure, this is a barrier, but I do not think that these days it is a huge barrier. Most resources that you will be working with in your ODC (particularly the senior ones) will have exceptional English. Many ODCs encourage all their resources to speak English constantly in the workplace so they can get the practise.

This will be a diminishing issue as the project carries on, you will soon discover what the constraints and difficulties are, and how to best communicate with the team. For example, in a project I ran with one ODC, I initially conducted stand-ups over IM chat (as written English was more comfortable for the team), but after that became impractical, we moved to telephone calls with the team leader who would convey updates on behalf of his team. As the rest of the team became more confident with their English, they would start to participate and you would all soon be working as one autonomous team.

A big no-no is to alienate the team and treat them as outsiders. The sooner you accept them as part of your team, and ultimately your company, the sooner you will get better results from them. Remote teams, like local teams, will take great pride in their company, and if they feel to be part of your company, that can only benefit you

Give your ODC team instructions and let them write code

This is not as much a myth as it is an expectation that most people adopt that infuriate me when they finally admin that the ODC failed! I constantly find local teams (product managers and subject matter experts) passing on their instructions and then walk away from the development hoping to get a great result at the end. Managing the ODC team is a full time job, just as it would be managing a local team.

I have found that the best mix for a local team to manage a remote team is a product manager and one technical lead. Both these resources need to be available 100% of the time to the remote team, but as the project progresses, the demand on them will be less.

The product manager will be responsible for clarifying requirements and final user testing, whilst the technical lead will partially act like the architect and review the results of what is delivered. I believe that the cost overhead is certainly bearable considering your remote team would cost 60%-75% less than a local team.

So there you go, that is what I have discovered in the last few years working with ODCs, do you have any opinions and your own experiences? I would love to hear about them.