2022 | Research Artifacts
Summary: This document outlines a series of suggestions on how to improve the product development processes at […] and increase harmony between departments.
After an acquisition and introducing new software development processes, it became increasingly clear that there were issues at […]. To help identify and resolve these pain points, I was tasked with investigating and auditing the processes teams were using.
Eventually, process problems wear down employees, reducing their morale, and in many cases, driving them to resign. The turnover rate at this company’s tech roles is especially high, and resignation is not exclusive to new hires. Even tenured employees exit because of these problems.
In the last sixteen months, these are some of the roles that have resigned from […] product team.
-1 Director of Development
-1 Quality Assurance Lead
-2 Senior Engineers
-2 Product Managers
-2 Scrum Master
Some of the frustrations employees experience are even made public. Past employees have posted their feedback on Glassdoor, which could potentially deter talent from entering teams. If enough negative feedback on the technology teams makes it online, […] could develop a reputation as a place for top talent to avoid.
Unclear and changing requirements take up time—each phase in the development journey requires an increasing amount of resources to resolve.
The cost of change chart represents the challenges teams are currently facing. Constantly, development teams are being asked to work from unclear requirements. This results in delayed feature releases, shipping incorrect solutions, limited sprint output, wasted time spent on re-working, and even contributes to the high turnover rate for tech positions at […].
If […] were to take action and resolve the issues with requirements, the rewards would be exponential—product teams would be able to deliver higher quality work faster that drives customer satisfaction.
Working under these conditions is not only inefficient, but it’s also frustrating for team members. When surveyed, employees report that their assignments are unclear and lack details.
When work is assigned to me, product requirements specs are clear, detailed, and informative
After work has been assigned and started, requirements remain accurate
I feel happy with the current product development process for my team
Current and upcoming priorities are clear and easy to predict
I feel confident in the performance of my team and their reliability
There needs to be more design, collaboration, and discussion when a business presents a request. Additionally, we need time to revisit our tech debt and developer experience. I feel like things are heading in the right direction and improving but […] has never had a process in place for our lifecycle that leads to quality solutions.
Have clear requirements that have been thoroughly reviewed and approved by all stakeholders (executive, biz, UI/UX, product) before they are delivered to the scrum team. Switch to Kanban or another simplified process until we get a predictable, working process. Eliminate the product roadmap until product proves they can do their job.
We need to be sure that stories are fully detailed with specific and clear requirements before they get to the development team. The dev team is not responsible for the "design and implementation" of features and enhancements. They need clear direction outlined in the stories so there is no question that we are delivering what the business needs, not what we think they would want.
The numbers wouldn't change drastically if I were less frustrated. We have legitimate issues that are and will continue to plague the development team.
Building a dedicated product design team
I'm frustrated but still enjoy the challenges of the job, and believe I can make a difference and help turn things around.
Committing time and people is usually difficult within large organizations—at […] it’s nearly impossible. Getting product leadership, C-level executives, and stakeholders all together at once turns into a wild game of calendar Tetris.
Working in cycles drastically simplifies this problem. A cycle gives teams a standard project size both for shaping and scheduling.
Overriding the current processes and changing everything teams currently do is an enormous amount of unnecessary risk. Instead, this should be a process tested, validated, and operated separately with a small team.
Sometimes, getting teams together for six weeks is impossible. Instead, try shaping a project with clearer boundaries than past projects. Present the project and put it through your company’s existing software development cycle.
Better-shaped work can shine a light on the engineering team and help them open up to things like longer cycles or a more deliberate betting process.
Another approach is to start by working in six-week cycles. For teams familiar with two-week sprints, this removes the workload of constant planning meetings and gives programmers more time to code.
Once the team has more bandwidth, it’ll be natural to think about how to shape the work to take advantage of this new capacity.
©2023 Tyler Renfro