The biggest myth of agile development — faster, cheaper and better outcome
The good news is everyone is onto agile these days. The bad news is people are onto agile without knowing what it entails.
One of my biggest bugbears is the myth of faster, cheaper and deliver better outcome with agile, and here is why …
Origin (本)
The story of the agile manifesto is well-known in the agile community. Unfortunately, not many have heard of lean manufacturing which predates agile development and has a strong influence on agile development.
Many practices in agile development are heavily influenced by lean manufacturing and both methods have a similar philosophy, which emphasizes waste reduction. These two approaches differ in execution primarily because lean manufactures physical goods while agile develops digital products.
By reducing waste, lean manufacturing produces higher-quality goods at a lower cost.
Which begs the question, “Isn’t agile development faster, cheaper and deliver better outcome through waste reduction?”
The myth of faster, cheaper and better outcome
Yes. It does. Unfortunately, it is even easier to do agile without waste reduction.
Never underestimate the power of wishful thinking. It’s like sticking a Porsche decal on a bicycle. QED.
Sometimes, it happens when the delivery team or scrum master is inexperienced so you will want them to read this and send them for proper training.
In most situations, stakeholders or product owners don’t really understand the implications of agile development. They often believe that agile is something for the delivery team to do, while they can remain status quo. Unfortunately, nothing can be further from the truth.
For agile to be effective, stakeholders and product owners have to change their behaviors and provide a conducive environment for the delivery team. Else, they should just stick with traditional waterfall because doing agile without reaping the benefit is sheer stupidity.
Why bother when it’s all pain and no joy. Not even a masochist.
Seven wastes to eliminate
Waste 1: Partially done work (aka work-in-progress, WIP)
Such as detailed documentation and wire-frames and I don’t mean partially done documentation and wire-frames. I am referring detailed documentation, wire-frames, and plans that are yet to be implemented as code. Until they have been implemented as working code, these are WIP.
WIP worsens task switching, waiting time and the possibility of rework.
Unfortunately, people craves certainty and planning gives comfort, and some stakeholders and product owners have more emotional needs than others. 🤷🏻♂️
Plans, documentation, and wire-frames are proxies, with varied fidelity waiting to be implemented.
The amount of waste you can reduce depends on the risk appetite of your stakeholders. WIP is an unavoidable evil so strive to keep it low.
Waste 2: Extra processing
Obviously, don’t spend too much time to polish proxies such as plans, documentation and wire-frames.
Unfortunately when organizations are structured as functional groups, functional specialists tend to over-process because they are appraised to do so — planners are evaluated by their detailed and exhaustive plan, business analysts are measured by the thickest of their requirement documentation, and designers are… you get it.
No single raindrop believes it is to be blamed for the flood
This systemic waste cannot be eliminated by the agile delivery team. It requires organizational restructuring by the senior management, to align incentives throughout the organisation. This is why our people report within the squad in GDS. Mission-focused over functional-centric.
Waste 3: Task switching
Another side effect of functional groups is the tendency to assign each specialist to multiple projects, in order to fully utilize them.
Digital delivery activities are highly abstract and require creativity. Switching across tasks incur waste due to context-switching. Additional waste is incurred to persist the current state with reasonably high-fidelity, in order to be correctly resumed. It takes about 15 minutes to interrupt, persist the mental state and then resume work for every task switching.
Another common cause of task switching is meetings. If you must have meetings, always move meetings to the beginning or end of the day in order to minimize waste to the entire team. Understand the difference between maker’s time and manager’s time.
To be responsive to change requires slack. A fully utilized workforce is the antithesis of agility because it increases waiting time and delay. Yes, you are trading off utilization for responsiveness, so deal with it slave driver.
Waste 4: Waiting / delays
Excessive waiting often arises when the product owner is not collocated with the delivery team. The team needs the product owner to clarify user stories and validate their work when it’s completed. Waiting time can be disproportionately high when teams are distributed across different time-zones.
This impedes the team’s ability to get feedback from product owner during retrospective and from other stakeholders during sprint review. No or slow feedback means no or slow improvement, which causes persistent defects and repeated rework.
Meeting is the most common cause of delays — finding a common time slot, synchronizing room’s and people’s availability. If you must have meetings, here’s how to make the most of it.
Waste 5: Defects (rework)
The longer it takes to detect defects, more defects will be created and more waste incurred on rework.
The only solution is to shorten the feedback loop and rectify early. Daily stand-up, sprint review and retrospective session are the best avenues to obtain feedback, rectify defects and drive improvement.
Unfortunately, these sessions are often underutilized. The team requires a safe environment to share critical and constructive feedback, in order to level-up their game. The product owner must participate in and co-create this safe space.
Waste 6: Hand-offs
Like similar reasons for partially done work, extra processing and task switching, hand-off often arises due to functional organizational structure.
Knowledge is lost every time a deliverable or an artifact is handed-off across roles. This results in longer delay and higher defects, on order of magnitude more than the hand-off of physical goods. It is foolish to incur hand-off cost in favor of higher utilization of people, for digital work.
Waste 7: Overproduction
Overproduction is to develop features that are not needed by the users. The best way to prevent overproduction is to build the smallest possible feature or product (MVP) and validate the hypothesis before building a bigger and better version of it.
Unfortunately, overproduction often happens because of product arrogance by product owners and other stakeholders. They are often overly certain of their idea that they choose to skip the MVP and invest in a full-blown product.
Of all the wastes, overproduction is the worst because it exacerbates all other wastes.
Summary
Agile rituals and engineering practices are useful and will help your team improve their game. Unfortunately, the team’s performance improvement will soon hit-a-wall due to obstacles beyond their control.
These obstacles are also known as wastes — a term borrowed from lean manufacturing. They arise from excessive planning, functional organization structure, unavailable product owner, excessive meetings, lack of a safe environment for critical and constructive feedback, and product arrogance by HiPPO.
Surprise! There’s nothing magical about agile.
Agile makes these wastes visible, so that product owners and stakeholders can eliminate them. Otherwise, it’s just another fancy idea that produces more noise than substance.
I hope this article broadens your perspective on what’s important in agile and why it works.
Our team is looking for software/quality and devops engineers who are passionate about tech and want to help us build awesome digital services for Singapore! 🇸🇬
Reach me at steven_koh@tech.gov.sg (ゝ‿ ・)
Want to know more? Here’s how we operate and the work we do.
Cheers! 🍻
