One person can make a difference
I’ve spent the last 13 years working in, managing, or building Agile teams. After nearly two decades in the Boston area, I’ve moved to Austin to be closer to my family. This has given me time for introspection regarding what has made certian teams more successful than others.
I’ve worked with many Agile teams. To be honest most have been average in success. They follow many of the Agile (or Scrum) principles and ceremonies. None the less, they still manage to maintain the status quo. They’re merely assigning a name , Agile, to their process.
Three teams have stood out as exceptional during my 24 years of hands-on-the-keyboard software development and 13 years of Agile experience. I’ve spent quite a bit of time looking at data collected and thinking about those teams and what made them successful. I’ll be writing posts about the various qualities which made them great.
First, let me define what I mean by success. In this case, a successful team:
- Delivers measurably high quality software
- Delivers measurably significant business value
- Delivers on-time as promised to the business
Note, that I didn’t say anything about group cohesion, happy hours, work-life balance, ping-pong tournaments won, or anything else outside of the iron fact that we’re hired to deliver a project. Some organizations are completely happy as long as the business isn’t on fire. This is not what I’m talking about here. I’m focusing on teams which are expected to drive revenue and growth for the business.
The #1 thing the successful teams have is one identified, assigned, dedicated Product Owner (PO). Let’s break that down.
ONE
The Product Owner; there can be only one. It’s this single person’s responsibility to know what to build. They know the customer and advocate for their needs. They know the use-cases. They work with the development team to think through all the little details of getting the software built. They are the de-facto resposititory for everything the software does or needs to do.
IDENTIFIED
Everyone knows who the Product Owner is. They have a name, a desk, an email account. They attend all the meetings and are always present when the team needs them.
ASSIGNED
This person has been told being the Product Owner is their job. They understand the responsibilities. Meeting those responsibilities is a requirement for continued employment.
DEDICATED
They are only working on this one project. It’s all they think about. It’s their sole responsibility.
When I think about the worst failing teams, they never had a Product Owner. They would try one of the following unsuccessful approaches:
- Team ownership
- Yes, the team collectively owns the code. They shouldn’t be responsible for the business value too. Let developers focus on writing great software.
- Non-development distriobuted ownership
- This is the “multiple Product Owner” strategy. This is usually the case where people want to give direction and have oversight but they don’t want responsibility or do the day-to-day work. This is an especially insidious problem in larger organizations.
I won’t guarantee that having a Product Owner will result in success. However, I can say from experience that without a Product Owner you will likely fail to be successful. You may muddle along. You may keep the lights on. You make keep this business running enough to be a lifestyle company where everyone gets to leave at 4pm on Friday. But you’ll never really make a difference.
- Everything is a P1 - July 22, 2020
- The Danger of Agenda-less Meetings - April 21, 2020
- Strictly Agile - February 12, 2018