Overview

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.

Proccess Pains & Resignation

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.

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.

True Cost of Requirements

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.

How Teams Are Effected

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.

How to Implement Change

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.

Starting Options

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.

Option A: Six-Week Experiment

1. Shape one project that can be comfortably finished within six weeks.
2. Carve out one designer and two programmers’ time for the entire six weeks. Guarantee that nobody will interrupt them for the length of the experiment.
3. Plan for the team to do the work you shaped for this one experiment.
4. Kick-off by presenting shaped work to the team. Set the expectation that they will discover and track their tasks.
5. Dedicate a physical space or a chat room to the cross-functional team so they can work closely together.
6. Encourage them to get one piece done by wiring UI and code together early in the project.

Option B: Start with Shaping

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.

Option C: Start with Cycles

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.