I’m on one of our client sites to meet Sonny Lam: Data Explorer, Scrum Master and lounge wear extraordinaire. While I like my interviewees to feel relaxed, I’ll admit this is the first time I’ve ever questioned someone wearing slippers, and Pokémon ones at that. But whatever gets the job done, right?
I had promised to bring custard creams, but during the commute across London, it had unfortunately slipped my mind. I quickly throw some apologies in with my greetings / footwear compliments before sitting down to talk all things data.
…And just in case I almost lost you at that last line, I can promise there won’t be any mention of (whispers it) GDPR. Instead, I’ll be giving Sonny the Spanish Inquisition about using a data-led approach to delivering value using Scrum, turning chaos into calm and then consistency of delivery.
HI Sonny, it’s clearly been an exhilarating time for the client and a lot of change has happened since its inception three years ago.
Yep! In the last year alone, the company has experienced astronomical growth – going from ~300 people through three restructures, to ~3,000 people now.
The data warehouse was originally built for the finance team; a single, specific use case and it was done quickly, an MVP. However, as other teams heard about its potential and value, they wanted to utilise the data for their own objectives. Consequently, the warehouse had things added to it haphazardly.
As the company was expanding into new territories, more data was not only being acquired, but extracted for new things and the data warehouse was really struggling. It was being maintained by a small group of people and wasn’t built for scale because it lacked appropriate design, investment, support and infrastructure. Changes were being made directly in the live environment so bugs weren’t caught in time and had a knock-on effect that weren’t obvious until much later. It led to a lot of pain.
Why do think this happened and how did you come to be involved?
At a micro level, the data team grew accustomed to just delivering tickets; they needed to understand how to ‘deliver value’. At a macro level, more leadership and management was required to understand how to effectively engage the team and therefore capitalise on what it could offer. The business as a whole needed to be informed and educated about the team’s capabilities and limitations; it was simply seen as an under-performing data service centre. The analysts and data team didn’t push back as they felt there was no point, but even if they did, they didn’t really know how to.
In February 2018, 101 Ways placed a product team onsite to work on the main product platform. Three months later, a second team was brought in, specifically for data with me as the Scrum Master, with additional data engineers, QA and tech lead following shortly after.
It sounds like you were dropped in the deep end and experienced a baptism of fire. Where do you start with something like that?
It was sink or swim; I spent my first week observing and absorbing absolutely everything. I arranged a one-to-one with every member of the data team to understand them on a personal level in all aspects. I did a lot of walk-and-talk meetings, and spent a lot of time passive smoking with staff on cigarette breaks! I then took all of that honest feedback (and my newly blackened lungs), compiled it into a strategy and presented to the team their ‘Agile journey towards AWESOME’.
Awesome? Is that the technical term? Tell me more.
Yes! [Laughs] It’s a way of inspiring the team that there is so much more and building from there. I wanted to show the team that someone was on their side supporting and guiding them forward. That was the most important message to drum in, because it was clear the team needed more love!
My job was to give whoever needed it, the courage to say ‘no’ and ‘why’, but also ‘here are other options to achieve the same thing’. In a large organisation that is growing at speed, no-one says ‘no’, especially if they’ve exclusively always said ‘yes’. I became a daily human shield when they had to challenge poor requirements with actual value.
Where did that journey begin?
With a vision via a slide presentation! [Grins and shows me the below]
Doing it this way, I could:
- Empower the team – inspire them to give more as an individual and even more as a team;
- Show them the strengths they already have;
- Show them the pain they currently suffer from;
- Introduce the team foundations to build upon.
- Show them the vision (The ‘what’)
- Go through the ideas to get them there (The ‘how’)
As a result, the team knew (at least on paper) what the ‘journey towards awesome’ would look like. To get there, it was about having someone with a specific experience and balance; someone who was always willing to do the right thing that invested in the long term over the short term, which is hard.
Going into a difficult environment and pressing the ‘restart’ button isn’t always easy, or even possible – what challenges did you face in terms of changing both people and process?
There had been a lot of growth, with new people joining and with each restructure, you’d lose people with essential historic knowledge and therefore lack any sort of delivery consistency. Habits are hard to break – especially bad ones. You can’t expect to change everything straight away, it’s about identifying which practices are valuable and finding ways to turn those into habits.
I started small, with team lunches and sharing chocolate goodies, so that we got used to coming together as a team. [Clearly a snack fiend, I feel another pang of guilt at my earlier empty-handedness]. It may seem basic or unnecessary, but actually encouraging the team to share nice moments helped them bond and fostered a good atmosphere. To see the positive outcome of this investment took about three months, but building a new culture is always a work in progress.
Why did this situation call for a new approach?
It became clear that I needed to establish a ‘why’ within the team. There was no purpose; the analysts were there and were grinding away, but they didn’t really know why or how they were adding value for the wider business. Even senior management and other teams I asked, regurgitated what they thought was the company mission, but I felt there needed to be more. This lack of clarity had filtered down to the teams and left them wondering what their role was, or worse, not caring. So I created a team mission statement to align the data team and communicated their new vision of why they were there.
Afterwards, whenever the team did something, it wasn’t just for the sake of it. Either they were solving problems or improving the working processes, but always with a focus on value.’
Traditional Scrum tactics have been tried and tested in complex environments before with success, what was the problem here?
Quite simply, it wasn’t working. Domain knowledge was lost as people left and a huge effort was required to get new hires integrated in a complex situation. Story points used up incredible amounts of time and resources unnecessarily. An aspect of being lean in Agile is about removing waste so there is nothing left but value. If something is not valuable, it is wasteful. The lack of team maturity due to all the changes was leading to an incredible amount of waste and so I felt there had to be another way, another option.
That’s when you brought in the ‘no estimates’ approach?
Yes, there are many ways of doing no estimates, but at base level, it’s about breaking things down. In a similar way to story mapping. I used the Tim Ferriss DiSS framework:
- Deconstruct – Break it down (to fit your context);
- Identify – What takes 20% effort and gives 80% value?
- Select – Group together all the priorities that make sense or can be delivered together;
- Sequence – Arrange and order it for delivery (again fit it to your context).
I had the data team break down the tickets into single, achievable pieces of work, deliverable within three days. This immediately revealed dependencies affecting delivery outside the team, whether there were any unknowns and showed us where to dig deeper if required. Doing this gave the team the balance and flexibility to focus on value – and delivering it as a priority – rather than churning out big chunks of work where not all of it was necessary.
From there, we would load up the next sprint conservatively and measure the throughput data in terms of lead time (customer request to delivery), cycle time (the time work begins to delivery) and my own customised measurement of local lead time (when we’ve prioritised and committed to it in the sprint to delivery).
What was the benefit of doing it this way, including the customisation?
It helped manage stakeholder expectations; you need to understand where they’re coming from as well as speak their language. Here, the leadership team and stakeholders wanted to know ‘How many sprints will X take?’ and measuring local lead time gave us the answer.
It took time, but eventually the data team understood that poorly crafted tickets were not good enough. We needed a certain level of refinement in order to achieve ‘awesome’ and I gave them the courage to only accept awesome.
It can be hard to go against the grain, especially when you have opinions from those that had ‘been there and done it another way’. How did you build trust in the alternative and in your leadership?
By engaging constantly, supporting teams, their members and showing the value it created, even when it wasn’t my role to. Being ahead of the game in terms of requirements; I gave people what they needed before they asked for it. Whether that’s professional support or office biscuits and some extra time off to do important personal things, it doesn’t matter. You’re showing integrity.
I believe in going above and beyond as a leader because it fosters a mentality of ‘all in it together’. If I do it for them, they will (hopefully) want to do it for me and others.
When priorities were being delivered – in some cases ahead of time and to the level expected – the trust grew and the pressure from senior stakeholders decreased somewhat. Leading with data allowed us to provide a more informed approach to decisions, commitment and expectations.
When you go into the office and feel the team’s energy, see their hunger for challenge and increased engagement, that is when you know you are on the right path.
Presumably this reduction in pressure translated to the data?
Of course – when I started in July 2018, out of 37 tickets, only three were delivered by a team of four people (~8% of what was committed to). Within a month, over 80% were delivered when the focus shifted to achievable value, and it’s been maintained at 60% or over ever since, even with so many team and organisational changes.
Every sprint has a context. Month-to-month during 2018, we were expanding into new markets: Italy, Brazil, Spain, USA etc. While the statistics were not perfect, as it’s knowledge work, it gave a good indication of what happens during each sprint and the variables affecting it. It’s about using data to understand which decisions have impacted delivery, how and why. Things like recruitment losses, additional, urgent tickets, holiday periods, sickness, lack of expertise and knowledge. We were able to see that losing a senior engineer cost us five-to-six tickets.
What did that mean in terms of actual sprint times?
We could measure the cost of bad decisions. Using the data, we could show senior stakeholders that if they wanted to do ‘X’ without due consideration, it will cost us ‘Y’ amount of days, which would put other delivery at risk. For example,we could ‘show’ building a bespoke dashboard without clear requirements and refinement had cost the team 11 days of effort and where most of the effort was focused. When initial perceptions from the top was that it would be a ‘quick’ thing to build (less than four days).
Prior to the client’s partnership with 101 Ways, a user story could take two months (54 working days / four sprints) to deliver and this was, wrongly, accepted as the norm. With a data-led approach, we improved to single digit working days to deliver value. It allowed me to communicate in the same language as senior members of the business and show the rewards of investment in a balanced process and more importantly, changing the mindset. If they gave us what we needed to be awesome, we could deliver what they wanted and more quickly.
While we couldn’t measure feelings or morale, each statistical improvement also backed up all the good vibes going on at team level.
You’re moving on to a new role, what would you like your legacy to be?
In my opinion the mission of any Scrum Master is to make yourself redundant, but ultimately I hope that I delivered value and made a positive impact. More importantly, I left happy and safe in the knowledge that the data team knew the difference between ‘ok’ and ‘awesome’. Job done.
And with that, Sonny and Snorlax head off to their next meeting. Let’s hope there’s biscuits.
