You may remember the 1978 movie Grease, with all of its slicked-back hair and famous choreographed dances. One of the best-known songs from the movie is “You’re the One That I Want,” performed by John Travolta and Olivia Newton-John.

“You better shape up / You better understand / To my heart I must be true!”

Olivia’s character tells Travolta’s character he needs to “shape up” and improve, or else their relationship isn’t going to work.

If you’ve spent any time in the custom software space, you’ve likely experienced some challenges that need shaping up. Some of the most common include:

• Team members feel like projects go on and on with no end in sight.

• Product managers don’t have time to think strategically about the product or what users truly need.

• The business wants features out the door faster and faster.

The 1970s saw the invention of the Waterfall methodology for custom software development. It was based on Henry Ford’s methods in 1913 for making factory vehicles more efficiently. However, the Waterfall model had challenges with long, drawn-out build cycles. Software could often take years to ship, and by the time it was complete, it was immediately outdated.

Though Waterfall proved popular for very small, fixed-schedule projects, it doesn’t work as well with larger, more complex solutions. For my own projects, it’s never been worth the risks Waterfall might have introduced—especially with the amount of dependencies on outside integrations.

Agile was first introduced in 2001, when 17 technology experts drafted the Agile Manifesto. They wrote four major principles for Agile project management, with the hope of helping teams develop better software:

1. Individuals and interactions over processes and tools

2. Working software over comprehensive documentation

3. Customer collaboration over contract negotiation

4. Responding to change over following a plan

Rather than basing it on a factory, the experts used the sport of rugby to describe how a “crowd” progresses across the field together. The origin of the word “scrum” in software goes back to an article in Harvard Business Review titled “The New New Product Development Game” by Takeuchi and Nonaka. It pulled from examples at companies such as Honda, Canon, and Fuji-Xerox—and described how new products were designed and rolled out in cross-functional teams with an ‘all-simultaneous approach.’

Agile is the most common framework I’m used to. It’s progressive and allows for iteration of a product. In fact, we typically see this methodology in about 90% of custom software projects.

But enough of a history lesson—let’s talk about a third methodology: Shape Up.

With Shape Up, by Basecamp, work is done in six-week cycles—just long enough to build something of value but short enough that everyone can feel the deadline approaching. The goal is to build, do quality assurance, and release in just one six-week cycle. When the new feature for the product ships after six weeks, the team is happy and so are the users. Time well spent!

Instead of breaking a large amount of work down into smaller, sprint-sized chunks as you would with the Agile method, Shape Up holds fixed to the time and allows the product team to release value every six weeks.

The building phase is uninterrupted:

• While in cycle, the team is in the shape/build phase uninterrupted for six weeks.

• After that, the product is released, and the team has a two-week bet/cool-down phase.

• They then enter into another six-week shape and build phase.

You may have noticed that the two-week phase is called a “bet” phase. If you are transitioning from Agile, you might have a hard time with this one, but backlogs can often be time-consuming anxiety builders for a product team. They also get outdated fast.

For example, an idea nine months ago might not have the same relevance or impact as it does today, so why spend time tracking it? Another benefit is that the best ideas keep coming back to bet on.

Though we’ve had longer sprint cycles before, this Shape Up framework is new to our team. My prediction is that it will work best for internal projects that have limited integrations and dependencies.

Now that you know a bit more about how Shape Up works, how should you choose which system works best for you? Here is a list of considerations that may help you make decisions about what to use:

• Project length: Agile employs short sprints, typically lasting 1-2 weeks, while Shape Up uses fixed six-week cycles with a subsequent two-week cooldown period.

• Focus: Agile is centered around rapid iteration, customer collaboration, and continuous feedback. Shape Up, on the other hand, focuses on strategic, uninterrupted work phases with designated times for review and planning.

• Team interaction: In Agile, teams engage in daily standups, sprint reviews, and retrospectives. Shape Up encourages periodic reviews and planning sessions after each cycle.

• Output: Agile aims for incremental updates and frequent releases. Shape Up targets complete deliverables at the end of each cycle.

• Documentation: Agile prioritizes working software over extensive documentation, while Shape Up necessitates more structured and detailed upfront planning.

I’ve been a part of leading and collaborating with product teams for more than 15 years. My experience is that we will need to continue to grow and improve as we seek to find ways to design and develop custom software that meet user’s needs and create value for the business.

Just like with new diets and workout programs, it’s the execution of the new approach that makes it work.

At Michigan Software Labs, we welcome the opportunity to choose new systems that will work better for certain clients. Shape Up might just work well for you.