Ever since Benjamin Franklin was hit by lightning while playing with his kite, we haven’t been able to live without energy. And as the world of technology keeps on evolving, that statement seems to be more accurate than ever. But, although energy is a central part of our daily life, the way we look at it has been changing over the past few years. New sources of sustainable energy, like solar panels or wind turbines, have gained in popularity as opposed to traditional fossil fuels. And Stedin wanted to be ready for this change.
Meet Stedin, the Grid Operator
Stedin, a grid operator in the Netherlands with over 3,000 employees, provides electricity and gas to two million customers in the Randstad and Rotterdam regions. Given the transition that the energy sector was going through, the Dutch company wanted to keep up with the change and do what it could to mitigate its ecological footprint as an energy company. So, Stedin assumed the responsibility of developing a sustainable, reliable, and affordable energy system while embracing an innovative mindset.
But, a few challenges quickly appeared on the horizon, holding the company back from its purpose.
"There were some challenges we had to deal with. First, our workload increased and became more diversified. Second, we felt the quality of our current level of service wasn’t going to meet future demands. Third, it was getting increasingly harder to attract and maintain technically skilled staff. And, last but not least, we needed to reduce operational expenses in order to enable the long-term investments to support this energy transition."
Martijn Van Ierland, RTE & Team Manager at Stedin
But that was just the tip of the iceberg.
"From an IT perspective, most of our technical collaborators were focused on maintaining commercial off-the-shelf software and not on development, and we still had a waterfall mentality. In addition, we were struggling to find people who were skilled and qualified in .NET, Java, and SAP—and we do a lot with SAP. So, simply increasing our technical pool wasn’t really an option."
Martijn knew it was time for a change.
Moving to Agile
After years with a stable environment, the sudden and rapid changes in the energy market required Stedin to become a more adaptable and flexible company.
“We needed to become more agile and build a development and operations oriented IT organization to focus on innovation and not on maintenance.”
To support this transition, Martijn and his team started looking for a platform that could back-up their initiatives. In other words, a platform that would allow them to develop and change fast while facilitating operations. All with Stedin people.
“Given our goals, low-code was the obvious solution. We evaluated a few vendors, but the ease of development with OutSystems and its mobile capabilities won our hearts. Not that we did a lot with mobile, but just the fact that it opened our landscape of possibilities was a winning factor.”
Another factor that affected Stedin’s decision was that with OutSystems, the company could attract people without an IT background and teach them to develop in a much shorter time-span and more easily than with .NET or Java.
Building the A-Team: Lessons Learned
Although Stedin had worked with scrum teams before, the journey with OutSystems wasn’t always smooth. With low-code development, the company was developing much faster than it was used to, which led to some pushbacks.
In an agile landscape, the product owner is the person responsible for managing the project and, thus, a key role. However, Stedin started its journey with an inexperienced and part-time product owner. But because the teams were working so fast, the product owner couldn’t keep up with their work.
Plus, in their previous scrum teams, Stedin was used to combining roles. So, for these new OutSystems teams, the company decided to have one person be a scrum master and tester. But, once again, the tester couldn’t keep up with the development teams. Also, she wasn’t able to be a good scrum master either, and that affected the speed of growth in the first few months.
After all these ups and downs, here are the top conclusions that Martijn and his team reached:
- A team shouldn’t have more than six people: the developers, a tester who acts more like quality control or a coach (the developers should be able to test their own work), a full-time and experienced product owner, a scrum master to coach the team. If the team gets too big, it’s preferable to split it. Otherwise, the PO, the tester, or both won’t be fast enough.
- Three developers with different levels of experience are enough, although one should always be a senior role to ensure the right decisions are being made.
- It’s not necessary to have a UX designer full-time; this should be more of a consulting role in early projects or when dealing with more complex ones.
- If you work with complex landscapes, like Stedin, with lots of integrations and dependencies between different systems and teams, it’s also useful to have a solution architect guide the development team, help them choose the best services, and show them how to integrate other applications.
The Final Results
Two years ago, Stedin had just a few scrum teams; today, they have 25, two of them fully OutSystems. Plus, 75% of its development projects are built by Stedin people. With this new organization, the Dutch company has built 16 new web applications with OutSystems—five of them critical to the business—and two mobile apps.
Most of these apps enable Stedin’s employees to work more efficiently. For example, the Product Configurator app automates handwork and standardizes the paperwork across different regions. It creates purchase order lists and automatically adds them to the financial systems in SAP.
Not only does Stedin develop more in-house, but the teams have also been able to increase their development speed.
“Our teams work in two-week sprints, and, on average, they deliver a minimal viable product (MVP) in just two to four sprints.”
As for the future, Martijn has this personal wish:
“In the future, I’d like to revamp our SAP applications with OutSystems from front-end to back-end. But given the dimension of SAP in our organization and the complexity of SAP, my idea is to adapt Gartner bi-model architecture. This way, we’ll keep SAP as our static and robust system of record, and on top of it, we’ll have OutSystems as a dynamic, easy-to-change system of engagement.”