Books I read in August:

Software Estimation: Demystifying the Black Art (Developer Best Practices) by Steve McConnell

The book is about software estimation as an art, not a science. It aims to help you get your estimates within a plus/minus 25% range. While 25% still sounds huge, many companies have trouble estimating more precisely than plus/minus 100%, which I can confirm from our own (painful, expensive) experience.

McConnell gives you a framework of estimation techniques that you can use, adapt and combine to improve the estimation skills of your team/organization. We have started to use some very simple techniques from the book and are already feeling much more confident in our estimations.

tl;dr Tighten the Cone of Uncertainty. Count, don’t judge. Use historical data from your own team/organization to estimate size, effort, and schedule.

Buy? Yes

How to organize offshore and nearshore collaboration: Lessons learned in offshoring and nearshoring by Hugo Messer et al.

Notes

Three ingredients for successful remote collaboration:

• process
• responsibilities
• performance (and measuring)

Ensure that the team members discuss their personal development with their manager every 3-6 months.

The product owner should be onshore, as close as possible to the customer.

The whole team is part of sprint planning (via videoconferencing).

Who is responsible for:

• Describing the functionality and user stories?
• Deciding what to build when in a sprint?
• Testing the app?
• Demoing the app?

One crucial role in offshore collaboration is a “process manager” (also called a delivery manager, quality manager or similar title). This person’s responsibility lies outside the project, and his core mission is to ensure smooth communication between the onshore and offshore teams.

To lay a solid foundation for remote collaboration, it is important to create “think time” before “doing”.

If your collaboration involves core algorithms or functionality, have good NDAs and grant access on a strict need-to-know basis.

Lack of proper planning makes it impossible to set up the right infrastructure and results in the failure of many projects. Agile development thrives in an environment which promotes collaboration and trust, and the right infrastructure is the key enabler for this.

The audio/video devices from Avaya and Polycom have given me good results in many locations.

Interactive digital whiteboards are cool.

Use a tool that’s able to record both the screen and the audio during conference calls.

CamStudio has a pretty good free screen recording software.

When team members from a different country visit, get volunteers from the onshore part of the same team to accompany them. They can act as local guides for shopping and sightseeing. I have personally experienced strong bonding after such outings.

Set up periodic communication about the project vision, overall project milestones, and key developments.

Use a gated check-in policy (all commits still have to build). Use continuous integration.

Ensure that everyone has a good and current view of the project. Use wikis, dashboards, chats, blogs, and issue tracking.

Continuous integration is a practice which enables early assembly of code units to a common shared mainline, as well as reflection on code quality, unit tests, and other kinds of measurable parameters.

Dashboards on LCD TVs in a project area are a nice way to represent the current build status and compliance reports for the agreed quality indicators.

There is no rule of thumb except that local teams should be able to work independently and that dependencies across teams should be identified and clear. This could mean that roles such as Business Analyst or Technical Architect will have to co-exist with local teams (this was for offshore teams).

We have found that our best practice in nearshoring is to work together as one team rather than subcontracting parts of the work. Modern communication devices and the availability of high bandwidth enables this. We call this an eXtended Resource Team (XRT).

XRT Principles

1. We are all equal colleagues. We treat every team member as a colleague – not as a replaceable extra resource, but as a long-term colleague.
2. We are one Team. Both teams can do all activities. In this way we steer away from work packages and are free to distribute the tasks on a day-to-day basis where the availability and capacity are independent of the location.
3. We have daily contact. Every day, the manager interacts with all the team members. Thus, we make sure that the team stays together and everyone has the same knowledge available to make the right decisions.
4. We create opportunities together. The team manager visits the nearshore part of the team at least every other month. The whole team gets together at the start of a new project and at least once a year.

tl;dr Use collaboration tools. Build a team. Someone has to be responsible.

Buy? Maybe

How To Get Prepared For Managing A Remote Team by Hugo Messer et al.

Notes

I just started taking notes on my Kindle, so I don’t have many on this book.

Offshore Process

Ambiguities in specification documents will be very expensive. Expect a lack of background understanding of the business processes (of the project or the customer) by your offshore team.

Make sure you have developed a common understanding on the expected deliverables.

Team Room

This is only for working. There should be another room for casual or non-work-related talk.

You need good headsets so you can talk collaboratively without disturbing others.

You need multiple project walls, as well as a company wall.

tl;dr Interesting read for everyone thinking about building a nearshore or offshore team.

Buy? Yes