A Look at the Strategy of Agile Methods
Different trade-offs with different objectives
There has been much debate around how we work in the past decade with a “battle royale” of sorts playing out. This was the inspiration behind this article. There isn’t a perfect universal strategy out there that is always “right”. Which is “best” is all about what you are trying to accomplish and what you have to try and accomplish that with.
In management there are three aspects which form the foundation of getting work done:
- What are we committing to do
- How long do we have to complete the work
- How many resources to invest
These three elements work in conjunction and trade off with each other. Trying to solve these separately or fix all three at the same time is a major red flag. You are going to experience problems in all cases using that approach except in the rarest of perfect circumstances.
Strategy is how you accomplish your objectives and goals.
The differences between traditional and Agile approaches
Traditional vs. Agile
- Commits to a when (schedule) and what will be delivered vs. commits only to maximizing delivery with given resources and schedule
- Grows resources as required vs. change what will be delivered as required
- Everything is important vs. optimized for prioritization
- Makes a major assumption that we know a ton up front vs. makes it easier to fix, pivot and adapt during the process
- Problems discovered near the end vs. problems surface quickly
- Uses phases in sequence, where all items are ideally delivered for that phase only vs. breaks items up into chunks, all phases for those items are ideally delivered at the end of each chunk
- Requires locked down requirements (problems to be solved & solutions to be built) vs. allows for adaptation of requirements as the process unfolds (problems to be solved & solutions to be built)
Traditional methods (Waterfall) require a great deal of certainty up front and account best for iteration within a phase, not on the requirements. It is good at correcting for execution errors.
Agile (Scrum/Kanban) provides feedback in fast short increments on requirements. It is good at adapting to changing requirements and incorporating larger feedback. Since the cycles are short time-boxes this also comes with a low cost of having to “try again” on any requirement.
In Winston Royce’s own 1970 paper where the waterfall method was introduced he says:
“I believe in this concept, but the implementation described above is risky and invites failure.”
What Agile does is take the sequential method but uses it at a “feature” level rather than on the whole product at once. This greater reduces the impact of the risk Winston is calling out.
Thinking in trade-offs
- If you have fixed resources, then you either need to be flexible on the delivery schedule or in what you’ve committed to delivering
- If time is fixed, then you need to adapt what you’ve committed to or the resources you’re planning to invest, in order to fit your schedule
- If you cannot change what you commit to deliver, then you either need to adapt the delivery schedule or the resources you’ve budgeted for accordingly
Hopefully this effectively conveys the trade off concept at the foundation of management; what we are committing to do, how long we have, and how many resources we invest to complete the work.
You cannot fix all three aspects when you are getting work done and have a high probability of success.
So what does agile bring to the table? The ability to deliver complete items, to more robustly demonstrate progress, the ability to surface issues, and the ability to adapt requirements as circumstances change. It accomplishes this by breaking the work up into smaller chunks covering all phases instead of independent phases covering all items.
Both traditional methods and Agile methods have a place. That being said, in most projects there is uncertainty, acknowledged or otherwise, which means Agile is worth serious consideration. In today’s environment it is looking more and more like it is needed.
