Let’s look at these one by one and consider mitigation strategies

The technical solution is to make sure your branching and testing strategy supports hotfix branches. See one example. But the bigger problem is the cost to implement the hotfix especially if the product owner is prone to request many of them. First, it disrupts the development team to branch, fix, and deploy the hotfix. Second, it requires at least two rounds of testing; one when the hotfix is deployed and a second it is merged into the main development branch. Here’s what I suggest

• Make sure the product owner understands the tradeoff by reducing the commit in the current sprint to support the hotfix.
• Illustrate and build awareness around the added testing costs
• Measure and benchmark the behavior (# hotfixes / time-period), communicate the impact to the roadmap, and single out product owners that have higher hotfix requests.

Users are complaining. We need an improvement fast

This is more likely to happen with internal applications deployed rapidly and where users may have different workflow needs. It may also happen if release cycles are too long and users prefer seeing more incremental changes. Suggestions

• Make sure to capture and reflect if the needs of a specific user group were missed.
• If this happens infrequently, consider scheduling minor releases before going onto your next major release. See more specifics on major/minor releases.
• If this happens frequently, consider shortening your release cycle.

There’s a new marketing event and the app needs

This is more specific to products or customer facing applications. Ideally, marketing events should be considered when developing the overall product and release roadmap. That being said, it’s fairly common for an agile marketing team to find new opportunities requiring changes to the release schedule and feature prioritization. Suggestions:

• Make sure the marketing team is engaged when developing roadmaps and release schedules.
• Develop a communication/collaboration process so that you are informed as early as possible when a new marketing opportunity may impact the roadmap.
• Make it easy for product owners to update priorities in the agile backlog.
• Develop a branching strategy that can accommodate these opportunities.

We need a big feature release

This shouldn’t really be an ad hoc business decision and this business strategy needs to be reflected in the product roadmap and the release strategy. If it comes out of nowhere, it probably means that there is a shift in business strategy, or this may be a onetime event. Suggestions:

• Make sure the team understands whether this a shift in business strategy that should require a review of the roadmap and the release strategy, or if this is a onetime event.
• Consider having shorter and incremental “alpha” releases for internal users and longer “go-to-market” releases that are customer facing.

Can we make a big workflow change easier for users

This suggests that you have the capability to roll out incremental improvements to a subset of the user community, or, have the ability to do A/B tests when rolling out new capabilities. Suggestions:

• If you need to roll out changes to different customers or user communities incrementally, then this capabilities has to be developed within the application. Add it to the backlog and develop a rollout strategy based on the application’s authentication groups and roles.
• There are many third party tools to support A/B testing or you could build the capability in house. If A/B testing is needed, just make sure it’s developed as a horizontal capability so that it can be leveraged across multiple applications.

If you send me any other anti-patterns, I’ll look to update in a future post.