Build on Demand with Datavail’s Sprint Team-as-a-Service

What if, instead of just repainting the Golden Gate bridge, those maintenance crews could rebuild it as they went along? The result would be a continuously improved new structure at about the same cost of maintaining the old one (not including materials, of courses). That’s the premise behind Datavail’s new “Sprint Team-as-a-Service” concept: “don’t just maintain your digital systems over time; we will help you rebuild them gradually as you build your business.”

Sprint- vs. Project-Based Development Services

Datavail came up with the concept while working with a new client whose service connected study-abroad opportunities to interested students. However, the provider’s technology wasn’t able to adapt to the continually evolving demand created by the constant addition of new schools and scholars. Further, the client did not have the skill set needed to recreate the system as a whole.

How it Works

In response, Datavail invented a ‘sprint team’ resource that dramatically changed both how they offered their services, and how their client managed his business:

• Datavail provided its software development services in two-week intervals (sprints) instead of on a whole-project basis.
• The sprint-team consisted of those technicians specifically called for by the sprint at hand – architect, developer, tester, etc.
• The team began by addressing the client’s backlogged issues but were equally prepared to develop new programming when needed.
• Because the client wasn’t 100% certain of how he initially wanted to move forward, he relied on information presented by the sprint team to help him make those decisions incrementally.
• The team’s flexibility allowed them to fluidly redirect their effort based on both what they discovered in their work and on what their customer wanted them to do. If necessary, they could refocus on more urgent concerns as they became evident or at their client’s request.
• When needed, Datavail added additional teams also on a sprint basis to resolve specific problems while the primary team continued its focus on the client’s to-do list.
• Team members swapped out as the needs of each sprint evolved.
• The client budgeted the process as an operational expense and added new sprints as budget and needs demanded.

The Customer Response

In the end, the customer’s business was able to manage all the changes requested by its global client base, and he was confident that he could afford to maintain that evolving capacity as his business grew.

When asked, he clarified what it was about the Datavail Sprint Team-as-a-Service that best suited his situation:

• Having a fully populated team gave him (and them) both a 30,000-foot and granular view of the work to be done and the result to expect.
• Having all their eyes on his short-, mid-, and long-term goals helped him to clarify (and budget for) his priorities.
• Datavail’s “Sprint Team 0” – the planning sprint – helped to identify and prioritize backlogged issues; suggest processes that could achieve early-, mid-, and ultimate goals, and create a preliminary design that got the effort started.

The Company’s Success

From the Datavail perspective, launching the Sprint Team also suggested ways that they could tweak their service practices:

• Putting control in the customer’s hands didn’t erode the quality of their service but instead enhanced it more toward what the customer was actually visualizing.
• The sprint concept significantly improved the customer relationship by making it an ongoing partnership instead of a one-time project event.
• The sprint concept also suggested a restructuring of their pricing strategy. Team members who were familiar with the customer could address and resolve issues more quickly, which often got the work done at a lower cost for the client.

Unfortunately, it’s not possible to rebuild the Golden Gate Bridge as an ongoing building project. With Datavail’s Sprint Team-as-a-Service, however, you can build and rebuild your business even as it grows and evolves.

http://goldengatebridge.org/research/facts.php#PaintHowOften