Outsourcing mobile app development and the agile software methodology don’t naturally fit together – in the below post I’ll outline how to make it work to reduce risk on both sides and give the project the best chance of success.
Key Challenges when Outsourcing Mobile App Development
The core disconnect between agile and outsourcing is the relationship between the cost and scope of deliverables. When outsourcing a project, you want to know upfront how much it’s going to cost and exactly what you’ll receive; however, in order to reach that decision the outsourcing partner needs to go very deep into requirements.
A typical waterfall based team would analyze all of the requirements upfront, do the development, then testing, then deployment. A typical agile team is conducting requirements gathering, development, and testing concurrently throughout the project.
In an agile project, scope is very dynamic and priorities can change frequently. Agile is by definition flexible and quick to adapt. Project scope and timelines are determined more by the available resources and their ability to deliver value. The requirements are very loosely gathered in the beginning and clarified as the item is moved from the product backlog into a sprint. The challenge with this approach is that the size of the item may move from a Small=>Medium=>Large depending on how complex the requirements become during clarification. If the arrangement between you and the outsourced team is too rigid, these changes will result in change requests that will require estimation, review, and approval.
How to Work in an Agile Way with an Outsourced Team
Fundamentally there are two ways to outsource a project. Both ways work with agile teams, but a fixed price project will require more upfront analysis and more accurate project sizing.
1: Fixed Price
In a fixed price project the scope is defined upfront along with timelines and estimated hours. In this model the scope needs to be crystal clear and even then there are risks on both sides that either the scope wasn’t properly defined or the effort not adequately sized.
With a fixed price project, you should expect a Discovery Phase in which requirements are gathered and the scope clarified. This phase would typically result in complete User Stories, Wireframes, Technical Design, Project Plan, and often a proof-of-concept to mitigate any perceived risks.
Once the estimation and project plan is complete, then the methodology can switch to more of an agile delivery model where items are broken into sprint-wise plans with regular delivery review, and sign-off. This approach will increase the visibility into the project and reduce the number of surprises at the end.
2: Time & Materials (T&M)
In a time & materials project the scope can be changed on the fly. This model enables maximum flexibility as the outsourced vendor is simply billing for time. The onus is on you to ensure that scope and goals are efficiently planned. In this model no Discovery Phase is needed and you can dive right into the project.
A typical approach to setting up a T&M project is to assign an upper cap of monthly hours and build a resource pool to fill those needs. A team may consist of business analysts, designers, developers, architects, and a project manager and/or product owner. Some vendors will bill each of these resources separately or bundle them into a single hourly rate.
An important metric in a T&M project is how much value is being delivered per hour. This is important to measure so that key stakeholders/decision makers can see that the delivery team (from business analysts to developers to testers) are working efficiently and consistently delivering quality results.
Managing the Product Backlog
When working with an agile team, it’s all about the product backlog. The backlog is a list of items, ideas, features, and defects that have been captured at some point along the way. Any ideas that come up at any stage, should be captured in the backlog. Whether it’s a good idea in the long-term or immediate term, it should get captured in the backlog so it can be prioritized accordingly. Some backlog items will be very high-level and potentially very large; however, other items will be very small.
When sizing an idea in the backlog, it should be a very very high-level estimate (t-shirt sizes work well – XS, S, M, L, XL, XXL). These estimates will be reviewed during sprint planning.
When working in an agile methodology, you should break the project into 1-4 week sprints. In our experience, 2 week sprints are typically most suitable for mobile projects. Grouping tasks into two week sprints gives enough time to put dedicated efforts into planning, development, and review. A shorter sprint than this can cause a lot of overhead compared to the amount of development work that gets completed.
Sprint planning consists of the following activities:
- Prioritizing items in the backlog: look at the list of items and decide which ones should be considered for development in the next few sprints. This will be based upon the high-level estimate and the value the item brings to the product.
- Sizing items: once the items are moved from the long-term backlog into a list of items that should be considered in the short-medium term, the items need to be sized more accurately. This is where t-shirt sizes get moved into the team’s standard units.
- Creating the sprint plan: now that the items have been sized more granularly, the product owner along with the development team decide what items get moved into the upcoming sprint. This is determined by value per unit of effort.
At the end of a sprint it is critical that the product owner and team review the deliverables from the sprint promptly. This is one of the pain areas when outsourcing because often it becomes an out-of-sight, out-of-mind sort of situation. If it is not clearly agreed upon that sprint reviews will happen immediately after a sprint and items are either signed-off or rejected, you’ll end up with a very large amount of items that get carried from sprint to sprint because they are never being adequately reviewed, revised, and closed. If you fall into this trap, you’ll end up with a large end-to-end testing sprint at the end of the phase.
The lesson here is that whether you are in-sourcing or outsourcing, the teams have to be cohesive and have a good rhythm to their workflow. If you’re aiming for a rapid release cycle, an agile methodology is an excellent approach. The efficiency will be determined by the team and their ability to work together as a seamless unit.