Adopting a DevOps practice starts with understanding where you are in the implementation journey. Download the DevOps Transformation Roadmap. Brought to you in partnership with Techtown.

The move to Agile in the last decade has resulted in projects that finish faster, produce better software, and come in under budget. Look up any new, hot tech company and you’ll find articles lauding their Agile philosophy. You might think that success is guaranteed if you get your team to commit the Agile Manifesto to memory.

The problem with looking at this in a single dimension is that you’re affected by survivor bias. As you research, you look at successful projects and the logical next step is to look at what makes them successful. The problem that plagues most people is that they never ask the opposite–the darker, but equally important question–what causes projects to fail?

Jumping on the Agile bandwagon might help, but only if done right. What makes a good Agile project and what makes a bad one?

In our experience we see failure stem from an extreme focus on Agile timeline, which usually corresponds with the rush to code.

It’s an easy trap to fall into; you want to get to market and your team wants to build features. Planning is probably the least sexy part of a project. Business goals, product strategy, budgeting, timelines, resource planning, and task management don’t take people’s breath away. But behind every successful software project, there is a plan that was created in the beginning and maintained along the way.

Agile’s greatness is rooted in its adaptability, but first, you need a business and project plan to adapt it to. Don’t fall into the planning gap–under-planning is just as bad as Waterfall’s over-planning. What you are searching for is a happy medium where you plan enough to set your guardrails in place so you can know if your project is on track and headed in the right direction.