How reinventing to stay relevant lead to being an Agile Great Place to Work
Tze Chin Tang

Here’s the story of a once industry-leading organization that fell into the pitfalls of success: complacency, bureaucracy and aging technology. Through acquisition and merger, it was given the opportunity to be reborn itself as a nimble, agile organization. Keen to find out how a once-successful company reinvents itself through agile, so as to stay relevant and brand itself as a market-leading organization that is also a great place to work? If yes, then this talk is for you! We will cover the journey of two Southeast Asian online job marketplaces that were pioneers during the first dot-com revolution, only to fall behind as global competitors emerged. Both platforms were then acquired and merged to form a single entity. However that was merely the start of a new journey to not only stay relevant, but also to be renewed and stay successful. This sharing will highlight the journey of the leadership team brought together to revitalise, energize and reinvent once mighty giants, with the outcome of being recognised as winners of the World Agility Forum 2020’s Agile Great Place to Work Award. It will holistically look at the transformation of an organization, from how to create focus, invest in people and shape its organisational culture, to sustained development and delivery of effective products to customers.

Learning Objectives
I was an in-house coach, hired to develop and lead a team of Agile Delivery Leads (Scrum masters). Our initial goal was to support teams in adopting Scrum and other agile ways of work, however was quickly embroiled with the immediate need to restructure the organization and cultivate a single culture across this newly merged organization. I reported to the CIO and worked with the executives, my peers, managers and teams in my 3.5 years with the organization.

The challenged that was entrusted to me was to lead this reorganization to be a more agile company, never having done this for a product & technology organization of over 200+ people across 4 locations (2 sites in Malaysia, 1 in Hong Kong, 1 in China). I did not have a background in change management or restructuring, though I relied on the agile values and principle to guide the journey.

Through this journey, I have learned and developed the following concepts:
- Treat the organization as the product. We did not want to have a "big bang" restructuring. If we know that this is how NOT TO build a product, why would we build an organization this way? I treated the organisation as my product - what traits should it have? What are our desired outcomes? What measures of success should we measure? How designs would manifest these traits?
- Apply "inspect and adapt" when shaping the organization and culture. Develop the organization iteratively. We used quarterly "sprints", planning retros, created lots and lots of feedback loops across the organization and developed the capacity to respond to feedback internally.
- When it doubt, let the manifesto guide our transformation. Again neither I nor the leadership team were experienced with these level of transformation. When I doubt, I went back to the manifesto!

What I learnt: Agile works even when the organization is the product!

As this was a 3.5 year journey, there was plenty of learning! These are the things I/we did to the claim of "org as product":

Develop it iteratively like a product using typical agile practices:
- Used iterations (quarterly) where we kicked it off with planning, setting up a backlog, weekly standups, reviews and retros
- Made intentional tradeoffs (much like a trading off product attributes), to ensure clarity of priorities across the leadership team
- The "dev team" was the management team. Customers were our team members (engineers, designers, product managers, testers, etc..)
- Outcomes were guided by OKRs, and experiments were captured as backlog items.
- Senior leaders would pair-up to work on backlog items
- Impediments were raised during the weekly standups (though usually earlier through our Slack channel).
- I was the person who was most closely playing the Scrum master role, and the CPO & CIO were the joint POs.

The struggles were:
1. Aligning the "team members" - essentially my peers. To get them to work together, focus on priorities, not cheering picking or going off and doing their own thing. Pairing helped.
2. Surfacing and responding to impediments quickly. Impediments were 99% people problems - issues that teams surface that couldn't be solved internally, old policies, or just "stupid" stuff.
3. Burnout. Many of the my peers and CIO/CPO were overworked..had to slow down to maintain a sustainable pace. Putting in WIP limits helped.
4. Me trying to figure out how to add value as a "Scrum master" for the organization.
Agile Exchange
Session Type
Experience Report