Focusing all your attention just on your product never works in the long run. To have a sustainable business, you must take care of the team behind it.
This should be obvious when you think about it, but still, many companies choose to ignore their development teams and let them burn out. Which we can clearly see in organizations around us. We do not want to stand idly by and let the people and their product suffer. This is the main reason why we created a new approach through which we want to help them.
Our new approach is based on improving Developer Experience, so that’s why we’ve started DX Heroes.
Developer Experience (DX) can be shortly described as a User Experience (UX) but from the other side of the product. These users are developers who, through proper cooperation, suitable tools, a pleasant environment, but also a product they like to develop, determine the level of Developer Experience.
We improve Developer Experience, because only happy developers can create exceptional software.
The core of the problem
Anyone who works in IT for a while, or creates a product, knows very well that sooner or later, he or she will encounter a number of issues that need to be resolved with his team.
The product development process isn’t always grasped correctly, which can threaten the effort. We often see demotivated team members, high staff turnover, increased error rate, or even a significant increase in delivery time as the product moves into later stages of its lifecycle.
In DX Heroes we realize that it is not easy to set everything up correctly right from the start. Often the starting conditions do not even allow to have a healthy developer environment. Maybe the team operated under a too tight budget or with a strict deadline. This is sometimes necessary from the start but as your product grows, you cannot leave it like this. The common mistake is constantly overloading the team with unrealistic deadlines or high management expectations. On the other hand, the team may be underperforming because of inadequate tooling, bad architectural decisions, missing DevOps, or lack of basic team communication rules.
This can be a hard problem to tackle and it must be approached with respect and humbleness. That’s why we have chosen a multi-stage approach when helping development teams.
First Stage — Screening
In order to start fixing the team, we must first get to know what we are up against. During this phase, our DX Gurus are incorporated into the development team. They will work together with them to implement the product. This is the best way how to observe the team’s inner workings.
DX Gurus will focus on identifying problems the team is worried about. These are usually two groups of problems.
The first includes the hard ones, often associated with improperly chosen tools, or missing procedures that lead to poor quality of a product. For example, the team may be missing Continuous Integration, Pull Request execution or they have poorly configured testing environment that costs more than is able to save.
The second group is the “soft” problems associated with the fact that the members of product teams are humans. They have feelings, emotions, and expectations. Not handling this soft side properly may cause demotivation, poor communication, or even the missing sense of purpose.
This screening phase usually takes about three weeks to one month. We discovered that at least two sprints need to be “experienced” within an agile team to detect major issues.
Second Stage — Suggestion
In the second step, the DX Gurus prepares a summary of all identified issues. They suggest how to tackle them in the team and what would be a good way to introduce good DX practices into the team.
When designing the solution, the DX Gurus takes into account the criteria chosen by the team’s management before the validation begins. Examples of such criteria may be the need to reduce product error rates or speed up delivery. Typically, that criteria depend on the product and the needs of the team. They must be realistic in order for the change to succeed!
Third Stage — Validation
At this stage, DX Gurus will verify all proposed solutions with team management and, if necessary, the team itself. When validating, an emphasis is put on meeting the criteria, but also on the goal of creating a truly functioning and satisfied/happy team.
Extra attention must be placed on explaining the proposed solutions. Mostly, these are changes that may not always be accepted with enthusiasm. Therefore, any proposed change needs to be sufficiently justified in the context of the team’s work and needs.
We always tailor the solution to the specific product team and the organization in which they operate. There is little value in adopting general principles without adjusting them first.
Here is an example we often see how adopting best practices without thinking “goes wrong”: The notion of blindly introducing agile development into already existing teams without respecting their needs. The idea that the mere application of agile rituals and instruments, like a checklist, will miraculously start to work, is definitely wrong. Usually doing this will only annoy the team and brings very little value to them.
Fourth Stage — Injection
In the fourth stage, our DX Gurus will start introducing the practices within the team. The important thing is that the injections of practices are done while working with the team on their product. It is, therefore, possible to directly explain the applied rules and show their correct use and meaning. This allows DX Gurus to build consensus around the change they are introducing. Such an approach leads not only to implementation but to true adoption.
An important factor in the entire operation of DX Heroes is that once they complete their mission they should no longer be needed in the team.
After DX Gurus are done, the team should be familiar with all new/improved practices and be able to work on their own.
A Community That Helps
In DX Heroes, we want to give everyone the opportunity to share their experiences and also issues they face within the teams. That’s why we’re starting a community of enthusiasts that want to improve the Developer Experience in their organization.
The first thing we are launching is DX Knowledge Base, a place where we want to focus on all the practices that can help teams work and improve their Developers Experience.
All Knowledge Base articles are published as an Open Source for free, so everyone who wants to contribute, or specify some of the new aspects of DX is welcome and can join here.
What next?
We are only getting started. If you want to get more information or stay in touch with us, you can look at our site here:
And what can you expect from us next? We know very well how useful tools can improve the life of developers and the whole team. This is the reason why we’ve begun to prepare a special DX Scanner tool. This tooling allows you to “measure” Developer Experience directly based on your source code and will recommend practices to adopt that will help you to improve your product development.
Author
Prokop Simek
CEOWith more than 12 years in software engineering, I use my expertise to link business and technology for our clients.