Introduction
In many IT organizations, there is clearly a need to guide people as to what is expected from them. This article outlines a few areas for dev leads to focus on to help keep the technical delivery of their projects on track, and insulate their teams from some of the hurdles and unknowns that come with just about every software project.
1. Help Shape the Backlog
The product backlog is a list of work (epics, features, user stories) for the development team to address, that is derived from the product roadmap and business requirements. The backlog should always be ordered by priority with the most important items at the top, so the dev team knows what they need to implement first. Dev leads need to communicate regularly with the product manager or business analyst in backlog grooming sessions, so they can help prioritize and shape the stories in a way that makes sense from a technical perspective.
Break down (or group together) user stories
When reviewing user stories, dev leads should consider whether or not any of the acceptance criteria can be broken out into smaller, self-standing work items.
Example 1
The backlog has a user story to build a user profile page, which has the following acceptance criteria:
It may make more sense for that single user story to be broken out into two separate user stories and captured underneath a “User Profile” feature.
Now consider the opposite scenario; does it make sense to combine multiple user stories into one? Usually, if multiple stories can simultaneously be addressed with the same code change, they are probably good candidates for being combined into a single user story.
Example 2
The backlog has the following two user stories:
For this example, there only stories for two roles, but what if we had twelve different roles? We might then have twelve three-point stories to capture those requirements. That’s 36 points added to our backlog to implement a role-based navigation model, which is too high. Dev leads should catch issues like this before any of the stories make their way into a sprint, and propose restructuring them into a single story:
The point estimation for the combined story is higher to account for the increased complexity of a scalable solution, however it is still much lower than the original 36 points.
Recommend changes in priority
While the product manager is ultimately responsible for maintaining and prioritizing the backlog, it’s not an activity that’s meant to be done in isolation. Effective product managers should ask for input from customers, designers, and the development team to optimize delivery. If the dev lead isn’t being asked for input, he or she needs to raise it as an issue. Three areas that should always justify priority from a dev lead’s perspective are technical dependencies, proof of concepts, and developer experience improvements.
Technical Dependencies
Does the team need functionality X in order to build functionality Y? Continuing with the example above, the backlog has a story that asks for admins to edit a user’s profile information; the solution should already support determining whether a logged-in user is an admin. If this functionality doesn’t exist yet, this should be called out as a gap. The product manager may either decide to go ahead with the story to edit profile information and remove the acceptance criteria for role-based restriction, or prioritize a story to determine a logged-in user’s role.
Proof of Concepts
Is the dev team implementing a major new feature that will rely heavily on a new third party library or interface with niche hardware? Dev leads should call out the need for a “Proof of Concept” story prior to the development of the actual feature, to mitigate risk sooner rather than later.
Example:
The backlog might have a feature to implement a printable PDF template for work orders with a consistent layout. This falls outside of the typical functionality covered in the stories that the team has been working on. There are dozens of ways to do accomplish this. Should it be done client-side or server-side? What library should be used?
The “Proof of Concept” story should solidify an approach prior to any other stories that will rely on that approach, potentially saving your team wasted effort and additional rework later on.
Developer Experience Improvements
Stories that can contribute to Developer Experience (DX) improve the workflow for developers, removing obstacles and headaches so they can deliver quality work faster. These items should always be highly prioritized, because they will positively impact the quality or completion time of subsequent user stories.
Push back when stories aren’t ready for sprints
Dev leads are the first line of defense against stories that are not ready for development. The more time they put into grooming stories ahead of time, the less painful downstream activities are for their development teams.
Is a user story lacking the appropriate level of detail in acceptance criteria?
Dev leads should discuss it with the business analyst or product owner.
Does a story have a lot of UI additions that need supporting mockups?
Dev leads should reach out to the UX designer (or business analyst if the team lacks a dedicated designer).
There is no “one-size-fits-all” formula for preparing user stories for development teams. Dev leads should be lenient (to an extent) with what stories come through, instead of pushing back if stories don’t adhere to a specific standard that the team follows. Does the story need pixel-perfect mockups every time, or will a lo-fidelity sketch work? If it’s a straightforward story, does the business analyst really need to fill out a bunch of digital paperwork in order for the team to implement it?
Dev leads should strike a balance between “too much” and “not enough,” and encourage their teams to make assumptions for some of the more common implementation patterns (e.g. form validation, confirmation actions, etc.).
2. Understand Developer Needs
In order to best support their teams, dev leads need to understand their team’s strengths and weaknesses, learn what motivates them, and give them opportunities to stretch themselves. Consciously distributing work, advocating the value of DX, and empowering the team to make decisions are a few ways in which dev leads can work towards building a skilled, highly autonomous team.
Consciously distribute work across the team
Dev leads need to ultimately make the best choices for the health of the project when assigning work to developers. One of my favorite approaches to work assignment is “fanning out” work that involves creating net-new architectural patterns that will be used throughout the solution. I typically assign these to senior developers and spend quite a bit of time reviewing the solution design, complexity, and maintainability with the entire development team. Once everyone is comfortable with the solution for the initial story, other stories that leverage these patterns can be implemented with confidence by anyone on the development team.
Dev leads should consider their team members’ strengths and growth areas when distributing work. While it can be easy to align stories with developer’s capabilities, leads may unintentionally pigeonhole their developers if they aren’t careful. It is important everyone on the team to have a full understanding of the solution.
If your team members get to a point where you are comfortable with their delivery, estimation, and planning, you can always let them take ownership of how they distribute stories between each other.
Champion the value of Developer Experience
Developer Experience (DX) is an area that can increase development team’s velocity and makes their daily activities easier at the same time. DX is generally referred to from the perspective of a product that is marketed to developers (e.g. open source library, SDK, API, etc.), but you can also view it from an internal perspective. Dev leads can easily remember three foundational areas to help improve DX and keep their team happy and confident with the products and tools they are working with:
- Projects should have accessible documentation, so developers who use them know to consume their services (e.g. Swagger, Compodoc)
- Projects should have consistent and reliable Continuous Integration and Continuous Delivery (CI/CD) pipelines, so the services that developers regularly rely on don’t break
- Project README files should have everything that developers need in order to begin contributing to the code
It is important for the dev lead to work closely with the product manager and business owners to articulate the value of improving DX, so that stories can be added to the backlog and implemented as early as possible.
Empower the development team to make the right decisions
Even the best dev leads make mistakes and their teams are usually the first line of defense to help catch them. They should listen to their team’s concerns and feedback. Retrospectives should be held every sprint so the team can learn from their collective mistakes and implement positive changes in the next sprint. Leads should make sure that the issues raised in retrospectives are addressed to the best of the team’s abilities.
Did stories make it into sprint planning that the dev team thinks were not ready for development?
The team should be encouraged to block stories from entering sprints if they aren’t ready.
Does someone have a new productivity tool that they think the team could benefit from?
The them should be encouraged to try it out (assuming it’s allowed).
There is nothing more frustrating for a development team than a draconian set of self-imposed rules and processes. Sometimes even the best ideas can’t be implemented due to factors outside of the team’s control, like industry regulations or company policies. For areas that the team can influence and control, dev leads should foster a team culture that is receptive to feedback and new ideas.
3. Maintain Code Quality
Code complexity and quality are two major factors in software delivery projects that are often overlooked by the business. The dev lead is ultimately responsible for code quality and should make sure that his or her team adheres to certain quality standards. Dev leads should ask themselves the following types of questions to help identify areas that their teams needs to focus on:
Determine the right approach
There are a number of different factors that can adversely affect delivery, and it is up to the dev lead to implement the right changes based on the issues they are seeing. If junior devs need more guidance, time can be allocated to pair programming with senior devs. If certain quality improvements can be automated, dev leads might decide to implement tooling into their builds (I’ve found that tools like Prettier and Husky incorporate nicely into my team’s CI pipelines).
Know how much technical debt the team can afford
The “health” of a software product (e.g. code coverage, outstanding bugs, etc.) should always be visible to the development team and the wider product team, so the team can help identify areas of technical debt. If technical debt is beginning to noticeably impact the team’s throughput or bleed into other parts of the application, dev leads should raise it as an issue and address it immediately. If dev leads stay on top of tech debt regularly, it won’t get out of hand. If they let it slide, they shouldn’t be surprised if they eventually find themselves with a mountain of technical debt, a “works on my machine” solution, and a disheartened dev team.
Conclusion
At the end of the day, dev leads should show the developers on their team smarter ways of doing things and help them improve their skills so that everyone becomes better at their jobs. They should follow the principles and practices their teams are committed to, advocate learning, and take the time to do so themselves.
They should push for their team to grow as developers and stop “coding to acceptance criteria.” Every developer is capable of looking for opportunities to provide recommendations to the business that still meet requirements and are simpler to implement or more elegant than the original concept; they just need the right coaching from their dev lead.
Thanks for reading!
