Sprint and Shift

When resources are scarce the smartest thing to do is to share.

For so long, startup founders have been pitching about having a team of professionals who are one hundred percent dedicated to the job. For most of these enterprises in their infancy that was true. What was also true, and much less obvious, was that these dedicated teams were not 100% occupied in their work 100% of the time.

Much like in the military, start-up life is more in the sense of  hurrying up and waiting.

So you are Lean and Agile, Your team is sprinting, they are at their best, optimized, combined effort to get the feature out on time.

But then, they wait.

They wait for the new designs to come in, wait for the other guy to deliver his bit, wait for the analytics on the latest feature. Wait.
And while the team waits, you waste.

In a way, its like having a V12 engine, running full throttle without anything connected to it. burning money with no practical production.

So how does the sharing work?

The key for time efficiency is to always have a full stack of tasks to do for the development team. So, if one project is not enough, its time to share. combining efforts with more then one startup means that the developers, as any other expensive resource in the company can be pooled. while waiting on one task, a developer can shift to another. By the method of Sprint and Shift, resources are maximized.

Oh, this sounds so wonderful, but is this as good in practice as it is in theory?

For the past year I had the privilege of working with two teams, both independent companies but inter-dependent in resources.

By choosing to do so, we have been able to enjoy the best quality of manpower, without paying for lost time between sprints. This is "Sprint and Shift" in action.

Nothing can be leaner than this.