What project management methodology do you use? I hear a lot of business owners, who are terrible at planning, throw agile around a lot. I have seen companies retool their development lifecycle for agile, hiring a certified scrum coach and setting up a scrum process only to leave a bad taste in their mouths when things don’t go as expected. To get to the root of this you have to understand what each of these processes is and their strengths and weaknesses.
In the end, the development you do needs to meet a specific business need, but you’ll find this difficult if the business owners are unorganized, don’t have clearly defined goals and objectives, or aren’t able to put together a marketing plan that they can stick to. Many business stakeholders think that agile is perfect in these situations because, you know, it’s agile…right?
Well, agile is flexible because you are able to redefine targets, goals, or priorities through the length of an ongoing program, but agile has a strict and rigid process that needs to be followed or the whole thing could come apart and often times, what leadership doesn’t understand is that the agile process was created to get something quick to market and then iterate and improve after launch. What this means is you need to be very disciplined in defining your minimum viable product vs your minimum desirable product and you have to be able to clearly prioritize your features to help you define your product roadmap.
One of the best ways to assess priority is to clearly understand what the organization’s goals are over the next year and how these features roll up to support those goals. It could be brand recognition, brand awareness, marketing, sales, user growth… if you understand what the goals are it will help you better align features and functionality to support those goals. You can choose the biggest impact, lowest effort, strategic partnerships or any other number of criteria and then work on features that support those efforts.
The next step is to break down the different features or functions into their most basic deployable components. Once you have done this, you can work with the engineering team to start estimating level of effort. I like to have a work breakdown structure for each of these features and the level of detail I break these into depends on the accuracy of the engineering team’s estimates. If you have a seasoned engineering team, you can leave everything pretty high level, but if you have a team that isn’t very accurate with their estimates or are new to a product architecture, you should break everything down. If you ask an engineer how long it takes to build a KYC form and they quote you a couple of hours it’s best to ask them about setting up the database, validating fields, will they have to integrate with any 3rd party APIs to validate those fields, how is the data going to be stored…?
After you have the estimates, you can loop the business back in and start to build out the roadmap. You can question the business with how this feature will tie back to their team’s overall goals and how those will support the company’s goals. Compare this against the engineering effort to try and get the most impactful features in the product in the quickest amount of time.
Agile is great for a maintenance queue, when iterating and improving on a product that is out in the wild or when launching a net new product, but the scenario that I really have to consider the pros and cons of agile would be a major replatform. In many cases, a replatform is replacing a system that has been custom built over many years with an off the shelf enterprise solution. These enterprise solutions are usually very robust with a lot of best practice features, but I have found that a lot of organizations have customized their systems to follow a legacy process and support a team who may have created their process 15 or 20 years ago. In these scenarios, it takes a tremendous amount of customization to a new system to reach parody of the legacy system and this is what they often look for when they are defining the minimum viable product. If you try and implement an agile framework in this case, without hiring a separate team to implement the new system, the business will feel like they are losing out. The engineering team will not be able to keep up with the maintenance requests, handle the day to day and the new systems program will suffer because the business will constantly be changing priority. If the business does some work to the legacy system while the replatfom is underway, they will most likely lose that functionality when the new system is set up and launched.
Most of the agile projects that I have set up, work well in two week sprints, planning out five to six sprints ahead of development. That means that product requirements and user stories are defined ten to twelve weeks out. In other words, we lose velocity, efficiency, and have wasted effort if we try to make changes to the roadmap in anything shorter than ten to twelve weeks. It is because of this, leadership and business who don’t understand the process are left with a bad taste in their mouth.
Key Takeaways for Organizations Implementing Scrum
- Agile ≠ chaos. Flexibility in Agile comes from disciplined iteration, not from changing priorities every week. Without structure, the process collapses.
- Scrum works best with clear goals. Before adopting it, leadership needs to define the organization’s 6–12 month goals (growth, awareness, revenue, retention, etc.) and ensure product features tie back to those goals.
- Minimum viable vs. minimum desirable. Success with Scrum requires discipline in prioritization, focus on what gets the product into the market, not a wish list that mirrors your legacy system.
- Feature prioritization is strategic, not tactical. Use criteria like biggest impact, lowest effort, or alignment to strategic partnerships, then validate with engineering estimates to find the best trade-offs.
- Break work down to match team maturity. New or less experienced engineering teams need detailed breakdowns to estimate accurately; seasoned teams can handle higher-level planning.
- Beware of replatform pitfalls. Scrum is sometimes a poor fit for replatforming projects, where replacing years of customization with a new enterprise system leads to endless reprioritization and frustration.
- Plan ahead. Even with two-week sprints, good Scrum teams have requirements and stories defined 10–12 weeks out. Constant roadmap changes inside that window destroy velocity and morale.
- Don’t confuse maintenance and replatforms. Scrum excels for iteration, improvement, and net-new products — but it can fail when stretched across large-scale replatforms without dedicated resources.