Agile Outsourcing - 12 Principles To Guarantee Project Success

13 min read
Agile Outsourcing - 12 Principles To Guarantee Project Success

The value of the agile development model comes directly from the deep collaboration. However, when software vendors are added to the mix, companies often opt to use agile development internally, but leave the outsourcing provider to deliver independently, completely outside of the agile work streams.

The problem? They’re leaving value on the table.

A software partner that will work with your agile processes (and not outside of them) can bring tremendous value for business. This model of agile outsourcing can be hard to embrace. It may even seem in conflict with traditional outsourcing ideas.

In this article we’ll help you handle the dynamics of agile software development outsourcing and maximize the value of an external software partner.

Embrace validated learning

Central to agile software development is validated learning. As you learn more about your end product, your users, or your workflow, you adjust. Embracing this continuous learning across the team is key.

One way to understand this is to think about your project in terms of hypothesis-driven experimentation. At the beginning of the project, you have a hypothesis of what the product should look like. Through iterative product releases, you validate and adjust your hypothesis. Each step is an experiment.

If you aim to improve your software development process, you need to take into account learning, especially when you bring the lean ideas into it. Build vision pivots. While software developers are not a fan of them, they’re critical if you want a successful project.

Adjust your product vision as you learn

The first phase of any project should be clarifying your product vision. Your product vision should include:

  • Specific project goals
  • Documented business value
  • Success criteria

The more specific you can be, the better. As you clarify your product vision, the end product will more clearly come into focus. You can use this work to guide the project to completion and ensure project success.

Not sure how to put together a project plan? Consider focusing on the bigger picture with these questions:

  • Are you addressing a specific problem? Can you define the problem?
  • What is the end goal?
  • How will the user use the end product?
  • What are the key features? Are there “must have” and “nice to have” features?

After you define your goals, consider the project delivery:

  • Which team members will be essential for this project?
  • How much work is required with each sprint?
  • Have you gotten feedback on your plan from technical and non-technical team members?

Taking the time to crystalize your product vision will help ensure a successful end product.

​​Focus on value for stakeholders

Every agile software project has stakeholders. Each stakeholder has a unique role in the project. Stakeholders may include:

  • Company leadership
  • Project sponsors
  • Project managers
  • Product owners
  • Developers
  • End users
  • Customers

When you involve an outsourcing vendor, you will have different stakeholders. In this case, you should consider stakeholders outside of your organization such as outsourced project managers, developers, and testers.

It’s important to involve all relevant stakeholders in your project because:

  • Stakeholders can provide valuable expertise. This could include historical, product and/or industry information.
  • Engaging with a variety of stakeholders will help to reduce risk and uncover potential issues faster.
  • Early users can help the team to evaluate the project outcomes early.
  • Involving stakeholders in the project definition phase will lead to an overall higher project success rate.

Establish a product discovery team

Proper, ongoing requirements analysis and planning are critical to any software development project. And agile software development, specifically, must leave room for making changes quickly. At any point during the development process, changes can be made.

If there is a new deliverable, requirements should be updated, and the development team must quickly act on the changes.

It’s also important for the design team to be continuously validating project deliverables. If anything goes wrong, it should be quickly identified and resolved.

All stakeholders should plan for change throughout the project. There should be a plan to process and manage scope change.

Find an experienced engineering leader

One of the most critical members of any development team is an experienced engineering leader. This high-performing leader should bring technical capabilities as well as soft skills to help manage relationships across the team.

This role can be a real challenge to staff. When utilizing agile outsourcing, you should look for a team that has an engineering leader built-in. This will spare you from the effort of searching, interviewing and hiring for this role.

The right engineering leader should:

  • Have strong technical skills.
  • Possess strong communication skills.
  • Have experience in your domain, with many projects under his or her belt.
  • Be able to guide agile processes.
  • Protect the team from coordination and quality assurance issues.

At SoftKraft we are a true software partner. We have dedicated development tracks to ensure an engineering leader can be staffed. Our engineering leaders not only handle the technology and team, but they also work towards clients’ long term success. For example, they are capable of joining your design team and contributing to the product development process.

Build a high-performing agile outsourcing team

We believe that dedication is contagious. If team members are dedicated and the manager serves as a role model, other team members are more inclined to behave similarly. The best way to build dedication is to equip the team and allow the team to make decisions themselves.

Allowing the team to set timelines and conduct team rituals gives the team ownership over the project. The Engineering Leader should drive performance on the team by guiding the overall product vision.

Many attempts have been made over the years to measure the performance of software teams. The issue is that most models have a major flaw: they focus on outputs rather than outcomes. They are more concerned with individual performance than with team or company performance.

Change fail percentage _is a high-performing engineering team’s ultimate metric. _This is calculated as the proportion of changes to production that result in a hotfix, rollback, or period of degraded performance. This includes, of course, software releases and configuration changes, as both are common causes of software failure.

This metric is the Lean equivalent of percent complete and accurate, commonly used in a generic product delivery process. This is common sense, and it is consistent with our understanding of manufacturing companies: you don’t want to increase factory production throughput at the expense of quality control.

With high pressure on teams to perform, the failure percentage is another vital software engineering KPI. The ratio of defects presented in pre-production testing to those making it to production is your defect escape rate. This enables you to assess your team’s software releases’ overall quality regularly.

Read more Software Development KPIs — Practical Metrics for Teams.

Commit to accurate planning

Start by listing out all project requirements. This is a good time to get feedback from internal stakeholders. Include both “must-have” and “nice-to-have” requirements. Take the time to ensure _all _requirements are included.

Scrum and agile methodologies call this list of requirements a Product Backlog. Once you have this backlog prepared, you’ll provide it to the development team who will be doing the work. The development team will estimate the work for each requirement.

Note: In order for the estimate to be valid according to agile methodologies, the team doing the work _must _do the estimate.

One way to estimate the project workload is by using Planning Poker. With this method, the development team assigns a score to each requirement on the list. The higher the score, the more effort the item will require. At this stage, a timeline hasn’t been attached to anything. This stage is simply to estimate workload.

Using an estimation method such as Planning Poker:

  • Encourages team collaboration and team building.
  • Provokes valuable insights from the software development team who might not have a platform to discuss their opinions and experiences otherwise.
  • Requires individuals to defend their predictions.
  • Improves estimate accuracy.

Hold kickoff to establish candid communication

The kickoff meeting is likely the first meeting between members of the project team and the client or sponsor. It’s an excellent opportunity to establish expectations and create strong team morale early.

Your kickoff is a time to introduce the team to the project, decide on teamwork strategies, and set project goals and check-ins. You might want to outline how you'll communicate, meet, and what could slow down the process (and how to avoid that).

SoftKraft’s typical project kick-off meeting agenda:

  • Team roles- Introduce the team and what they will be responsible for.
  • Vision statement - Provide the project’s vision statement. For example: "For <customer>, the <project name> does / provides / solves <problem / solution statement>. Unlike <competitor / comparison point>, it will <differentiator>."
  • Project scope - The client presents the MVP features that need to be delivered. The client can also cover a high-level epic journey: What user personas are involved? Where does it fit in the overall user experience?
  • Timeline and metrics - The client presents his or her point of view on trade-offs, so Softkraft can make smaller decisions quickly and autonomously.
  • Success factors (group session) - Ask everyone to write down what they think will make the project successful. Have the team share their ideas and discuss how each one could be measured.This is a great way to get group engagement!
  • RAID (group session) - This is similar to the previous session, but it is focused on risks.
    • Risks- things that could happen, and would affect the quality, timing or cost of the project (or a combination).
    • Assumptions - things that are currently true and form the basis for a plan, but any change in them would create risk or issue.
    • Issues- things that have already happened that adversely affect the project.
    • Dependencies- things that need to be done or provided, either once or regularly, to make the project a success.
  • Team communication plan- Softkraft discusses how communication will be handled with the client - how often, in what form, etc.

Communicate, communicate, communicate

The agile methodology encourages developers to communicate through team collaboration. When using the agile model, the team members work closely with the stakeholders. This should result in improved decision making and customer satisfaction.

Keep in mind that agile software development requires strong communication between the client and the offshore development team to achieve project goals and ensure proper software delivery.

Honesty is important in this relationship. Because of cultural differences, it’s common for software developers to avoid speaking their minds for fear of upsetting the client. Sometimes misunderstandings can happen, but the more transparent everyone can be, the better.

Tips for strong communication:

  • Set up face-to-face visits.
  • Set up virtual or face-to-face team building activities.
  • Ensure a culture of honesty is established on both sides.
  • Ensure appropriate business processes are established on both sides.
  • Utilize a robust set of communication tools.

The point is that there’s nothing such as over-communication in agile software development. To set the project up for success, we recommend setting up as many communication channels as you can.

The outsourcing vendor should appoint at least one member in their team who speaks fluently in the client’s native language to represent the client accurately. This role usually falls to the engineering lead or a certified Scrum professional.

Clients should also name a dedicated representative that is very familiar with the project and can communicate efficiently with the offshore development team. The client’s representative is usually authorized to accept changes or approve work.

Understand your team’s limits

While Agile software development teams are defined as cross-functional, they come with some limits. For example, not every software development project will include a lawyer in their team.

It’s important to understand the specific limits of the agile team you are working with. To obtain a better understanding of this, you can create an organization-wide value stream map for project delivery. Evaluate the work that has to be done by the agile team. Then, you’ll have a clear idea of the work that needs to be done outside of the team.

This work can be done as pre-work before development begins, at the end of the cycle, or concurrently with the development team.

Note: The amount of work found in the value stream map is also a good start for setting up the budget based on the project’s labor costs.

Do risk assessments regularly

Every project comes with risks. Risks are problems that may arise over the course of project development. Project management has the task of identifying and reducing risk beginning at the project planning phase. We recommend you plan a meeting to discuss this or simply ask all the team members about what risks may arise.

When considering risks, you should look into these areas:

  • Project scope
  • Resources (staff, financial, and physical)
  • Project delays
  • Failures of technology
  • Failures of communication

Complete control over all potential risks is impossible, so you should focus on considering them early on to avoid project failure.

Continually manage project scope

In agile development, you must manage the project scope throughout the project. It’s not a one-time thing. New discoveries from the users, product owners, and others may bring in new requirements. Additionally, feedback from stakeholders may require the project scope to change.

It’s important to have a clear scope defined up front, but you should be willing and able to adjust to changing scope as the project develops. Ensure you have a clear project owner who will adjust as needed when new information arises.

As the scope changes, so will your budget and timeline. The agile approach makes budget management a shared responsibility between the client and outsourced team. The product owner manages the backlog, the sponsor agrees on the budget, and the team delivers the backlog and spends or manages the sprint budget within agreed constraints.

Similarly, the project’s timeline will be estimated up front but will change as the scope of the project changes. To account for some amount of change, we advise you to allocate extra time to complete the tasks. It can also be helpful to bring in a project manager to guarantee that the project progresses fast enough to meet deadlines.

Conclusion

Many organizations apply agile methodology in outsourcing. If you have the right outsourcing partner, you’ll find significant business value in embracing agile outsourcing. A few key takeaways for your next agile-outsourced project:

  • Take the time to select the _right _agile partner for your project - this is critical!
  • Clearly define project success standards up front. Ensure everyone is clear on what success looks like.
  • Remain flexible throughout the project. Change is inevitable!
  • Don’t be afraid to speak up and share feedback early. The more transparent everyone can be, the better.

Finally, consider giving agile outsourcing a try. You can start with a small project, evaluate a vendor’s work, and decide if software outsourcing helps achieve your business goals.