Many software development teams use an Agile backlog but have NO business agility – and actually use Scrum with a waterfall mentality! If the product backlog is used in a Scrum project and the company doesn't really understand Agile, it's a waste of money and most programmers are miserable!

In this episode, I share what I've learned about using agile methodologies with software teams that actually lead to business agility. Business agility is the ability of a company developing a software product to adapt to feedback and data collected about customer usage. Because software development is such an unpredictable engineering activity, a company can choose to pin its hopes on estimates or deliver more frequent releases and be guided by data.

In the 1990s and earlier, we met once a week to do status reports and developed software products in steps – similar to Scrum. This was the waterfall software development process. But when our industry realized that programming estimates were so unreliable, we needed a way to spend money more efficiently. The solution was to release the software product more frequently and stop working on features that don't give us the business results we hoped for!

If you are a programmer working on a software project and feel like the Agile Backlog is just a long list of features designed by the product owner that don't change, then that is anything but Agile! Agile literally means "able to adapt to change." If a product manager doesn't have a budget to incorporate customer feedback into their software project, they won't have the money to change it. Truly Agile software development requires humility and collecting usage metrics on every software feature the development team creates.

During each backlog refinement, data and feedback from previous sprints should be available to inform backlog prioritization decisions. This ensures that sprint planning always includes the customer as a partner in making decisions about what software features to build.

Unless features are released at the end of each Sprint, the Development Team just produces code without appropriate usage metrics that tell the Product Manager if the product is going in the right direction! This usually leads to Scrum Teams focusing on estimates instead of the business value of the product.

I hope this episode helps you understand how programmers, product owners, scrum masters, and everyone else who works together to develop and release software can do so in a healthy way – where everyone is under less pressure to predict the future through estimates. Instead, we can use the insights gathered through feedback and recording data in production about how customers are using the software to produce the RIGHT features – at a sustainable pace!

#agile #programming #scrum

Do you need help with your career? Book a free career consultation:

https://jaymeedwards.com/services/software-development-coaching/#free-consultation

CHAPTER MARKERS

0:00 Introduction
0:57 The purpose of a backlog
1:19 7 waterfall backlog characters
1:28 #1 No metrics on feature usage
2:09 #2 No release after the sprint
2:55 #3 Backlog never rearranged
3:37 #4 Features that were never removed
4:19 #5 No new features
4:54 #6 Estimates for all stories
5:35 #7 Measure the output, not the results
6:32 7 ways to achieve backlog agility
6:53 #1 Measure the impact of features
7:51 #2 Release every sprint
8:51 #3 Don't build on features
10:08 #4 Use data to re-prioritize
10:42 #5 Remove bad features
11:28 #6 Commit to results
12:40 #7 Use cross-functional teams
15:25 Follow Groove

Download a free software development career guide from my homepage:

https://jaymeedwards.com

Please take the opportunity to connect with your friends and family and share this video with them if you find it useful.