Make Plans, Embrace Change

Software development is complex.

Every day, teams are working furiously to get their next big feature out the door. There are a lot of different people involved. From initial brainstorming to the full release, most ideas get passed through multiple hands. And each new pair of eyes introduces new insights that can lead to new directions.

We should celebrate the collaboration. Feedback is the cornerstone of Agile development. In fact, it's the second principle defined in the Agile Manifesto.

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

And yet it can be a hard pill to swallow. Late discoveries can feel like giant gaps that could have been avoided. Commitments may need to be tweaked, tickets have to be rearranged, code has to be changed, and test scenarios have to be updated. Without a strong culture in place, it can be hard to welcome change mid-flight.

So what can be done? In general, there are a couple of key frustrations I see with teams when it comes to requirements:

1. Ideas that seem obvious once mentioned don't end up in the list of original requirements.

2. Communicating the downstream impact on the developing team and their deadlines, as well as other teams and stakeholders, is difficult to do on a continuous basis.

Let's tackle each of these points.

Obvious ideas getting missed

"Shoot, we forgot about XYZ". It happens to every team. We first started this blog post with "Software development is complex". How often do we forget...

• ... the different states that need to be accounted for? Did we make mockups for the loading and error states? How does this page look on mobile devices? How does this design account for internationalization and languages that read right-to-left?
• ... the different people involved? Have we thought about how the QA team is going to test this feature? Are there other teams that already have a solution to the problem we're facing?

What can we do about this? What I've seen in some teams is that they simply assume they'll get better over time. They will hold retrospectives and say things like "We just need to remember this kind of stuff next time", with no real action items.

There is no obvious, silver bullet solution. But potential recommendations for teams looking to workshop their approach:

1. Involve "more" people early - Countless studies have shown the benefits of diversity when it comes to improving products. New eyes can see an idea from a different perspective. And giving individuals a chance to join the conversation earlier can help you find potentially hidden leaders, product owners, and technical experts in your organization.

2. Form processes, tools, and systems - Ensure certain aspects don't get forgotten by creating processes and systems that account for lessons learned the hard way. Create checklists for quality assurance, have tools that provide visibility and transparency to the plan, and create systems that ensure you stay on track.

There is no silver bullet solution. Some teams under-plan, some teams over-plan, and a subset of both of those teams end up winners. What will work for your organization will largely be based on a balance of your tolerance for risk and desire for speed. What is most important is that you be intentional about how you operate.

Difficulties communicating impact

As new discoveries arise, it becomes important to reflect on the impact of the discovery. Modern software development typically involves so many different teams and types of team members. Most changes in a pre-made plan will impact others in your network. So how do we get better at communicating these impacts? Here are some considerations:

1. Communicate and document in public - When things are shaking up, it can be tempting to reach out to your knowledge expert in Slack and ask them for a status update. It's easy for you at the moment and you immediately get the answer you need. But these types of interactions don't scale; soon, everyone is trying to reach the designated knowledge expert and they end up having to have the same conversation 1 on 1 with each person.

Rather than having these conversations in direct messages or in email groups, consider having the conversation in more public spaces such as Jira or a public Slack channel. This has several benefits. The knowledge expert no longer has to waste their time answering people one by one. The decision made is documented permanently, in a manner that can be traced back to the original context. And it allows you to "crowd-source" a solution, meaning you can get great solutions from teammates you might not have originally expected to contribute.

2. Be cognizant of the plan and events around you - A lot of software developers will focus hard on their task at hand, refusing to come out of their coding flow until their task is done. And of course, having the time and focus that comes from the uninterrupted flow is incredibly beneficial. But there are also benefits to taking a step back and understanding the ecosystem around you. Is another team deploying a hotfix tonight? Is a refactor on a different code base that might have lessons for your own code base? Rather than assuming people will know and tell you the potential impact to your team, sometimes it can be in your favor to know a little more about other people's work so that you can form some theories about the impact yourself and communicate your needs.

Conclusion

We've discussed various considerations to make with your team on how to catch things earlier while doing software development. These are things that I've come across in my experiences across teams, and the points outlined as well as others not discussed are the motivations for why I created Planner. I hope Planner can be another tool in your toolbox for mapping out future projects and help you find your roadmap.