Better Software West 2018 - Agile Product Development
Wednesday, June 6
Outcome Over Output: Don't Be a Backlog Lumberjack
As agile goes mainstream, many organizations are only focused on mastering different elements of agile frameworks. Progress is measured by vanity metrics such as velocity and burndown charts. These metrics can turn agile teams into backlog lumberjacks! Teams, ScrumMasters, and leadership must realize that while speed to launch is crucial to delivering software, speed to learning is even more important. To accomplish this mindset shift, product owners need to learn to change their focus from mastering the art of writing user stories to connecting their teams with the users of their products...
Beating the Feature Factory Mindset
On a human level, we crave outcomes and impact. But in software product development, there is something addictive about the "build more and more features" approach that often leaves people frustrated and unsatisfied. Developers understand the challenges of working in output-focused environments and the adverse effects this has on productivity, morale, and business impact. Join John Cutler as he discusses these "feature factories," why they exist, how they impact your business, and how you can shift the focus to outcomes and impact. John thoroughly makes the case that churning out features...
Measuring Flow: Metrics That Matter
Are you considering kanban but not sure how you’ll predict delivery without story points, velocity, and a burndown chart? Or are you part of a Scrum team but feeling like your team could benefit from improved flow within your sprints? In this session, join Julie Wyman and Hunter Tammaro as they explore key kanban metrics for measuring team flow and predictability. In the first half, they will introduce metrics including lead and cycle time, throughput, and the cumulative flow diagram. They’ll review what each represents, discuss easy ways to collect them, and show how they are similar and...
Thursday, June 7
Stop Guessing and Validate What Your Customers Want
In agile, everything we do is an experiment. Product development is no different. We think we know what the customer wants, and the customer thinks they know what they want, but it turns out we're all wrong! To get to validated discoveries about our features, we must understand how to write a better hypothesis for our development experiments. This session focuses on challenging the mindset that we are validating options during our experiments. Natalie Warnert will show you how to eliminate options that don't work with data and feedback by looking at your product hypotheses as tests that...
Unlocking Retrospectives
Retrospectives empower teams to learn and improve. But many teams fail to reach their true learning potential. Ryan was part of a team that held retrospectives for a year and a half to fix one line of code. Through the story of this team, he will show you how they turned their retrospectives from a meeting with meaningless action items to one that accomplished a meaningful improvement. Ryan will explore the resistance that was met and how it was overcome. He will show how to shift to a hypothesis-driven retrospective that to guides specific improvements and learning goals. His team made...
Building the Perfect Product Backlog
"Efficiency is doing things right; effectiveness is doing the right things." This quote from Peter Drucker identifies why even the most productive agile teams may not always deliver the most successful business solutions. The agile team depends on the product owner to correctly identify the business requirements with the highest values, to clearly describe each feature at the right level of granularity, to provide the necessary supporting documentation, and to continuously adapt the product backlog to meet the emerging needs of the organization. Otherwise, the team could be measuring its...
Essential Product Ownership: It takes a Village
Scrum surfaced in 1993. So, the role of a Product Owner has existed for 20+ years. Surely the whole idea is well understood by now. Right? And the role is a simple one. There is a single product owner per product team or teams. Defining and accepting the work to meet the clients’ goals. Always mucking around the backlog. Again, simple and clear. Right? Well, in my coaching travels and observations it’s not that simple. I still see literally tens of organizations and hundreds of teams that struggle with the notion of product ownership. So, let’s go over it...