Now that Agile has become mainstream, teams are looking to go beyond their Agile process to find ways to improve. There has even been recent use of the term “Antifr-Agile”, where process is secondary to product validation and customer learning (AgileDayChicago, 2016). Here are 7 ways that your team can go beyond your Agile process.
Scheduling work into fixed windows of time can constrain your team’s ability to deliver features to your customers when they are ready. After you have been doing Scrum for a while, you should consider Kanban. Kanban lets teams focus more on delivering features. Kanban lets each story flow through at its own rate and supports a continuous delivery model. Teams can even limit work in process so they maintain a constant throughput and don’t get overloaded.
For years teams have released software when they have the prioritized backlog complete. Doing so delays getting features to your customers. Instead, focus on which features can work together to deliver functionality that your customer can use. You can use story mapping to derive which groups of features you should deliver.
Think of your releases as a train with the features being passengers. In the past, because of all the ceremony around a release, the train would only depart once every year or so. Teams would try to get all of their features into the release because if they missed the train, it would be a long time before they could get onto the next train. A better approach is to embrace continuous delivery. Today’s tools and platforms make it much easier to perform a release. Now the train can depart much more frequently, allowing you to release smaller groups of features more often.
How much time do your teams spend estimating when they don’t have all of the information? Why not dive right in? Collaborate to create features, and then demonstrate those features early and often to get feedback. Leverage the concepts from the lean startup community to experiment and fail fast to learn what your customers want. Don’t be afraid to get ideas and concepts in front of your customers!
Knowing how much work your team completed does not help your customers. Do your customers really care what your velocity is? Nope. What is your definition of done? Making it to QA? Or ready for the next release in six months? Instead of tracking how many stories were completed in a sprint, track how many features you delivered to your customer. Your customers only want features they can use. Even better yet, track your customer’s satisfaction with what you are delivering. If you change what you track, you may find that you need to adjust your definition of done.
As mentioned earlier, teams generally release software when they have the prioritized backlog complete. The problem with this approach is that the backlog is usually prioritized by the organization. Change your focus to making decisions based on the benefit to the customer not to your organization. Use story mapping to determine which features, when grouped together, provide the most value to your customer. If you release those features right away, you will see a quicker return on your investment. Now you can fund the next release. All of this will cause your organization to actually receive business value sooner than it does now.
When it comes to the financial part of a project, think of it as an investment rather than an expense with a fixed budget. Limit your investment upfront and only continue funding the project if it is delivering value to your customers. If not, you can cut your losses much earlier than if you had allocated a predefined budget amount.
Here is an example given at Product Conf 2016: consider a lottery where you had to guess three numbers. Would you prefer to pay $3 and get all three numbers up front; or would you prefer to pay $1 to get the first number and find out if it is right or wrong; then if it is right pay $1 to get the second number and find out if it is right or wrong; then if it is right pay $1 to get the third number and find out if it is right or wrong?
Organizations constantly focus on the expense of a project when making decisions. A better way is to look at the cost of delaying the project. Delays can be in the form of consuming resources across too many projects, not delivering features to customers, or not even doing a project. These delays can lead to opportunity costs which can be manifested in unhappy or lost customers, missed new customers, or even competitors beating you to market. So give consideration to the cost of these delays when making project related decisions.
These are just a few of the ways that your team can go beyond your Agile process. You can learn more from the local AgileIowa user group and at conferences like dsmAgile, Product Conf 2016, Agile Day Twin Cities/Chicago, and Product Camp Twin Cites. At Source Allies our teams are always striving to improve. If you have an example of how your team has gone beyond its Agile process, please share in the comments section below!