“Friction makes doing simple things difficult and difficult things impossible” – Stephen Bungay
For all right reasons, most mature agile organization give high emphasis on customer journeys but what about your developer journeys. Do your developers (which includes, programmers, testers, ops etc) 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 hop many “hoops” before he/she can really start delivering value. Getting access to systems, getting right authorizations, approvals, setting up tools etc is not only time consuming but very frustrating. This is not just of new developers but IT teams in general are slowed down by 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.
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 right subscriptions to all team members which requires approvals, cost codes etc. Once a team has access to ADO, now they need to have some agents. I’ve seen many instances where requesting for self-hosted agents needs further approvals for new infra, open network ports etc. Next hurdle is to connect ADO pipeline with other systems/services such as SonarCude, Artifactory, ServiceNow etc. I’ve seen many instances where these activities make 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 Journey’s” can help. A good developer journey should have been a simple a self-service. Once a team requests for ADO and all the underlying plumbing is taken care i.e. an ADO account with all team members which is already integrated with other systems (such as artifactory, Sonar etc)
Why developer journeys are important
Because they can focus on what they are good at – Creating and Delivering value. Having smooth developer journey can also bring additional benefits to organizations
- Ease of scaling – Improvements on developer experiences can easily be leveraged across 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 joint. You don’t wait for someone to give you a menu, take an order and get it to you and finally settle the bill. Instead, the menu is already available (service catalog), you pick and order (self-service portal) which is way faster.
- Cost – Most organization being 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. Same is true with bad developer journeys. Teams will get used to inefficient processes and start either accepting the status quo or have a workaround (which at times can be counterproductive, remember having a server under your desk).
- Create a service catalog: Identify a list of services your IT4IT or Central CIO (or whatever unit in your organization) offers to rest of the organization. In most enterprises, these core IT teams work in silos and hence they cant easily identify their services. For e.g. there be a central DB team, Network team, OS team, IAM team. If a team requests for a database server, OS team need to provide a new server, IAM team will create appropriate users, Network team will add the server to right network, 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, end consumer (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 high level of automation. This not only reduces 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 quality of value you deliver? I’m curious to hear how you plan to improve your developer journeys.