What problem are we trying to solve?

No, really. Stop for a second and ask it plainly: what is the problem here?

If we are doing projects, we are problem solving. We are trying to help our business run more efficiently, compete more effectively, or do something it could not do before. That is the whole point. Everything else — the methodology, the tools, the ceremonies, the frameworks — is in service of that goal. Not the other way around.

The Problems Come in Every Shape and Size

No two projects are the same. The business problem might be a spreadsheet that one very clever person built five years ago to track customer orders, and which now has 47 tabs, three people who understand it, and zero ability to scale. Converting that into a real system that can be supported and maintained is a genuine problem worth solving — and it looks nothing like building a new customer-facing mobile app from scratch, which looks nothing like upgrading a twenty-year-old core banking platform that nobody wants to touch.

The permutations are endless. Third-party implementations. New builds. Re-platforms. System integrations. UI modernizations. Data migrations. Each one comes with its own constraints, its own stakeholders, its own technical debt, and its own definition of done. The common thread across all of them is the question you should never stop asking: where is the most value that can be delivered next, and how will we support what we are building once it is in production?

The Problem With Waterfall

Waterfall has a fundamental timing problem. Too much time passes before the people paying the bill start seeing any return on their investment. You spend months gathering requirements, months designing, months building, and then — finally — something gets released into the world. By which point the business has changed, the requirements have shifted, and several of the assumptions baked into that initial design are no longer true. The feedback loop is so long that course corrections are painful and expensive.

I have seen projects where a team spent six months building exactly what was asked for, only to demo it to the business and hear: "This is great, but we actually need it to do something different now." All of that time. All of that money. All of that effort — and the first real conversation about whether the software solved the actual problem happened at the end.

The Problem With Scrum

Scrum is a powerful framework, but it is not a universal one. It is best suited for greenfield development — new systems, stable teams, clear product ownership, and enough runway to build a healthy backlog and iterate over time. In that environment, it is excellent.

But most of us do not work in that environment most of the time. We work in organizations with fixed budgets and hard deadlines. We work with teams that are partially dedicated to multiple projects at once. We work on legacy systems where "sprint zero" turns into a months-long archaeology expedition. We work on implementation projects where the third-party vendor's release schedule has nothing to do with our sprint cadence.

Forcing Scrum onto a project that does not fit the model does not make the project more Agile. It just makes everyone frustrated — and gives the people who were skeptical of Agile in the first place exactly the ammunition they were looking for.

Being Agile Is Not About the Techniques

Planning poker is a useful technique for estimation — but on a project where the scope is well-understood and the team is experienced in the domain, you may not need it. Test-driven development builds quality in from the start — but on a project with a six-week timeline and a team that has never practiced TDD, mandating it will slow everything down without delivering the quality benefit. A physical Kanban board with sticky notes works great for a co-located team — but a distributed team across three time zones needs a digital tool, and there is nothing less Agile about using Jira or a well-configured board in whatever tool your organization already has.

Co-location is ideal. It is not always possible. Remote teams can be great Agile teams. The technique is not the principle.

Being Agile is about solving problems and delivering value in small, achievable increments. It is about getting feedback early and often. It is about learning as you go and adjusting to what you learn. Those things are true whether you are running two-week sprints with a full Scrum ceremony stack, or whether you are doing something more informal that fits the size and nature of the work.

In my view, it is better to bend or even skip one of the Agile practices and actually solve the problem you have been asked to solve, than to enforce a process the team is not ready for and watch the project fail by the book.

Start With the Problem

This is a complicated world. Time is a factor. Budget is a factor. Talent, experience, domain knowledge, organizational politics, regulatory requirements — all of it is a factor. The right approach to one problem is not the right approach to the next one.

When I am presented with a new challenge, I always start in the same place: what problem are we actually trying to solve? From there, I apply Agile values and thinking as fully as the situation allows. But I never — not once — let a technique or a principle become more important than solving the problem. The methodology exists to serve the work. The moment it starts getting in the way of the work, something has gone wrong.

Ask the question first. Let the answer tell you what you need.

Popular posts from this blog

The Agilish Method

Combining Agile and Waterfall methodologies into a cohesive approach, we call "Agilish" can be an effective way to deal with individuals and organizatons that struggle with the natural fuzziness of the Agile approach. Agilish offers the flexibility of Agile while accommodating the structured planning of Waterfall. This hybrid approach can help ensure that projects are adaptable while still meeting deadlines effectively. Here are a few tips to successfully implement Agilish: Start with a Clear Vision : Define the end goal and major milestones upfront, much like in Waterfall. This provides a roadmap that guides the Agile sprints. Iterative Planning : Use Agile sprints for iterative development and planning. Regularly review and adjust plans based on progress and feedback. Strong Communication : Maintain open lines of communication between Agile teams and Waterfall stakeholders to ensure alignment and manage expectations. Flexible Prioritization : Allow for dynamic prioritizatio...
Read more

Agilish — Your Get Out of Jail Free Card

Image
We do not live in a perfect world. Most of our industry has spent the better part of two decades moving toward Agile adoption, and the case for it has never been stronger. But there are still plenty of clients, managers, and organizations that are comfortable with Waterfall — and either will not or cannot change. You can make your case. You can share the evidence. And sometimes, at the end of the day, you are still doing Waterfall. This Dilbert sums up the challenge better than I can: Pick Your Battles Dale Carnegie famously argued that you cannot win an argument . Even when you are right. Even when you have the data. The moment someone feels they are being argued into a corner, they dig in — and you have lost them, regardless of the facts. The same principle applies to how we work and the methods we use. Sometimes the smartest thing you can do is let the client or the manager be right. Not because they are, but because the relationship and the work matter more than winning...
Read more

Blind Alleys and the Case for Incremental Delivery

Image
A friend recently shared a fascinating article about a mistake made by some of the greatest scientific minds of the 19th century. For decades, the best mathematicians and astronomers in the world were convinced there was an undiscovered planet — named Vulcan — orbiting between Mercury and the Sun, hidden from view. The math seemed to demand it. The calculations were elegant. The theory was accepted as fact. There was no planet. A Star-Crossed 'Scientific Fact': The Story of Vulcan, Planet That Never Was Two lines from the article stuck with me. The first: "It's easy to forget that there are people behind the data and equations. And when people are involved, there is always room for human error." The second hit even harder: "In science, you don't dwell on the blind alleys... but the blind alleys are most of what science actually does. You have to go down the blind alley, you bang your head against that blank wall at the end of it, come b...
Read more