Who’s On Phirst

All companies have different needs and reasons they pursue outsourcing. While Phurnace had success with our first outsourcing project, it was not without lessons learned. Having just kicked off our second outsourcing project, I'd like to share some of these lessons for those of you who might be considering an outsourced software development project.

Recognize the inevitable challenges
If you are going “offshore”, the language barrier is always a challenge. Even well spoken English can sometimes be hard to understand when you are accustomed to hearing the Texas drawl. The time difference is challenging primarily because it adds stress to the end of your day and in the same way your begins with stress. Finally, the lack of direct interaction is by far the biggest challenge. Nothing replaces direct communication. The recognition of these challenges is important so that you find creative ways to mitigate them.

Choose your project wisely
Selecting a project with a lot of unknowns leaves the door open for disaster. In addition, maintenance projects can be a bad idea. Maintenance is often perceived as easy which evolves to thinking that maintenance can be outsourced. While it is certainly possible, maintenance often involves very difficult problems and your most knowledgeable developers. Instead, find a project that your internal development staff could knock out of the park; but, is not the best use of their time, technically speaking.

For Phurnace, the best projects are usually those that have two qualities:

• Direct knowledge of the problem domain and scope by our development staff
• Well defined deliverables

Don’t underestimate the time required
View your outsource team as an addition to your current team. One common mistake is to fall for the sales pitch that they will manage it for you. If you just acquired an outsource team of five people, think about the impact of 2 or 3 new additions to your staff. Use that as a starting point for estimating your time required.

Daily Communication
Agile development practices encourages direct and often communication. This same approach works very well with an outsourced team. Setup daily calls to get your project going. It may require a little nudging, but be persistent. The outsource team will eventually give because they want the project to be successful, too. If you gain confidence, you can figure out what works best once you have an understanding of how your team interacts with the rest of your organization.

Do away with formal status reports
Formal status reports might as well be named TPS reports (from the movie Office Space). They are very overrated but extremely common in outsourcing processes. They usually involve a few tables with tasks and hours. This tells you nothing about the actual progress. Think about what you really want to know and tell them what you to know and when. Here are some examples: What issues are currently outstanding. What items is the outsourcing team waiting on you for. What are is the plan for next week by person. This is the information you need so problems can be resolved quickly, and you can hold each individual accountable as you would your own team.

Expect to be very technical
Know the code that they are working with, understand the technical challenges, and be capable of providing direct technical advice. Don’t delegate this on an as-needed basis. If this is not your expertise, my recommendation is to find someone who can be on this project from day 1 to provide this assistance. This is extremely important because otherwise you will never really know how well the project is going.

Don’t forget testing
Ask for tests as deliverables. More importantly, make sure these deliverables are something you can take in-house in the case you decide to no longer use the outsourcing team.

So those are a few of the lessons learned from my first time around at Phurnace. I am excited about my new team and look forward watching their project -- very closely!

In Agile Software Development
Comment (0) Read More...

Recently, I was entertained by hearing complaints from a friend regarding their Agile practice and how impractical and inefficient it seemed. This conversation led me to think about our own agile practices at Phurnace and other companies for which I’ve worked. It is my experience, since the Agile boom, companies tend to adopt a hybrid approach that is typically a collection of agile practices mashed up with traditional practices from which people feel comfortable. I reviewed some of the basic principles of Agile software development and found several common pitfalls.

Individuals and interactions over processes and tools

Agile projects are geared to expect change. Agile practices expect that management, sales, and product leadership frequently change project requirements. Recognizing this as a reality rather than denying it leads to a more honest and accurate approach for your organization. Thus, agile projects must explicitly abandon traditional planning in favor of direct interaction with individuals. With a clear focus on high value features and releasing valuable software often, a software team can adapt to frequent changes yet consistently deliver additional product "value”.

Traditional team management use tools such as Microsoft Project to breakdown work items that look into the project's future. Resources are allocated, dependencies are tracked, and tasks are mapped to individuals. This plan is traditionally managed by identifying the "critical path" for final delivery. Any change or diversion from the plan forces the plan to be re-worked. If the project has little variance, this approach is effective. However, most software projects change often resulting in making the project plan irrelevant.

One pitfall is that most hybrid approaches continue to use traditional tools to chart out a project plan which only confuses the leadership. These estimates are put into a Microsoft Project chart to determine which stories are feasible for the next iteration. This piece of planning, even on a smaller scale, is often out of touch with reality. The reason lies behind the estimates. A spreadsheet or Gant chart of numbers fails to communicate many of the inferences and risks that would otherwise be learned by direct interaction with the team members or the lead. In essence, given a 3-4 week timeframe, relying on your team's depth of knowledge and experience thru personal interaction is a better measure for the feasibility of tasks.

The second pitfall with this theorem is around processes. Adding unnecessary processes under the name of “Agile” is, in my experience, the most abused part of the practice. For instance, daily or frequent standup meetings are very effective for encouraging frequent collaboration and communication between your team members. However, if the traditional “weekly development meeting” is simply expanded to a “daily development meeting”, it only achieves 5 times more wasted time.

Working software over comprehensive documentation

The most important thing in a software organization is consistently creating software that provides value. Frequent collaboration with your collegagues often replaces the need for short-lived documentation. Rarely, does an internal design document or test plan add value to a product suite; while actual development or test execution can produce another valuable release.

The pitfall often found in a hybrid approach is not usually around typical documentation such as test plans for design documents. Instead, organizations adopt traditional practices such as weekly status reports and require so-called-Agile “daily” status reports. Daily status reports are just another form of comprehensive documentation leaving less time for working on software!

I am sure many people experience issues with Agile development while also seeing huge improvements over the traditional practices. I am very interested in hearing any feedback or opinions. In a follow-up blog, I plan to address the other two theorems:

Customer collaboration over contract negotiation
Responding to change over following the plan

In Agile Software Development
Comment (0) Read More...