Building Blocks of DevOps: Developer Journeys
You've heard of user journeys, but do you think about your developer journeys? Take a look at what you need to consider for your develop journeys.
Join the DZone community and get the full member experience.Join For Free
“Friction makes doing simple things difficult and difficult things impossible.” – Stephen Bungay
For all the right reasons, most mature Agile organizations put great emphasis on customer journeys, but what about your developer journeys? Do your developers have a smooth experience to deliver value?
How Long Does a New Developer in Your Team Need to Deliver Value?
In many enterprises, a new developer has to jump through many “hoops” before he/she can really start delivering value. Getting access to systems, getting the right authorizations and approvals, and setting up tools is not only time consuming but very frustrating. This is true, not just of new developers, but of IT teams in general that are slowed down by the very tedious and bureaucratic organizational process of requests, approvals and lengthy lead times. This not only impacts developer productivity but also has an adverse impact on innovation and experimentation culture in teams.
You may also enjoy: Following the Customer's Journey to Detect Bottlenecks
Example of A Bad Developer Journey
Imagine a team decides to use Azure DevOps (ADO) for their pipelines. Usually, the first hurdle for most teams is to request access to their ADO, get the right subscriptions to all team members which requires approvals, cost codes, and more. Once a team has access to ADO, now they need to have some agents, and I’ve seen many instances where requesting for self-hosted agents needs further approvals.
The next hurdle is to connect the ADO pipeline with other systems/services such as SonarCude, Artifactory, ServiceNow, and more. I’ve seen many instances where these activities take multiple weeks before a team even develop a simple “Hello World” pipeline. All the time/effort spent on these activities is waste and can be/should be avoided. That’s where a good developer's journey can help. A good developer journey should be a simple a self-service interface. Once a team requests ADO, all the underlying plumbing should be taken care of automatically, like an ADO account with all team members which is already integrated with other systems.
Why Developer Journeys Are Important
Mapping developer journeys are important because they can then focus on what they are good at – creating and delivering value. Having a smooth developer journey can also bring additional benefits to organizations:
- Ease of scaling — Improvements in developer experiences can easily be leveraged across the organization. This will help the onboarding of new tools/services easy by reduces friction.
- Efficiency — Development teams are more self-sufficient when they can easily consume services. This is more like ordering food at a fast-food restaurant. You don’t wait for someone to give you a menu, take an order and get it to you, and finally bring the bill. Instead, the menu is already available (service catalog), and you pick and order (self-service portal), which is way faster.
- Cost — Since most organizations are matrix organizations, a service request has to go through multiple silos before it can be fulfilled. This is not only time consuming but also results in the cost of delays.
- Innovation — With less setup/onboard time, teams are encouraged to more experimentations.
- Easier knowledge exchange — Improvements in developer experiences can easily be leveraged across organizations.
Where Should You Start?
Listen, measure, observe. Like the saying goes, "If you keep looking at a broken mirror, you will stop noticing the crack after some time." The same is true with bad developer journeys. Teams will get used to inefficient processes and start either accepting the status quo or develop a workaround (which at times can be counterproductive).
Create a service catalog. Identify a list of services your IT4IT or Central CIO offers to the rest of the organization. In most enterprises, these core IT teams work in silos and can't easily identify their services. For example, consider that there is a central database team, a network team, an OS team, and an IAM team. If a team puts in a request for a database server, the OS team needs to provide a new server, the IAM team will create appropriate users, the network team will add the server to the right network, and the DB team will install and configure the database. Once all of this is done, this DB server is given to the team which has requested.
Each of these teams has a view of what service they provide. However, the end consumer (the team requested for a DB server) should not care about how many teams are involved in this. So, a service in the catalog should be a new DB server and not necessarily individual steps to fulfill this service.
- Create an IT value stream for services: Identify a service owner and plot an IT value stream map for this service. Focus on improving the value stream by either reducing/avoiding silos, changing process and automation.
- Automate: Needless to say, one-click provisioning, self-service requires a high level of automation. This not only reduces the complexity of handover but also minimizes the error rate.
So, do you currently measure your developer experience? Do you measure how it is impacting speed, innovation, and the quality of the value you deliver? I’m curious to hear how you plan to improve your developer journeys.
7 Traits That Make a Great Software Developer
DevOps vs. Siloed Cultures
Published at DZone with permission of Phani Bhushan. See the original article here.
Opinions expressed by DZone contributors are their own.