eBook2 edited - final - VenturePact · 2018. 12. 31. ·...

[Type text] [Type text]

Outsourcing 102

Manage, Communicate and Release, Effectively!

2

CONTENTS

GETTING STARTED WITH DEVELOPMENT 4

ü PREPARING A PLAN 4

ü MANAGING THE TEAM 8

o USING TASK MANAGEMENT AND TRACKING TOOLS 9

o SETTING A CLEAR COMMUNICATION SYSTEM 13

o BUILDING A STRONG CULTURE 22

Software Development for Entrepreneurs 25

3

our last eBook, we analyzed the best practices to set up a

successful outsourcing engagement. We discussed how to:

• Decide whether outsourcing is right for you

• Select and compare developers

• Set up contracts with developers

• Avoid common outsourcing pitfalls

In this second eBook of our Outsourcing 10X series, we will discuss how

to conduct a successful outsourcing engagement. We will assess how

to:

• Plan a software development project

• Communicate with remote teams across time zones

• Manage accountability and ensure deadlines

• Assess quality of code and standards

• Manage contingencies and understand rookie mistakes

• Understand some common outsourcing myths

Have questions about developing your next big idea? We're happy to

help. Send us an email at [email protected]

In

4

GETTING STARTED WITH DEVELOPMENT

You have finalized your requirements, selected a developer and now, it’s

time to write code. Right?

Well, not so fast!

When a project is launched, we often observe that both developers and

clients are eager to start coding right from day one. The client wants to

see “real” results while the developer wants to meet their deadlines.

Often, both parties don’t find it worthwhile to spend time actually

planning. Without planning a release schedule with deadlines and

assignments, there is no accountability, which usually leads to extensive

delays.

Imagine you’re building a house. Now, you can’t just call the builder on

day 1 and ask her to start laying down the foundation. You may have an

end result in mind, but that isn’t enough. You need a well-‐thought out

plan that is properly executed to get you there. The same goes for

software development.

That said, planning is difficult!

5

As you develop your app, you will get new ideas and your customers

will provide feedback, leading to changes in the initial scope and the

initial plan. So how do you plan knowing that you will be changing the

scope along the way?

EVER HEARD OF AGILE SOFTWARE DEVELOPMENT?

Agile is an iterative and incremental development methodology that

allows teams to incorporate user feedback and changes while the

development is underway.

With agile, a project is divided into small increments. Each increment is

designed, developed, tested and deployed before the next increment is

started. As you ship small increments, you get user feedback constantly,

which can be incorporated along the way.

You start with the increments you are most certain of (like login and

signup functionalities that are necessary), leaving the more uncertain

functionalities for later. This gives you the time you need to incorporate

any user feedback.

Although every company claims to be agile, most of them tend to have

their own version of it. While the "philosophy" remains the same, the

practices are adapted to suit a team’s preferences.

6

Here is an example of an agile development setup, where the project is

divided into the following increments:

➔ Releases or Iterations: A release is the "demo-‐able" state of the

product. Releases are planned in a way that after each release, you

can organize a product demo for customers and get feedback. A

release would contain multiple modules.

➔ Modules: Modules can be described as functionalities, like

registration flow, chat, picture sharing etc. A module may be

defined through a collection of user stories.

➔ Stories: User stories are the smallest unit of

development. For instance, “Reset Password" is a

user story, which is part of the "Login" module.

In the planning stage, your focus should be to break down the project

into such sections and work with the developers to come up with a

timeline. Every story and module, at least in the first iteration, should

have an estimated deadline in place. Subsequent iterations can be

planned as and when they are completed.

7

þ Checklist: Here’s what you need to get started with development:

ü Have the initial scope clearly laid out in the form of mockups or wireframes. ü Have agreed to a pricing structure. ü Have the project divided into iterations, starting with the one’s you’re most

certain about. ü Have user stories & modules written down with deadlines and assignments.

Agile Jargon: Agile teams often use the following words:

ü Requirements Churn -‐ A change in scope or features that is introduced while the development is underway.

ü Sprint -‐ A pre-‐defined time period in which specific tasks or work is completed and made ready for review.

ü Product backlog -‐ A list of all the features and functionalities (along with short descriptions) that are desirable in a product, but are not being built in the current iteration or version.

ü Refactoring -‐ The process of revising and simplifying the design of existing code without affecting its behavior.

ü Technical debt -‐ A metaphor to describe the extra development work you have to do when you use easy-‐to-‐implement code to get by in the short run instead of building the best solution.

8

MANAGING THE TEAM

So you have made your project plan, and now it’s finally time to start

the development phase.

When working with a development firm, you will most likely have a

Project Manager on the team to manage day-‐to-‐day requirements.

However, it helps to know the best practices so you can monitor the

team and keep them accountable. If you’re working with freelancers,

you will be doing a lot of the management on your own.

Let’s discuss the following management techniques that we have found

to be effective:

ü Using Task Management and Tracking Tools

ü Setting a Clear Communication Structure

ü Building a Strong Culture

9

USING TASK MANAGEMENT AND TRACKING TOOLS

In an office, it’s possible to get by without a process. When a new idea

comes to your mind, you can talk about it in a meeting, during lunch or

over drinks. If you find a bug, you can put it up on the whiteboard for

the team to see.

When working remotely, however, not having a system in place is

inviting disaster. Imagine trying to get people from three different time

zones together for a hangout! Now, imagine trying to organize this over

email.

www.socialsignal.com

10

Coordinating the entire project over email can become frustrating. It’s

difficult to track, and doesn’t keep people accountable.

This is why it’s much more efficient to use a project management tool.

A task management tool allows you to assign and define tasks, put in

deadlines, track progress, share files, and have discussions -‐ all on one

platform. Some popular tools you can choose from are:

1. Asana: Easy to learn and extremely versatile. Good for simple

software projects with a small team of 3-‐8 people.

2. Jira: Built for more complicated software projects. Easy to use if

you’re a developer.

3. Basecamp: It’s very popular within the industry. Extremely easy to

learn and use.

4. Slack: This new tool in the market is built around work streams

and chat rooms.

The utility of a tool really depends on how well we use it. Here are

some best practices to keep in mind while using these tools:

ü Delegation: The tasks should be assigned to a single

developer/team member, not the entire team. This keeps the

individual accountable.

11

ü Deadlines: It’s imperative to have deadlines in place for all tasks

and to keep the team accountable to those deadlines. Thus,

involving the developers while setting deadlines is necessary.

While assigning deadlines, make sure you’ve accounted for:

• Changes to scope

• Errors in prediction

• Time spent planning, designing and testing

• Local holidays

We recommend budgeting extra time before setting a launch date

and asking to translate the 60 days of development work to an

estimated date of completion that includes holidays and

weekends etc.

Source: www.savagechickens.com/2008/09/deadline.html

12

ü Maintain Lists: You should have a centralized place where you

maintain a list of bugs and a list of ideas for the next version.

Over time, it will be difficult to track everything. Often, they will

exist on your Evernote, on your iPhone notes and as scribbles on

paper but try to keep them consolidated.

ü Keep it clean: With time, the tool can become extremely messy

with Dropbox links, red marks due to missed deadlines,

comments, unattended tasks etc. For the sake of the team’s

sanity, it’s extremely important that the tool is kept clean and

updated regularly.

ü Setup guidelines: If you understand the tool, do not take it for

granted that each team member understands how to use it.

Sometimes team members will forget to update their statuses or

log the bugs in the right list or they may not have notes about the

scrum meetings etc. Thus, it becomes imperative to maintain

clear guidelines and hold the team accountable to them.

13

SETTING A CLEAR COMMUNICATION SYSTEM

Shockingly, a majority of failed projects can be attributed to

communication gaps (rather than technology failures). This is especially

true in a remote environment where you are required to “over

communicate” to compensate for the lost face time.

Most communication corresponds to the agile development schedule.

This ensures that continuous feedback is given to the team after every

story/module/iteration, so that everyone is on the same page.

Here are a few ways in which you can establish a robust communication

channel between the various teams.

i. Daily Standup: A daily standup meeting is a 10-‐20 min short

call that brings everyone on the same page. But, it cannot be

used as a substitute for task management done via a tracking

platform. In fact, both can work together. Daily standups can

force the team to sit together and align their goals. It can be

conducted at the start of a working day or just before it ends.

The call is generally supposed to focus on answering three

questions.

14

✓ What was done today?

✓ What were the challenges faced and the solutions

used to overcome them?

✓ What will be done tomorrow?

ii. Chatting: Besides the daily standup, it helps to have some

time-‐overlap so that questions that come up during the

development phase can be answered. This way the whole day

is not wasted. An overlap of 2-‐3 hours is generally helpful. Here

are three sample schedules. For the sake of the example, we’ve

assumed here that you’re on the east coast (EST) and the team

is in India (IST).

15

iii. Weekly Iteration Demo: You may schedule a longer weekly call

to actually go through the latest iteration and give feedback.

It’s important to maintain a written log of the minutes of the

meeting, so that feedback given is not lost.

16

iv. Monthly (or Bi-‐Weekly) all hands in: This is a broader meeting

where strategy and other non-‐technical issues may be

discussed. This gives the team a sense of inclusion and provides

them with a better understanding of the overall goals.

17

Here is an example of a communication schedule for the month.

18

Effective communication is more art than science. Here are some tips

to remember about communication:

Ø Over communication: People make assumptions about

expectations. “Hmm...It’s not clear what the CEO wants. Perhaps

he wants this.” Two days later -‐ “Wait, you actually wanted that?

Who would have guessed?” This is bound to happen.

Source:http://www.smashingmagazine.com/2011/05/20/why-‐can-‐t-‐we-‐bbies-‐be-‐friends/

So always over-‐communicate. When providing details, make sure

all assignments are clear. At the end of the call or chat, ask your

remote teammates to repeat everything to you. Instead of simply

asking, ‘’Is everything clear’’, ask them to explain back to you the

concept or idea you just described to them. You will get a much

19

better sense of whether or not they fully understand what needs

to be done.

Make sure everything is clear -‐ expectations, deadlines, and

evaluations. The remote employees need to understand what

matters to you and why it matters. They have to understand your

ideal outcome and goals, so that they can better determine their

objectives. You will never want a smart developer wasting their

time working on the wrong feature. This will leave both sides

frustrated and cause delays.

Ø Discipline: In an office environment, one is generally on time for

meetings because everyone is sitting together. While being

punctual for meetings and calls is equally important for remote

teams, it is easy to lose track of time and forget, especially when

you are sitting in a different time zone. In this case, plan the calls

in advance, so that people can arrange their schedule for the day

accordingly. Send a meeting invite and account for the time zone

difference to remind all parties involved of the meeting.

Ø Responsiveness: Using Asana or chatting only helps if people are

responsive. This is probably the most important thing and, if not

20

done well, can become the root cause of all frustration. The rules

are actually pretty simple.

ü Always be online and available on Hangouts/chat during

work hours (on the computer as well as cellphone).

ü Always have status updates to let people know what you are

up to: ‘I am busy’, ‘Out for the day’, ‘Lunchtime’, ‘Getting

married’ ‘Away on honeymoon’ and ‘Available for chatting’

are all short messages that let the rest of the team know

whether they can reach out to you.

Ø Empathy: Empathetic communication between team members is

important since misunderstandings often occur with online

discussions, especially if you are on a cross-‐cultural team. If there

seems to be a misunderstanding over chat, then make sure to

conduct a video call to clear up any confusion.

It is important to be empathetic towards cultural differences. For

example, let’s say while working with Indian developers, you ask

them “Can you please get this done by tonight?” Their response

might be a seemingly indifferent “Okay, please wait”.

21

Source:blog.readytomanage.com/diversity-‐cartoon/

Now, for some people in the West, this could come across as

rude, and you might feel angry or insulted. However, for the

Indian developer, she might have intended to say “Sure, you’ll

have it by tonight”. It’s important to be mindful of these cultural

differences, if you hope to establish a healthy working

relationship with the team. Give the other party the benefit of the

doubt before jumping to quick conclusions.

Ø Choosing the appropriate channel: Similar to how you don’t

break up with someone through a text message, there is certain

22

etiquette in remote communication as well. Here are some rules

of thumb:

o Email for specific one-‐time non-‐emotional messages

o Task Manager for assigning tasks, asking for updates

o IM/Chat for discussions that require quick back and forth

o Video Chat for more involved or emotional topics (feedback,

onboarding)

BUILING STRONG CULTURE

If you’re working with an outsourced software partner, chances are you

will be working with them for a while if you found a great firm. So, it

helps to have a strong relationship that’s built on trust.

Ø Build one team, not 2: In most contractual relationships, tension

will arise between the two parties. Unless the relationship is built

properly and disagreements handled tactfully, a client may come

to believe that the developer is there to cheat her and bill more

money while the contractor may become skeptical of the client’s

intention to make payments.

23

The best approach is to treat and make developers feel like

they’re a part of the company. Motivate them & spend time

onboarding them. If there is a missed deadline, refrain from

saying “Your team” missed the deadline. Rather say, we missed

this deadline and let’s try to get back on schedule. Think

productively, instead of entering into long arguments about the

past, try to learn from your mistakes and spend time thinking

about the best path forward.

Ø Not just Code Monkeys: It is important to involve the software

developers in the decision-‐making around the product and make

them feel included in the larger strategy as well. If they are

reduced to mere “code monkeys” where they are just churning

out code based on your specifications, they may complete the job,

but they will less motivated to do a good job. Try the following:

Case Study

Jason Friedman at Fab worked with a development consultancy in Pune India. He had a great rapport with the team and they worked so well together, he ended up acquiring the company.

READ MORE HERE

blog.venturepact.com/blog/why-doesnt-fab-com-use-us-based-engineers

24

o Setup Yammer for the Company: This is a Facebook like

private group for the company where you can post

interesting updates about the business, share relevant

articles, run polls etc.

o Do personal check ins: Usually all conversations are about

work. Try to mix it up. Talk to the developer about her life,

interests and hobbies. Engage with them on a more personal

level. We usually recommend a personal check in once a

week.

Tool Tip

o Meet in person: If possible, meet them in person and grab

dinner. This helps build more trust in a relationship.

Sqwiggle is an awesome tool that creates a perpetual video chat room between your

remote teams.

25

SOFTWARE DEVELOPMENT FOR ENTREPRENEURS

ARE YOU ON THE RIGHT TRACK?

You do not have to be a software developer to get software built.

However, it helps to know some concepts; best practices and jargon

that will help you ensure that your team is on track.

Here is a handy checklist of a few things you should do to stay on top of

your project and keep a close eye on progress:

1. Version control: Version control allows developers to maintain

repositories of code. Say they build a V1.1 and successfully release it.

Then they build V1.2, but as soon as they release it, they realize it has

some bugs, so they need to go back to the previous version -‐ V1.1. A

version control system lets the developers maintain these versions.

Version control also allows multiple developers to collaborate on the

same file. Version control is a standard practice so your developers

should be using GitHub or Bit

26

Bucket etc. If they are not using version control, it is generally a red

flag.

2. Commenting: Ideally, you should be able to understand how the

code flows from the comments. See the code repositories and check if

they are commenting regularly, and if those comments are descriptive.

This is important because as the team grows other developers will

review and build on that code. Clear and descriptive comments will

help the rest of the team understand the developer’s thought process.

3. Bugs, Testing & Automated testing: The developer, at the minimum,

should be maintaining a list of bugs. It is always good to check on these

bugs to see how well the developer is doing. While the number of bugs

is generally not a great indicator of quality (you always have bugs while

developing), it is important to see if those bugs are being rectified

consistently. A good developer will probably be using some automated

testing framework like selenium or cucumber, which are tools that

automate functional tests.

27

4. CI/CD: It is good practice to have Continuous Integration and

Deployment frameworks in place. CI is a process whereby the

developer can integrate new code with the old code on a regular

(usually daily) basis. A good developer will have something like Jenkins

setup whereby, when she pushes the code, the code automatically gets

tested for the use cases and only if it passes does it get integrated with

the main code branch. If it fails, it raises a ticket.

5. Code Quality: It’s very difficult for nontechnical people to judge the

quality of the code. Even if you do have a developer on your internal

team, you should remember that not every developer thinks the same

way. What makes sense to one may not make much sense to the other

and both may have different opinions of the same code. Hence, it is

important to not make snap judgments about the code quality without

understanding the other developer’s perspective. The right thing to do

is to have code reviews from day 1 so there are no surprises during the

development process.

28

6. Timelines: While it is important to enforce deadlines, there are times

when the development is hit by an unforeseen roadblock. A single bug,

at times, can take hours to resolve or a seemingly small change can

fundamentally alter the flow. An analogy given by Michael Wolfe is that

of walking on a beach from LA to San Francisco. While google maps

would suggest its 400 miles and that it should take 10 days to complete

the journey (4 miles per hour and 10 hours every day), you cannot

possibly account for bad weather, sharp turns, small hills, high tide or

angry sea lions.

29

VenturePact is a managed marketplace where businesses can find trusted and

prescreened software development firms. You get free quotes, verified

portfolios, references as well as VenturePact’s support throughout the product

development process.

www.VenturePact.com

www.venturepact.com

eBook2 edited - final - VenturePact · 2018. 12. 31. ·...

Documents

Transcript of eBook2 edited - final - VenturePact · 2018. 12. 31. ·...