Improving the Developer Journey at NS
The developers at NS are making a difference in daily travel operations and experiences! We (Development Enablement team) are empowering them to do just that. This article is all about sharing our progress in enhancing the Developer Journey at NS.
Abstract
The NS Development Enablement team aims to improve the Developer Journey and Developer Experience (DX) by addressing challenges in the application development process, such as inefficient handling of non-standard needs that cause developer frustration. The goal is to make development at NS as smooth as possible.
A roadmap lays out steps for improvement, beginning with creating transparency around development capabilities using the DORA.dev framework. The team mapped out tools and services to these capabilities and developed a dashboard to give developers clear visibility of the available resources. Initial feedback to this approach is positive, indicating valuable steps toward better DX at NS.
For who is this article?
Anyone interested in Platform Engineering and DX.
About NS
Nederlandse Spoorwegen (NS) is the principal passenger railway operator in the Netherlands, providing essential transportation services to millions of people every day. As an organization, NS is committed to delivering safe, reliable, and sustainable train services while continuously striving to improve the overall travel experience for its customers. NS also plays a key role in promoting eco-friendly transport solutions and contributing to the reduction of carbon emissions. Embracing innovation and technology, NS is on a mission to adapt to the evolving needs of its passengers and maintain its position as a forward-thinking leader in the railway industry. Examples of IT services you may know of NS are OV-Fiets, NS app and NS travel information (signs on the stations).
Let’s set the premise of this article by starting with the problem statement.
Problem statement
Img. 1 shows the context of the improvement and some of the pain points we identified early on.
It’s safe to say that very few individuals have comprehensive knowledge of all the activities throughout the entire Software Development Life Cycle (SDLC) for their application. To rephrase that, no one knows everything, and you need to pull missing knowledge into the team to be effective as a development team. But constantly pulling in new skills in the team can be a huge distraction for the team. So, how can we make the most of our time? The central platform organization (CPO) at NS is there to support teams so they can make use of standard components for development activities. This means that teams won’t have to pull that much all the time, which is great news!
The platform organization acts as a central hub of support for our platform solutions. It brings together diverse expertise to streamline the development process, which is a huge benefit for everyone involved. By pooling resources and collaborating effectively, teams can leverage the collective wisdom and experience needed to deliver high-quality features that cater to the needs of our travelers.
For single tools where only a license and account provisioning are needed, the developer faces little or no issues at all.
A challenge arises when developers have a non-standard need. Where they must navigate various platform teams, create multiple tickets, and follow up on progress to achieve their goal.
This process can lead to frustration and hinder developer efficiency especially when you are sent from one supporting team to another. Overall, the Developers’ Experience suffers when you encounter these obstacles in your journey before diving into development.
For example, specific scenarios, like onboarding an application to a public cloud, lack a comprehensive step-by-step guide. This absence may seem unusual, and understandably so. The platform organization teams only contribute a portion to the overall developer journey, rather than overseeing the entire process from start to finish. Consequently, development teams often find themselves navigating through available options with limited processes to follow.
Let’s clarify the term Developer Journey or at least share our interpretation:
“The Developer Journey is the entire process a developer goes through to make and run their software within the organization”.
So, the Developer Journey is the entire process, while DX is how smooth and enjoyable that journey is. A good DX means the developer has the right tools and environment to be productive and happy, like a well-maintained road trip. By focusing on DX, companies can help developers build and run software faster and with less frustration.
Given above context, our problem statement is:
“How can we enhance the Developer Experience within the NS by improving the Developer Journey?”.
Lots of organizations in the IT space are already starting up programs to improve the developer experience (DX) you also hear the term Developer Journey mentioned a lot there. In the next part we elaborate about these terms and what their relation is because we think it’s not yet well known for everyone.
The Developer Experience and the Developer Journey
Let’s provide an analogy:
Imagine a developer’s journey as a road trip. DX is the quality of the road itself. A smooth, well-maintained road with clear signs and amenities (good DX) makes the trip (developer journey) enjoyable and efficient. Conversely, a bumpy, poorly lit road with confusing detours (bad DX) would be frustrating and hinder progress.
A positive DX can shorten the developer journey by streamlining tasks and reducing friction. Good documentation, clear process and good service all contribute to a smoother journey.
Conversely, a poor DX can lead to wasted time, frustration, and ultimately, delays in the development process.
In essence, DX is all about making the developer journey as positive and productive as possible. By focusing on DX, companies can empower their developers to build better software, faster.
Now that we explained these terms and how they relate to each other, you might be wondering what’s holding us back, well … to explain that let’s look at the context of our organization a little deeper.
The context of our (platform) organization
As with many enterprise organizations there is a lot of variances in development teams. But similarly with these large companies you need to standardize and set the framework for developing so you can profit of reuse of knowledge and resources. The NS is quite unique in the sense that development teams, in the past years, experience quite a lot of freedom with choosing tools they want to work with initially. While this freedom proves beneficial initially, challenges emerge during the transition of products to managed acceptance and production environments, which come with regulations and limitations on supported technologies and integrations.
Cloud native initiatives have been a viable option for teams that are eligible for running in the cloud but then they must run and maintain it themselves unless otherwise agreed. Given these circumstances, teams would greatly benefit from expert guidance right from the project’s inception (Project Start Architecture). Ideally, they should have the option to request a reliable and supported plug-and-play blueprint to streamline their processes and enhance efficiency. Such a blueprint could contain software standards like, for example secure software development. Unfortunately, such a blueprint does not exist yet for all applications, although there are some good initiatives that come a long way in this regard provided teams can find them amongst the web of team offerings.
Additionally, there are designated deployment landing zones, which may include traditional data centers, internal clouds, public clouds, or vendor-hosted platforms, depending on the specific needs of an application. These requirements may involve high availability, optimal performance, and enhanced security measures or a combination thereof. As the largest public transportation company in our country, we certainly must uphold a high standard, this reflects our software development and hosting standards as well.
We need to do better!
It is clear that we need to do better for our developers. But how do we do that? In general you would expect that having self-service and lots of automation in place would greatly help. We agree with this but that doesn’t just magically happen and our assignment is there to help drive this change forward.
Other consideration is how do we prevent us doing too much at the same time. In the orientation phase we formed our team and conducted initial developer interviews. These interviews helped us understand the problems that developers are facing and helped us gain focus. Additionally, we made a 3-plateau roadmap to plan our improvement activities (img. 3).
Developers have expressed various concerns regarding platform organization, such as:
- What services are available?
- How to initiate non-standard solutions?
- Solution flexibility to meet team requirements
- Are the solutions integrated?
Conversely, other challenges arise, including:
- Should a single solution be provided?
- Understanding team preferences
- Satisfaction with the services
- Avoiding redundant efforts
- Addressing shadow IT concerns
This is not the first time our organization has attempted to launch such an initiative. While the results have not been as significant as we had hoped, they are still discernible. We are aware that this is a significant undertaking and that we must avoid focusing excessively on the vision or implementing technology as a solution, without first considering how to handle the data and processes.
In our large organization, where teams must collaborate, technology is rarely the most pressing concern. Therefore, initiating the implementation of a tool is not a solution to the problem but rather a solution to an unknown issue. Consequently, we have decided to prioritize transparency, then build the service delivery, and finally implement full self-service.
Our approach can be summarized as follows:
- Lay out a framework to position tools (Capabilities)
- Survey the teams to collect tools being used per capability category
- Select recommended tools
- Provide a developer-oriented tool overview
As the first step, transparency, we wrote down our developer capabilities.
In the next segment, we will look at developer capabilities and how DORA helped us.
DevOps Research and Assessment
How we use DORA.dev providing foundation to build upon
We are using DORA.dev as a reference, because we are certainly not the first organization to do something like this and we do not want to reinvent the wheel, what seems to work and is already proven, use that.
The DORA.dev technical capabilities can be found on: https://dora.dev/devops-capabilities/
We decided to focus on the DORA Technical Capabilities for now because that’s the most tangible asset within the developer journey.
What we did was look at the categories defined by DORA and then map them to our tools. We quickly found that we needed an intermediate layer. We called it NS Developer Capabilities, and here is an example of what it looks like:
You can see that sometimes there is more than one tool to fulfill a defined Developer Capability, but that’s okay at this point because that’s the as-is situation.
Looking at the Tool column, you can see that there is overlap, which is logical in most cases. Sometimes tools are “best in class” or integrated into a suite (for example, Azure DevOps has multiple tools that can satisfy multiple functions).
We bring all of this data together and align it with the different stakeholders.
Combining the data with User Experience
As we worked to deliver this product, we combined all the data that we were collecting from the existing platform teams and made it available in a consolidated dashboard. Basically, we went through all the published items and put them into a single view. We then published that as a simple PowerApp.
For now, we use a PowerApp to get quick feedback about how developers would want to consume such information and if it fills the need for more transparency (what is the offering catalog).
We are working towards a more future-proof solution since PowerApp will reach its limits of what it can handle in the foreseeable future.
The result of step 1 — transparency
We started developing this story by constantly looking at the phases of the SDLC and them mapping tools under those phases. You see that we broadly mapped tools to development phases in the SDLC.
Since this was so recognizable for many developers, we decided to stick with it going forward. So, in our PowerApp we did the same.
Each tool is represented as a card in this pane. Card details are straightforward. The tool name and tool type (off-the-shelf, product, or solution) are displayed. The developer capability, the supporting team, and a brief description of the problem the tool solves. Finally, the action button that takes you to the appropriate home page for that tool.
What have we learned so far?
To learn if the product you’re making is actually solving the problem, you need to engage with users and get an idea if they’re happy with it. And that’s exactly what we’re doing together with our UX expertise colleagues.
Preliminary results show that what we did in step one, providing transparency, is very well received. The people we showed our tool overview don’t even question our efforts for a second and certainly feel helped by knowing “what’s available and supported in NS for development”. We feel that there are certainly things that can be improved in Plateau 2, where we will be looking at each service item to get it up to a decent level. As stated before, this is certainly a challenge with composite products where multiple platform teams need to work together. We’re very confident that we will continue to take steps towards a better developer experience.
In summary
Our key takeaways:
- Developer Experience (DX) is key: Making sure developers have a smooth process from start to finish boosts happiness and efficiency.
- Developers face obstacles: Clunky processes for special needs frustrate developers.
- Using DORA.dev as a guide: NS uses this framework to sort out what tools they have and how they fit into the developer journey (Tool overlap is okay for now).
- Rapid prototyping using low-code tools such as PowerApps works for fast feedback.
- Positive feedback from users: Devs like the transparency and find the dashboard helpful.
What’s next?
We are looking forward to implementing and seeing our Developer’s journey improved in many ways. Some other topics we will potentially cover in future:
- Process & Workflow management
- Knowledgemanagement (Documentation & Support)
- Automation and integration strategies
- Onboarding a new software engineer in one day
