Dumb ways to die in product development
No quarters needed
See if you can survive the game of product development and the typical chaos that comes with it.Play
We’ve led hundreds of software projects for clients across the globe. They vary in size and industry, but all have something in common.
An unhealthy obsession with Agile.
In the product-building world, organizations tend to problem-solve with strict processes and tools and more meetings. These efforts can quickly lead to the point where the original principles of Agile are lost in a muddled mess of roles, acronyms, and Jira tickets. At its most extreme, you have Scaled Agile Framework for Enterprise (SAFe), which is the ultimate in Agile process and rarely works.
Agile has lost its way. Let’s throw it away and find our way back to a sensible place.
We don’t believe there is a best practice when it comes to building software. Instead, we believe there are unique organizations, with unique humans, building unique products who need their own approach to building software.
Consider this: Back in the early 1990s when Scrum was introduced to software development, it may have worked, but mostly for small teams developing one product.
Jump forward to 2023. Large organizations are supporting multiple products with a combination of ongoing maintenance and new feature work. Do you expect that same process to work without adjustments?
Software development processes aren’t one size fits all. While the principles of Agile, Scrum, and Kanban are solid and you can learn a lot from them, you don’t have to be dogmatic about them.
We believe there is a better, more pragmatic alternative: Working with agility, but not being confined to Agile. Being flexible in your delivery process will lead to less stress and more cooperation between your teams. We’ve done this successfully, so you can too. Here’s how.
A while back, we worked with an engineering team who engaged us to do some software development for them, as well as provide project management help.
When we started working with this team, it consisted of about 25 software developers, two product managers, one product analyst, a director of product, and a vice president of engineering.
Before we arrived, the team had grown organically from a nimble, close-knit team to a large team that was drowning in meetings and not turning around work quickly.
Their processes weren’t working.
Since product development teams’ ultimate goal is to reliably deliver product updates, developer productivity is key. At the time we entered this relationship, developers were in hours of meetings per week and struggling to get work done. Most of the meetings were about organizing work or shaping functional stories. We wanted a way to take from Agile principles and create just enough processes to avoid chaos and keep the engineers happy.
Because the team was in an initial build phase, it made sense to borrow many principles from Scrum but adjust them based on how the team worked.
The goal wasn’t to dictate how things were done, but rather act as an impartial instigator for asking hard questions and creating momentum for change.
Over the course of a few weeks, we met with client team members at every level, from product managers to developer leads to developers. We asked questions about what issues they encounter daily, where they believe the current process fails, and how they would feel about changes.
Our general approach to change in process is:
Look familiar? It’s an agile approach to Agile.
Some of these will seem like common sense, and in many cases they are. But sometimes teams get stuck in their ways.
Here are the things we helped them tackle to create a sustainable product development process. Coincidentally, these are things we see across many, many product teams.
First off, any 25-person team is too large to manage. We worked with leaders of the organization to split up the team into multiple squads that made sense.
This foundational change makes it easier to manage further change by letting individual team leads be proponents of changes within their small groups. It also gives small groups of people autonomy to have mini processes-within-the-process that work for them. They can implement processes for their squad and not have to incur the overhead of syncing with 20+ people to enact change.
[insert Capitan Obvious meme here]
You’ve been there. That thirty-minute meeting that’s still going at 90 minutes, the whole team looping around the same topic never making any decisions or progress. Meetings without agendas are common, and they often go outside the intended scope. Conversations go in an irrelevant direction or include stakeholders who aren’t needed.
Hone your meetings closely. Note that we didn’t say ceremonies: We believed that these meetings should be custom to your team and not be a “standard” Scrum meeting.
Start simply: Write down the purpose of meetings. Meeting organizers should publicize meeting agendas so the audience and goals of each meeting are crystal clear. This gives people a chance to skip out on meetings when they are not needed.
Many teams have meetings that include all team members. The standard backlog grooming, planning, and other sessions include upwards of 20 people. But typically, only a few are active in discussions. The remainder sits passively wondering if they are needed, likely getting frustrated that they can’t focus on their work.
By splitting the team up into separate squads and having separate ceremonies, meetings become shorter, more focused, and more engaging. Yes, it means more work for product owners, because they need to attend more meetings. However, the cost of the product owners splitting up work amongst teams and attending more meetings ends up being worth the benefit of getting teams to streamline work and be in short, focused meetings.
When you implement focused meetings, you will see that all team members engage in conversation because they can contribute to a focused discussion. We find that this approach of as-needed, well-targeted meetings offers the flexibility to be agile and adjust to the needs of each sprint.
When incomplete user stories are given to developers, it causes churn. Developers start stories, only to have them be told to stop once they get midway through because of incorrect prioritization.
We often use the phrase “shovel ready” to describe work that an engineer can pick up and complete independently. This should include clear acceptance criteria (or whatever your team might call it) to outline what constitutes the work being “done.”
Stories should not leave a grooming session without being fully fleshed out, and not sized until everyone in the session understands what work is associated with it. Priorities of tickets are set further in advance during the Sprint Planning sessions, so developers are never working on anything that isn’t necessary, and thus nothing is being pulled out of their queues.
Though a single workboard is great for small teams, it can become untenable and lead to planning overhead when teams grow large.
The transition to multiple squads and the nature of your work make it necessary to have different, focused boards. This makes it easier to get a sense of what was happening across individual teams while ensuring everyone can access other team boards for cross-team user stories.
In our experience, product managers love individual boards. It makes it easier for them to see and plan their work.
We often see processes like this:
The development team works in a Kanban-style process, with no boundaries, picking up the next ticket as they go along. Developers are not held accountable to any sort of completion date and can work on stories for as long as they felt fit.
This creates issues around velocity, where some weeks zero points are completed. Developers aren’t necessarily shirking duties, but they have no sense of urgency around stories that are high value.
Nothing against Kanban-style processes, but you need to be disciplined about limiting work in progress. It’s not the silver bullet that some might make it out to be, but implementing sprints grounded in Scrum principles can help teams focus in the right circumstances.
Using these Scrum processes holds the whole team accountable for completing user stories based on estimates agreed upon at pre-sprint meetings. Of course, taken to the extreme, you end up in process hell, which will only frustrate engineers and designers. Strike a balance between setting commitments and being flexible when unknown things came up.
These meetings should be led by your team’s Product Manager, a ScrumMaster, and a developer lead. In the meeting, review the team’s velocity for the most recent sprint and the average from previous sprints. Use this alongside knowledge of the team’s priorities, to put together what needed for the upcoming Sprint.
The magic here is not the process, but getting the team to stick to the process.
Generally speaking, give developers autonomy to choose their own stories.
Sometimes on new teams, developers don’t know which story to pick. In these instances, guidance from lead developers will make things effective. Based on their knowledge of the user story, timing, and a developer’s ability, create a process where the lead developer assigns the next story. Depending on the priority and timing of a sprint, developer leads should offer ‘stretch assignments’ to developers to expand their skill sets.
When you implement this simple change, teams are more productive and developers feel more accomplished.
Team retrospectives often don’t provide as much value as they should. A huge reason is that nobody feels comfortable talking in a large group.
Sharpen the focus of each team’s individual retrospective by focusing on the typical questions of what went well, what didn’t, and what could be improved. Be careful to coach and not cast blame in these meetings.
A common roadblock is that some team members are more likely to share what’s bothering them than others. This leads to consistent conversations and the false impression that things are going well or that everyone is satisfied. Reinforce that feedback can be provided directly and anonymously.
This can result in some strong individual discussions, but quite frankly, it is not enough.
Hopefully, this illustrates how listening to your engineering teams and taking common sense approaches to processes can go a long way. Throwing Agile dogma at simple problems will only make things stressful and more complicated.
At the end of the day, do right by your teams: Listen to them and make things as easy as possible.
Once you do that, everything else will fall into place.
See if you can survive the game of product development and the typical chaos that comes with it.Play