Now, let\u2019s look at some of the more prominent \u201cladders\u201d in agile.<\/strong><\/p>\n Agile teams<\/a> 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.<\/p>\n 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\u2019s 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.<\/p>\n 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<\/a> (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.<\/p>\n 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\u2019t 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 \u201csneak-peek\u201d and real-world testing of the application with a small set of users.<\/strong><\/p>\n 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<\/a>, getting user feedback and integrating that feedback directly into the agile delivery lifecycle.<\/p>\n 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.<\/p>\n 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.<\/strong><\/p>\n 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 \u201cOn,\u201d and the user can interact with the new feature. If the user does not have access, then the feature toggle is \u201cOff,\u201d and the feature is not displayed.<\/p>\n 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.<\/p>\n 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 \u201ctruths.\u201d First, teams calculate the minimum MVP at a feature level and then stop splitting stories because they don\u2019t 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.<\/p>\n Teams that understand these baselines are myths they can easily overcome (by applying the other \u201cladder\u201d 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.<\/strong><\/p>\n 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\u2019re using as inspiration solves a similarly scaled problem.<\/p>\n 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.<\/strong> 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.<\/p>\n Now that we\u2019ve looked at some of the better agile practices, let\u2019s address the \u201csnakes\u201d that can ruin your projects.<\/p>\n 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.<\/p>\n 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<\/a> increases as the application becomes complex because the addition of features increases the management overhead of planning and deploying the application.<\/p>\n Here are a few \u201csnakes\u201d to avoid.<\/strong><\/p>\n Numerous agile methodologies<\/a> 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.<\/p>\n 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 \u201cthree vs. five\u201d (Fibonacci) or \u201cLarge vs. XL\u201d (T-Shirt sizing) to simply breaking a story into smaller parts. Teams that practice breaking down stories quickly learn how to create \u201cjust-right\u201d stories and remove the overhead of full-team discussion about trivial \u201cbuild-on\u201d stories that don\u2019t require new design decisions.<\/strong><\/p>\n 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 \u201cthree\u201d or \u201cfive\u201d 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.<\/p>\n 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.<\/p>\n 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\u2019s overall scope should stay fluid.<\/p>\n You might deem an epic with 100 stories as \u201ccomplete\u201d by the users after you\u2019ve 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.<\/p>\n 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.<\/strong><\/p>\n 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.<\/p>\n 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<\/a> 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.<\/p>\n Most applications \u201cdropped\u201d onto the user base in major releases spread out over months and years are not well received because the user\u2019s 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.<\/p>\n When your teams use granular prioritized stories, frequent production deploys (Before MVP), and feature toggles, they\u2019ll 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.<\/strong><\/p>\n 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 \u201cdropping\u201d a fully built epic to the users and having to immediately rearchitect or redesign to handle multiple edge conditions simultaneously.<\/p>\n Team members have an inherent desire to deliver quality applications<\/a> 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.<\/p>\n 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\u2019s success, it causes teams to become hyper-focused on velocity, which is evident in teams prolongedly arguing about estimates. From your business\u2019s perspective, a team with an average velocity of 48 story points over eight months with no production deploys has no ROI for the application.<\/p>\n 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.<\/strong><\/p>\n 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.<\/strong><\/p>\n \u201cCorporate\u201d 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\u2019t 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.<\/p>\nFull-Stack Devs\/Teams in Agile<\/h3>\n
Build and Deploy on Commit<\/h3>\n
Automated Integration Tests<\/h3>\n
Frequent Production Deploys (Before MVP)<\/h3>\n
Feature Toggles in Agile<\/h2>\n
Granular Prioritized Stories<\/h3>\n
Architecture Appropriate for the Problem<\/h3>\n
![\"\"](\"https:\/\/centricconsulting.com\/wp-content\/uploads\/2020\/12\/Agile_ShootsLadders_Transparent_Darker-260x300.jpg\"){kind=spacer}
<\/p>\nSnakes: Agile Hang-ups<\/h2>\n
Prolonged Arguing About Estimates<\/h3>\n
Due Dates for Epics<\/h3>\n
Not Capturing or Ignoring User Feedback<\/h3>\n
Focus on Velocity<\/h3>\n
Week-Long Feature Branches<\/h3>\n Successful agile teams require integrating new features across the application from many different developers while still producing a reliable and deployable application. <\/span> 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.<\/p>\n