How to get the most out of agile development

The good news - everyone is onto agile development these days.

The bad news - many are onto agile development without knowing what it fully entails or how to get the best out of it.

One of my biggest bugbears is the myth of delivering a faster, cheaper and better outcome with agile development, and here is why.

Origins of agile development

The agile manifesto is well-known within the agile community. Many practices in agile development are heavily influenced by “lean manufacturing”.

Both methods adhere to a similar philosophy of waste reduction. However, the two differ in execution primarily because “lean manufacturing” produces physical goods while “agile development” produces digital products and services.

By reducing waste, lean manufacturing produces higher-quality goods at a lower cost. Which begs the question, “Is agile development faster, cheaper and deliver better outcome through waste reduction?”

The myth of faster, cheaper and better outcome

Yes. It is. But it is also easy to do agile development without waste reduction.

This happens when the delivery team or agile project leader is inexperienced. If this is the case, you should consider reading this and sending them for proper training.

In most situations, stakeholders or product owners don’t really understand the implications of agile development. They believe that agile development is something for the delivery team to adopt and execute, while they can remain as status quo. Unfortunately, nothing can be further from the truth.

For agile development to be effective, stakeholders and product owners have to reduce wastage by changing their behaviours and provide a conducive environment for the delivery team. Otherwise, teams should stick with traditional waterfall development.

Here are seven types of wastage teams should eliminate to maximise the potential of agile development.

Seven types of wastage teams need to eliminate in agile development

Wastage 1: Partially completed work (aka work-in-progress, WIP)

WIP refers to detailed documentation, wire-frames and plans that are yet to be implemented as codes. Until they have been implemented, these are classified as WIP. WIP worsens task switching, waiting time and the possibility of rework. Unfortunately, human craves certainty and planning gives assurance. Some stakeholders and product owners require more assurance than others. WIP is an unavoidable evil, so strive to keep it low. The amount of waste you can reduce depends on the risk appetite of your stakeholders.

Wastage 2: Over processing

Do not spend too much time on refining proxies such as plans, documentation and wire-frames. Unfortunately, when organisations are structured as functional groups, functional specialists tend to over process because they are appraised by their ability to do so. Planners are evaluated by their detailed and exhaustive plans, business analysts are measured by the thoroughness of their requirement documentation, and designers are… you get the idea.

The agile delivery team will not be able to eliminate this systemic waste. It requires organisational restructuring by the senior management to align rewards and incentives throughout the organisation. Mission or task focussed teams should be prioritised over function centric teams.

Wastage 3: Task switching

Another unintended consequence of having functional groups is the tendency to assign each functional specialist to multiple projects.

Digital delivery activities are highly abstract and require creativity. Switching across tasks incur waste due to context-switching. It cost about 15 minutes to interrupt and resume a task.

Another common reason for task switching is meetings. If you must have meetings, always move them to the beginning or end of the day to minimise waste to the entire team.

Wastage 4: Waiting time

Waiting time can be disproportionately high when teams are distributed across different time-zones or physical locations.

Imagine a scenario where a team needs the product owner to clarify user stories and validate their work only when it’s fully completed. This impedes the team’s ability to get quick feedback from the product owner during reviews. No or slow feedback leads to little or no improvements. This, in turn, leads to persistent defects and repeated reworks.

Wastage 5: Defects (rework)

Defects lead to more defects. The longer it takes to detect defects, the more wastage will be incurred on reworking and rectifying the defects.

Here’s a possible solution: shorten the feedback loop and rectify early. Daily stand-up meetings, sprint reviews and retrospective sessions are the best avenues to obtain feedback, rectify defects and drive improvements. Unfortunately, these sessions are often underutilised. An agile team requires a safe environment to share critical and constructive feedback. The product owner must participate to co-create this safe space.

Wastage 6: Hand-offs

Every time a deliverable or a project is handed-off across roles, wastage happens. Tacit knowledge is often lost in the process of handing off. This leads to more delays and defects. It is foolish to incur “handing off” cost in favour of higher utilisation of people.

Wastage 7: Overproduction

Overproduction or developing features that are not needed by the users is the final type of wastage. The best way to prevent overproduction is to build the smallest possible feature or product (MVP) and validate it before building a bigger and better version.

Unfortunately, overproduction often happens because of product arrogance. Product owners and other stakeholders often overly certain of their ideas and hypothesis and choose to skip the MVP to invest in a full-blown product.

Of all the wastage, overproduction is the worst because it exacerbates all other forms of wastage.

Agile development makes these wastages visible, so that product owners and stakeholders can eliminate them. Otherwise, it is just another fancy idea that produces more noise than substance.

I hope this article broadens your perspective on what is essential in agile development and how it can work better. Reach me at steven_koh@tech.gov.sg for comments and feedback.

This article was first published by the Government Technology Agency of Singapore on Feb 16, 2019. The opinions expressed in this publication are those of the authors. They do not purport to reflect the opinions or views of Bank of Singapore Limited or its affiliates.