It’s important to understand the best practices and pitfalls of agile to ensure your team can deliver the best results as efficiently as possible.
As a kid, I remember loving to play a version of Snakes and Ladders. We cried tears as snakes ruined our progress and shouted cheers when we climbed a ladder past our competitors. As I look at my own agile journey across many different projects and companies, it always feels like an intense round of this classic board game.
Unfortunately, in the real-life agile version, it’s a lot harder to spot sinister snakes and choose to climb helpful ladders. In this article, I describe the details of what processes are hidden snakes and which processes are helpful ladders so that your agile journey consists of cheers of progress instead of tears of failure.
Ladders: The Important Elements of Agile
Let’s start by defining what I mean by “ladders.” Ladders are practices that help move teams forward in their agile journeys. These practices span both process and technical choices, and it is important to make progress and continuously improve in both areas.
Now, let’s look at some of the more prominent “ladders” in agile.
Full-Stack Devs/Teams in Agile
Agile teams are most effective when the team has the ability and scope to solve business problems. Some agile teams break up their developers and individual contributors into strict role-based silos. The most effective agile teams allow their developers and architects to make full-stack changes. This flexibility allows the team to manage issues at the appropriate position in the architecture without blaming people responsible for other parts of the application stack.
Build and Deploy on Commit
Modern development tools are available for both cloud and local development. Using these tools to build on commit and deploy to a development environment automatically enhances your team’s ability to deliver. Building immediately exposes build-time failures while deploying applications to a development environment allows both manual testing and automated integration testing to find application issues without developer or operations teams having to manage scheduled deployments.
Automated Integration Tests
By expanding on the automatic deployment capabilities, teams can leverage automated integration tests executed immediately after a Development deployment. In a full continuous integration and continuous delivery (CI/CD) environment, teams can use these tests to mark a build as success or fail and to either block a build from moving to the next environment or automatically push a build to a higher environment (Test, QA and more). Your teams can build automated tests at a UI and API level to ensure a baseline functionality for all builds.
Frequent Production Deploys (Before MVP)
Minimum Viable Product (MVP) is an excellent tool for describing the vision of an application to both the team and external users and stakeholders. As teams mature in their agile capabilities, they realize that MVP is a tool for the vision they shouldn’t tie to delivery capabilities. Teams that begin delivery of the application early in the development process, even before reaching MVP, begin testing their CI/CD pipelines and offer “sneak-peek” and real-world testing of the application with a small set of users.
The frequent deployments help teams realize that delivery of working software is more important than waiting for a perfect MVP. This allows the teams to become comfortable with delivery of software, getting user feedback and integrating that feedback directly into the agile delivery lifecycle.
Feature Toggles in Agile
Feature toggles are the missing connection between teams that succeed in CI/CD and teams that continuously struggle with releasing software. As your teams move towards frequent production deploys, they might quickly become overwhelmed with managing the commits around features (new and changed) that are not ready for full-time usage. Teams turn towards a variety of anti-patterns in a failed attempt to manage feature rollout.
Feature toggles offer a simple and extremely powerful tool to manage new features without exposing users to incomplete functionality. A Feature toggle is a method for enabling or disabling features both large and small. A toggle can enable and show a single button, or you can use it to control a set of UI screens for a new business process. You can also use a feature toggle to provide A/B testing or Branch by Abstraction implementations.
The feature toggle looks for a user’s key attributes to decide whether the user can interact with the feature. You can accomplish the simplest implementation by adding each feature to the security model for a user. If the user has access, then the feature toggle is “On,” and the user can interact with the new feature. If the user does not have access, then the feature toggle is “Off,” and the feature is not displayed.
Since the toggles are generally database-driven, you can even use them to temporarily enable a feature for a small subset of users in production for usability testing. This allows actual users to provide feedback with real data and test the process flow in production. Once a feature is complete the feature toggle should be removed as part of normal refactoring.
Granular Prioritized Stories
Most teams are successful at breaking an application into epics. However, teams struggle with breaking epics into appropriately sized stories. Teams limit the breakdown of stories based on two “truths.” First, teams calculate the minimum MVP at a feature level and then stop splitting stories because they don’t understand the value in delivering if the MVP is not reached. Second, teams that have limited production deployments experience no value from stories that are significantly smaller than sprint boundaries.
Teams that understand these baselines are myths they can easily overcome (by applying the other “ladder” ideas) can further breakdown stories into one- or two-day efforts. Once teams split the stories into one- or two-day efforts, teams can make micro-adjustments to individual features and immediately change story priority as they find new issues and opportunities in production. The ability to prioritize granular stories frees the team from having to plan sprints and releases perfectly.
Architecture Appropriate for the Problem
Teams take great pride in building applications that fulfill the end-user and business goals. As part of designing the system, the design and architecture teams look to other successful applications when choosing the application architecture. Standardizing on well-known architectures keeps teams from having to repeat architecture and design mistakes. At this stage, you need to step back and make sure the architecture you’re using as inspiration solves a similarly scaled problem.
For example, a team that is building a global web-based shopping application needs an architecture that auto-scales to handle the spike in load during Cyber Monday. If this template architecture is used for an internal application used by five users the effort to build the complex architecture can result in overspending, overcomplication, and delays — without providing business value. You can apply the misapplication of architecture in reverse when the team responsible for an external user-facing application uses an architecture designed for an internal low-security, non-scaling application.
Now that we’ve looked at some of the better agile practices, let’s address the “snakes” that can ruin your projects.
Snakes: Agile Hang-ups
I define snakes as process and technology choices that prevent teams from becoming a smoothly functioning agile team. In practice, snakes take root in response to attempts to solve agile issues. Snakes masquerade as long-term solutions to agile issues when a Ladder is available to solve the issue productively.
As the number of snakes increases, team productivity begins to slow, which can, in turn, cause your team to adopt additional snakes as they attempt to regain team productivity, resulting in a vicious cycle. The loss of productivity increases as the application becomes complex because the addition of features increases the management overhead of planning and deploying the application.
Here are a few “snakes” to avoid.
Prolonged Arguing About Estimates
Numerous agile methodologies recommend estimating stories to allow teams to determine velocity, set delivery expectations, provide a constructive method for discussing story definitions, and determine relative sizing between features. However, story estimation is not a requirement for all agile methodologies (ex. Kanban), so a team estimating should continuously evaluate the effort required to estimate the stories versus the gain.
For example, instead of prolonged estimating meetings, your team could strive to prioritize stories granularly. This allows the team to shift from difficult and unwinnable arguments of “three vs. five” (Fibonacci) or “Large vs. XL” (T-Shirt sizing) to simply breaking a story into smaller parts. Teams that practice breaking down stories quickly learn how to create “just-right” stories and remove the overhead of full-team discussion about trivial “build-on” stories that don’t require new design decisions.
For truly unique stories, your teams can have ad-hoc discussions about design decisions. Teams discussing design and style details on an ad-hoc basis have incredible time-saving gains as the application matures because they are no longer forced into weekly or bi-weekly planning sessions. As your teams mature, there is no benefit in determining if a specific story is a “three” or “five” when the story is simply adding a new feature that follows the standard design and implementation. A good indicator your teams are experiencing this snake is when the estimation meetings have dissolved into a small subset of members participating in an effort to limiti the waste of full-team estimation meetings.
Due Dates for Epics
One of the hardest shifts for teams beginning their agile journey is finding a way to show progress while still providing a strategic plan for rolling out new application versions and features. Teams story point hundreds of stories across the full set of epics and features. Then they attempt to use this velocity to determine the dates for delivery (to end-users) and integration (with other teams) for specific epics.
The problem with this approach is that epics should be fluid based on user feedback. You create epics through brainstorming and storyboarding of features, but you need to realize that as you complete and roll out individual stories in the epic that the epic’s overall scope should stay fluid.
You might deem an epic with 100 stories as “complete” by the users after you’ve only completed 15 stories because the return on investment (ROI) for completing the other 85 stories falls below the ROI for features in a different epic. Likewise, an epic the team originally thought would be a minor feature with only eight stories might provide an unexpected productivity improvement for the users if they complete three additional unplanned stories.
Time spent story pointing and discussing stories to determine a specific epic due date using velocity is better spent doing real-time prioritization using granular prioritized stories.
Instead of focusing on the Gantt-chart layout of epics with specific due dates, a team should focus on the next most important set of features across epics and prioritize the current set of stories to fulfill portions of each epic. Teams that embrace Granular Prioritized Stories allow the project and product owners and the business to fully prioritize feature rollouts based on the highest ROI across epics.
Not Capturing or Ignoring User Feedback
Business and development teams work together to define systems with storyboarding, mockups, user interviews and so on. These are an excellent method to get a baseline vision and overall sizing of the application development effort. Both waterfall and agile teams also provide periodic demos to the users and business to show progress and gather user feedback. Periodic demos in a QA/Test environment are much less effective than actual users interacting with the system in production performing actual work.
Most applications “dropped” onto the user base in major releases spread out over months and years are not well received because the user’s first real interactions with the application occur when the release is supposed to be complete. This means the team has very little time or resources to devote to adjusting the user experience.
When your teams use granular prioritized stories, frequent production deploys (Before MVP), and feature toggles, they’ll produce easier-to-use systems, achieve ROI earlier, and have a better overall acceptance rate because they can absorb production user feedback into the application as they develop it.
An important subset of user feedback are edge conditions that are difficult to imagine and set up in a development walkthrough environment. Teams that can gather this user feedback can prioritize handling edge conditions as the feature is being developed instead of “dropping” a fully built epic to the users and having to immediately rearchitect or redesign to handle multiple edge conditions simultaneously.
Focus on Velocity
Team members have an inherent desire to deliver quality applications to end users. Teams want to feel like their work is providing a productive, high-quality end-user experience. Unfortunately, when you artificially delay production deployments of the application (ex. waiting for MVP, not using feature toggles to control access, and so on), it causes your teams to search for other mechanisms to show productivity and ROI.
Teams focus on velocity because they can calculate it easily, and it seems to give a good overall status of the application. When velocity is the only measure of a team’s success, it causes teams to become hyper-focused on velocity, which is evident in teams prolongedly arguing about estimates. From your business’s perspective, a team with an average velocity of 48 story points over eight months with no production deploys has no ROI for the application.
Teams that realize they can only determine their performance by looking at the ROI gained by the rollout of the application in a production environment can look past velocity as a primary measurement tool and begin to focus on production deployment frequency. Velocity and other team metrics are only useful for seeing minor productivity trends within the team.
Week-Long Feature Branches
Successful agile teams require integrating new features across the application from many different developers while still producing a reliable and deployable application. Feature branches provide a straightforward mechanism for separating work and allowing developers to switch work streams by setting aside their current feature branch to switch to a different feature branch.A secondary use for feature branches is for open-source development where the application maintainers actively want to control the integration of features because each developer can attempt to move the application in a different direction than the maintainer’s overall vision (i.e., block integration of outside features). This means teams never integrate many feature branches and pull requests.
“Corporate” application developers that work on long-running feature branches that take weeks to deploy, or become orphaned, results in a significant source of waste and lost ROI. You shouldn’t require feature branches to control the integration of features because the application developers who prioritize using granular prioritized stories are working on high-ROI stories controlled by feature toggles.
Your teams might still use feature branches with pull requests within a DevOps structure that automatically builds pull requests before approving the request, but these feature branches are at an individual story level, not at a feature level. Each “feature” branch in this usage becomes a one to two-day mini branch not tied to a specific feature. Development teams that don’t auto-build and merge pull requests can develop directly in the master branch and use feature branches for very limited scenarios (ex. hotfix branches or branches to support multiple major versions simultaneously in production). Instead of feature branches master branch developers can rely on Git’s stash mechanism to quickly switch to other stories without a feature branch.
“All or Nothing” Stories in Agile
Agile teams that begin with story estimating, MVP definition, long-running feature branches, and infrequent production deployments quickly fall into creating larger stories. This occurs because it’s slightly easier to estimate fewer large stories. This setback occurs when teams lose the ability to care about individual stories and small feature improvements. MVP-based story definition also drives “all or nothing” stories because teams believe that the MVP translates to the smallest business process that can deliver ROI. Team members working on “all or nothing” stories cannot get user feedback or see ROI of their work, which causes the team’s output to look like a waterfall project.
Your teams can avoid this pitfall by realizing that the MVP is a high-level structure to provide “elevator pitch” descriptions of the application. They can only achieve the actual development of the application with granular prioritized stories and feature toggles with frequent production deploys if they break up stories beyond the MVP.
For example, an MVP for a car rental UI might have multiple rental flows: quick rental based on generic attributes (i.e., sedan), rental of a specific car model (i.e., Honda Civic), rental of an exotic car, and bulk rental with special delivery requirements. Teams caught on this snake create a single story that includes each of these flows in a single UI (as defined in the MVP UI mockups). This story will result in a long-running feature branch that will not be available for user feedback in production.
Teams who avoid this snake can start by breaking the MVP into four rental flow stories and then further divide these stories. For example, your team can further break down the generic attribute rental flow into an initial story that simply displays the available choices (sedan, truck, exotic), which they can deploy and roll out to production for limited use with feature toggles. This allows production users to verify the basic structure of the business process before the team has built the actual rental flow and ensures the team has understood the intent of the MVP.
The team’s next story might add availability counts for each of the choices. The third story could enable the renting of a vehicle from one of the categories. This “make it work” story can cause teams to fall back to the “all or nothing” story because they need to manage all the edge conditions for renting a truck, sedan and exotic car. Teams who avoid this pitfall realize they could use simple UI blocks, including smart defaults, to simplify the edge conditions. For complex edge conditions where smart defaults aren’t appropriate (ex. the exotic car flow), the UI could simply pop up “Please call for assistance” so they can postpone the development of the full set of edge conditions for that rental flow.
Conclusion
Basic agile development methodologies have provided teams with a boost in productivity and end-user ROI, but they cannot completely reduce the increasing complexity of applications and their development lifecycle. Teams that recognize and avoid the snakes of agile software development by embracing the appropriate ladders can reach beyond initial agile training to deliver ROI with a repeatable (and enjoyable) development process.
In our Agile Transformation white paper, we walk you through the challenges of scaling agile while providing you with solutions and steps to ensure you can do it successfully.
