Is Your “Agile” Backlog REALLY a Waterfall Project?
Agile Development • Continuous Delivery • Kanban • Scrum
Many software development teams use an agile backlog but have NO business agility - and are actually using scrum with a waterfall mindset!
Watch or listen to this episode
YOUTUBE
SPOTIFY
APPLE
Many software development teams use an agile backlog but have NO business agility – and are actually using scrum with a waterfall mindset! When the product backlog is used on a scrum project and the business doesn’t really understand agile, it wastes money and makes most programmers feel miserable!
In this episode, I share what I’ve learned about using agile methods with software teams that actually produces business agility. Business agility is the ability for a company building a software product to adapt to feedback and data gathered about how customers are using it. Since software development is such an unpredictable engineering activity, a business can choose to put their hopes in estimates, or deliver releases more often and let data be their guide.
Back in the 1990s and earlier, we still met once a week for status reports, and built software products in increments – much like scrum. This was the waterfall software development process. But as our industry realized programming estimates were so unreliable, we needed a way to be more efficient with spending money. The solution was to release the software product more often, and stop working on features that aren’t getting us the results for the business we’d hoped!
If you’re a programmer on a software project and it feels like the agile backlog is just a big list of features designed by the product owner that don’t change, there’s no agility in that! Agile literally means “able to adapt to change”. If a product manager doesn’t budget to accommodate customer feedback in their software project – they won’t have the money to change it. True agile software development takes humility, and gathering usage metrics about every software feature the development team builds.
Whenever backlog refinement happens, there should be data and feedback available from previous sprints influencing backlog prioritization decisions. This makes sprint planning always consider the customer as a partner in decisions about what features of the software to build.
Unless features are released at the end of each sprint, the development team is just cranking out code without any corresponding usage metrics to let the product manager know whether the product being built is moving in the right direction! This is what usually results in scrum teams focusing on estimates instead of the business value of what’s being produced.
I hope this episode helps you understand how programmers, product owners, scrum masters, and everyone else who works together to build and release software can do it in a healthy way – where less stress is placed on everyone trying 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 product the RIGHT features – and at a sustainable pace!
Skip To Points In The Video
- 0:57 The Purpose of a Backlog
- 1:19 7 Waterfall Backlog Signs
- 1:28 #1 No Feature Usage Metrics
- 2:09 #2 No Release After Sprint
- 2:55 #3 Backlog Never Reordered
- 3:37 #4 Features Never Removed
- 4:19 #5 No New Features
- 4:54 #6 Estimates For All Stories
- 5:35 #7 Measuring Output Not Outcomes
- 6:32 7 Ways To Get Backlog Agility
- 6:53 #1 Measure Feature Impact
- 7:51 #2 Release Every Sprint
- 8:51 #3 Don’t Build Onto Features
- 10:08 #4 Use Data To Reprioritize
- 10:42 #5 Remove Bad Features
- 11:28 #6 Commit To Outcomes
- 12:40 #7 Use Cross-Functional Teams
- 15:25 Episode Groove
About the THRIVING TECHNOLOGIST show
On YouTube and all major podcast networks, Jayme shares teamwork and leadership strategies, guidelines for healthy company culture, and stories about real projects so you can have a sustainable career in the software industry.
Jayme Edwards
A family man and veteran of nearly 40 software projects, Jayme experienced many wins and losses over his career as an architect and consultant.
Now he's coaching software developers, managers, and business owners to overcome challenges in the IT industry - so they keep growing.