Are you agile while your company uses a waterfall mode? Think Growth Sprint.

You know the scenario: your software development team works in agile while everyone else is using the same old waterfall methods.

And what happens?

The graphic design team works on assets that will later get discarded. The marketing folks would love to get some features into the product to help them with their job, but they come in too late. And the whole process ends up wasting a lot of time and resources.

At Pentalog, we believe the solution is to move everything to agile within a Growth Sprint mode.

What is “growth sprint”? How can it help? To find out, I interviewed Jeff Mignon, Chief Growth Officer at Pentalog.

Q. What is a growth sprint?

J.M. There is two types of growth sprints. The first one is similar to a design sprint. It’s a two-to-four-day workshop to get a project unstuck.

The other type is an ongoing process. That’s the one I’m going to be discussing today.

A growth sprint is a unique backlog for a project that brings together software development, user stories, UX, UI, marketing, finance, customer support, PR and even HR.

It’s nonsense to work on software development in agile and on the rest in waterfall. A growth sprint makes the entire team work in agile. And Agile helps you pivot around obstacles.

A growth sprint is different from an agile sprint on many levels. First, it’s a unique backlog, as I said. And it’s focused on business a lot more than an agile sprint would be. Agile sprints are mostly focused on features, whereas a growth sprint is business-oriented.  A growth sprint is really about business outcomes, not features.

Another difference is that a growth sprint will bring together under the same umbrella the day-to-day production and the tests and backlog that are specific to an agile sprint.

So, a growth sprint is making everyone and everything work in an agile mode. It’s a lot more efficient.

Q. Is “growth sprint” the same as “growth hacking”?

Growth sprint is more than agile, lean, and growth hacking, but it borrows from these methodologies.

A growth sprint aggregates the different layers of a project.

A sprint usually focuses on software development. In a growth sprint, the different layers are added to a unique backlog.

For example, instead of preparing all the design upfront, this approach means we are deciding what elements of UX and U.I. we need before we create the assets.

And then, we add marketing. By bringing marketing on board, we are making everyone work together, and at the same pace. Proceeding this way avoids a typical situation where marketing is preparing stuff that is not in sync.

And through this approach, we can add to the project features that marketing needs.

We used a growth sprint approach for a client who had to build eight apps. Our team was the only one to deliver its app on time with no surprise from the money side.

Q. Why is growth sprint such an efficient method? What’s the magic?

The magic comes first from the fact that everyone is working together. No effort is needed to know what others are doing.

It makes risk management very efficient: because no time is wasted on matters not related to the North Star and with no potential of improving the bottom line, we reduce the waste and the risk. Growth Sprint is about putting growth first.

The growth sprint approach is also very successful because you don’t have to figure out the requirements for everything beforehand. It makes you much more flexible when you discover something under the hood.

With this method, you increase the transparency of the whole process and see the hurdles.

Q. Can a growth sprint approach be used for any projects?

The simple answer is: yes!

Of course, some types of projects can’t be released first using an iterative process like this one to make them evolve. But even these projects can use an iterative process before being released to the public.

Q. How difficult is it to implement?

The learning curve is not steep. There will always be some difficulties, but adopting this approach is not difficult in itself.

The thing people worry the most about when looking at agility is transparency. People are nervous about transparency. They fear surveillance. It takes a couple of sprints for them to realize that transparency is not about judging. It’s about helping you.

Most people love working with a growth sprint or agile approach because it’s easy to implement: you break down the work in small pieces, and it becomes a lot more concrete.

And there’s another reason people love working like this, and it’s specific to a growth sprint: people love that we are breaking down the silos.

Q. What potential problem could we encounter?

The main issue that could derail the success of your growth sprint approach is governance.

The sprint is a self-governed team. If all of a sudden, someone has the power to disturb the backlog in the middle of the sprint, it could kill everything. It’s going to ruin everything.

If you’re responsible, you are responsible.

At the start of the sprint, the team decides what will get done. You don’t assign stuff to people. People pick what they want to do, what they will work on, and commit to it.

Nobody outside the team should have the power to change the sprint.

Q. Any final thoughts?

The goal of agile methodology is to manage complexity.

The world has moved from complicated, linear projects to complex, nonlinear ones. Agile recognizes that fact.

Pretending that you can recognize requirements at the beginning of a project is dangerous.

That’s why I believe almost any project would benefit from a growth sprint approach.

Do you want to discuss your project with our team? Contact us now.