SKF - Nordcloud

Home Case Studies SKF

Project Summary.

Services provided:

Cloud Migration and Modernisation DevOps Support

In partnership with:

AWS

Client industry:

Automotive Manufacturing

Client location:

Sweden

Q: What business challenges were you trying to overcome when you started the cloud journey?

We have service contracts with customers where engineers monitor bearing performance and provide necessary maintenance. It’s time-intensive work, and it’s a cost-competitive market.

We wanted to develop a cloud-based predictive maintenance application that would remotely monitor bearing performance, reducing the need for site visits while improving responsiveness for our customers. The driver was a clear business need to offer better services more profitably.

Having envisaged that business objective, our technical strategy involved a digital layer that enabled continuous interaction between products, customers and us. We knew it would need machine learning, data lake capabilities, and databases for analytics, and decided to go for AWS and use a microservice architecture.

Q: How were you managing upskilling before starting work with Nordcloud?

We had cloud experience in the German teams – we’d started the journey back in 2000 and used a private cloud from 2004 until 2012. So there was a base level of understanding. The team started out as 2 developers but quickly expanded to 20, including remote members.

Feedback was that things felt inefficient and that there wasn’t enough visibility of other people’s workstreams. Even though I’d run workshops and everyone was familiar with the Agile Manifesto and the Scrum Guide, we were struggling with the implementation around enabling people to work with in the new way, particularly the mindset shift.

It became clear that we needed external agile coaching support to work alongside the team and embed agile practices.

Q: What learning pathways were implemented and what was the experience like for tech and non-tech people?

With Nordcloud’s input, we decided on a bottom-up approach to enabling the team. Scott, the agile coach, spent 3 weeks just joining meetings and listening, building a picture of how we were working. Based on his diagnosis, we restructured into 3 smaller, multidisciplinary teams that included a product owner, a scrum master and developers with different specialties.

We clearly divided responsibilities within the team, so roles were well defined and upskilling requirements were clear.

Restructuring the teams

Restructuring the teams was a key milestone – this gave us a manageable unit for agile and technical enablement.

Identifying the problems

An offsite team day we had about 2 months in, which included the remote teams who visited us for this event. Nordcloud ran it as an open space with discussions on different topics. The coaches and I were moderators taking notes while the team discussed the challenges. This had a big impact. To change the culture, the individuals needed to identify the problems themselves.

For example, the topic of code reviews – a consensus emerged that this was an issue where we needed a better way of working. Retrospectives felt boring – we agreed to try a new format. It got really granular – should cameras be mandatory in meetings, so there’s more connection with the remote teams?

Because the teams were recognising and workshopping the challenges, there was more impetus for change. They felt in control, not that this was something imposed onto them.

New product ownership framework

Implementation of a new product ownership framework. As Chief Product Owner, I had been heavily involved in all the roadmaps, architecture and technical dealing. With the new multidisciplinary teams having more autonomy, I was able to relinquish day-to-day control to individual product owners, giving me more time to focus on the overall roadmap and customer value.

Under the new framework, product owners now have responsibility for months 0-3 in the roadmap, deciding on features to be deployed. Months 4-9 are my responsibility, so we stay aligned to the vision.

Q: How long did it take until people felt confident in the new tools and ways of working?

From the time we realised upskilling was required for agile to be effective, it took about 8 months for the teams to be enabled from a technical perspective. This was in terms of getting the first real version of the CI/CD pipeline finished. This is important, because without the pipeline, development processes took an awfully long time, which undermined and even prevented agile thinking. With automated integration, testing and deployment, we can roll out releases quickly. You can see the impact sooner and you can react – which is exactly what you need to be agile.

The technical training started before the agile coaching, so the teams were comfortable with the environment before we delved into the conversations around delivering value every sprint, having, for example, a common pipeline. It was a reasonable pace.

For the agile element of the journey, it took about 6 months to transform and then another 6 months before we felt like experts. I’m pleased at how quick the process has been, and having the coaching was instrumental in this.

But of course, this is about lifelong learning as we continue to expand skills within the teams and wider organisation. The aim was to reach a tipping point where we no longer needed coaching and could own our journey going forward. In fact, the Nordcloud coach even said: “You no longer need me – the teams are enabled to run with it now.”

SKF

Bring an agile coach in as early as possible. I tried to do it on my own, but I didn’t have the bandwidth or experience. Get an external expert who’s objective and understands how to embed skills.

Jens Greiner

Global Manager – Digital Solutions

Bring an agile coach in as early as possible

Bring an agile coach in as early as possible, and have someone familiar with your context. I tried to do it on my own, but I didn’t have the bandwidth or experience. Get an external expert who is objective and understands how to support cultural transformation.

Take a bottom-up approach

Take a bottom-up approach. Team buy-in makes a huge difference. It’s about leading, coaching and empowering. From my perspective, this sometimes means accepting decisions I’m not super happy with because I’m respecting the team’s autonomy.

Have a failure-friendly culture

Have a failure-friendly culture where vulnerability is encouraged. In a traditional waterfall setup, success is defined at the beginning, so you can’t kill a project partway through if it’s not working. You waste money because you’re pursuing something that won’t deliver the right value.