From grief to agility

Steven Koh
Government Digital Products, Singapore
6 min readDec 9, 2016

Since the post on our agile journey, there were many enquiries on how their organisations can similarly be more agile. Many of them shared a misconception that things just worked right out-of-the-box in our journey, as if we have agile pixie dust 😊. So I thought this post can help to put things into perspective and hopefully alleviate their fear of unknown.

First, the numbers

Although we have about 150 specialists in Hive, this number is less than 10% of GovTech’s staff strength. The majority of staff in GovTech are seconded to other government agencies.

GovTech is only one, out of more than ninety government agencies. While we have made good progress, there is still plenty to do, and much to learn from everyone. This is only the beginning!

Second, the model

Changing people’s mindset is never easy, especially when people are invested and/or entrenched in traditional hierarchy and the waterfall approach. If you find this journey challenging, I assure you that you are not alone 👊😀.

If it’s easy, someone else would have already done it :)

I recently came across the Kübler-Ross model, a pretty useful model to explain the five stages of grief when organization moves from waterfall to agile. The five stages are:

  1. Denial
  2. Anger
  3. Bargaining
  4. Depression
  5. Acceptance

NB: Names have been changed to protect the innocent and guilty, from examples below.

Stage 1 — Denial

People in denial stage are not ready for agile. They don’t see the need. Neither are they intellectually curious to find out what they don’t know. You know they are in denial when they say things like,

  • “We know agile. Sprints are just like phases in waterfall”
Hybrid agile development proposal from a well-reputed vendor
That moment we saw ‘hybrid agile #1’ from vendor’s proposal 😱😱😱
  • “We keep the lights on. Our things are static and there’s no/little room to innovate. There is no need for agile in application maintenance.”

IMHO, it’s probably better to leave them alone because …

Stage 2 — Anger

When people in ‘denial’ are pushed to be agile without the support they want, they become angry and say things like,

  • “Our tender specs took us two years and almost a million dollar to craft. This mega project is going to be huge and complex. It is too big to be agile. Agile is for small companies and startups. Agile is good for small website and mobile app development. Agile lacks the structure. It doesn’t have the rigour and quality. It’s not secure and cannot scale to big projects like ours. By the way, will you please help us convince our bosses? We really don’t have time to redo the tender specs for agile.”
  • “QMS doesn’t support agile. Procurement doesn’t support. Audit will have problems with agile. And we have no agile tool to be agile. Our existing systems do not support agile. We are just not ready lah!”

Obviously, they should go for some training and/or seek agile consultancy. But unfortunately, this will delay the delivery. Simply put, they don’t have additional resources — time or money — to do things differently. Furthermore, no one wants to appear short-sighted for not considering agile during budgeting, so …

When people are in a catch-22 situation, their path of least resistance is to get someone else to say ‘no’.

And then some will end up in next stage.

Stage 3 — Bargaining

People are in ‘bargaining’ stage when they try to be agile without adequate knowledge of what they are doing.

A little knowledge is a dangerous thing — Alexander Pope

That’s when they say things like,

  • “Agile is for the vendor to deliver. The vendor will use our tender specs and agile deliver.”
Agile delivery by vendor. BAU for everything else.
  • “We have already spend six months developing the tender specs and now our boss wants us to use agile. Hmmm … Let’s get the vendors to turn these waterfall tender specs into user stories.” And then, a month later … “Prioritization? All these user stories are mandatory as per our tender specs requirement!”
  • “Regular feedback is for inexperienced consultants. We are very experienced. We already know what users want. It’s all in the specs.”

At best, it becomes a waterfall project disguised as agile. At worst, it becomes a dead ‘agile’ project that discourages others from trying. And in between, there will be …

Stage 4 — Depression

This is the stage where people either say, “Told you. My project is very complex. Agile doesn’t work here!” or …

  • “We are doing agile but the users have no time for us.” — It is a common mistake is to choose a trivial project to pilot agile delivery. If success of the project is of little significance to the users, they probably won’t invest their precious time to review the product and give feedback, every sprint.
  • “Our vendor’s velocity hits a record high of 100 story points but most features are broken.” — It is impossible to be agile without solid quality engineering practices. A good agile delivery requires unit tests and automated functional tests. Quality precedes agility.
  • Or “We have many agile meetings, agile gantt chart, agile sign-off sessions and agile status report. But agile still fails the same way.” — Chances are this is fake agile.
We need a [DevOps | Cloud | Chatbot | AI | the next buzzword] vendor

And hopefully they move on to the last stage where they look for an agile coach and try to salvage the situation.

Stage 5 — Acceptance

This is when people accept agile as a different way of working. They might not be most comfortable with it or like it. But they have accepted it and are learning to live with this new norm. At this stage, you will see:

  • Lesser product arrogance. Instead, there will be greater respect for frequent delivery, regular usability testing and ongoing user feedback.
  • People start to focus on outcome rather than output. Key features that deliver high business value become more important than feature count. Prioritization is the key.
  • Instead of teams in functional silos, who are at best merely cooperating and coordinating, there are more high-performing, self-organizing and collaborative teams that are small, co-located and cross-functional.

Summary

Human beings are creatures of habits. The more entrenched their habits, the more support they need. Use Knoster’s model to understand their needs and nudge them along.

Software is eating the world and agile is here to stay. Time is on your side, so pick your battles wisely.

If you enjoyed this piece, you might also like to know how we operate!

So let’s change the world, one share ❤ at a time! 😊

Cheers!

--

--

Steven Koh
Government Digital Products, Singapore

GDS Director@GovTech | Pragmatic optimist | Build high-performing teams, delightful products, and fun-loving communities | #techforpublicgood