Had a great time recently talking to the PMI Atlanta – Agile Interest group. Great participation and lots of fun, nice people. Please check out the presentation and let me know if you want to have this discussion at your organization.
Do you want to have more effective daily stand-ups? Do you want to have the planning meetings flow better and increase the value of these meetings? Do you want to see continuous improvement flow from your retrospectives?
If your answer is yes, then put it on the Team.
I’ve written about trust, relying on strengths, and improving self-organization many times — and the message of these can all be summed up as putting it on the Team. Make the team responsible for solving problems, make the team responsible for defining how to deliver, and making the team accountable for delivery. Most of the times when we talk about the concept of the Team self-organizing, is it more focused on the “how” part of delivery, and not the process. However, remember that the meetings (or ceremonies as some call them) are primarily for the team. Specifically, the Iteration Planning, Daily Standup (or Daily Scrum), and the Retrospective meetings — these are for the team, not the stakeholders or managers. Do the stakeholders and managers gain value from these meetings — Yes, but the real value is the fact that the Team takes ownership of what they are going to deliver, they take ownership on holding each other accountable to deliver and working through problems themselves, and they take the on responsibility the responsibility of improvement.
A lot of times we (as in Managers, Scrum Masters, Team Leads, Type-A Team Members) want to install processes and templates around these meetings. This usually happens after a few weeks or several months of trying an agile framework and either not following the guidelines of the framework or the team not taking the initiative to make improvements. We’re not getting any value and the team is resisting and or blaming the whole concept — we want to fall back to more structure and being told what to do.
A great example of this is when a team’s stand ups start becoming mundane, over-run their time boxes, and team members don’t show up. So what happens is we come up with a template for the team to keep up with for daily stand ups as well as establish a set of metrics we answer to during the stand-up. And of course, this just becomes one more thing for a team member to keep track of as well as an unintentional mechanism of command-and-control.
As an ex-Director/Manager, I often wanted to step in and help — and I usually would come up with a template and or some hard-prescribed structure and tell the team to follow it. I wanted to help and that’s what managers genuinely want to do, but I was quickly put in my place when one of my team members said, “let us figure it out, it’s our problem.” I gave guidance and advice, but otherwise I got out of the way. I let the Team come up with how they were going to make their meetings more effective. And at the end of the day, they simply looked at the frameworks themselves and decided to more closely follow the existing framework guidelines — e.g. keep stand-ups at 15 minutes and stick to the script, then allow the time remaining to become open space troubleshooting time.
At the end of the day, remember that more process does not equal more better. Rely on the Team to solve problems, over instituting process and templates to solve problems. I think I’ve heard this before somewhere …
How many of you have heard a Product Owner being described as a single-wring-able-neck, or read that the Product Owner is solely responsible for the “Return On Investment” of a product or project? Are you aware that the Product Owner is responsible to work with stakeholders to define the product or project, and they are also required to be available to the team to answer questions, give feedback, and accept the deliverables produced by the team? If you are doing Scrum, you’ve likely heard all of this.
As defined by ScrumAlliance.org, the role of Product Owner is responsible for the business value of the project. To take this a step further, Roman Pichlar inked a solid blog called Being an Effective Product Owner. In this blog, he better explains the expectations and or responsibilities of an effective Product Owner including close collaboration with team to guide and direct the team, active management of the backlog (ranking, grooming, etc.), proactively manages stakeholders [expectations], has a thorough understanding of customer needs, and has some knowledge as to how good software is developed. These responsibilities closely resemble the four aspects that Robert Galen outlines in his book, Scrum Product Ownership — Balancing Value from the Inside Out. These four aspects include part Product Manager, part Project Manager, part Leader, and part Business Analyst.
As pointed out by many in the Product Management space, the role of Product Owner is fairly broad and, although many folks like Roman and Robert have done a good job helping to better define the Product Owner, the role itself is often viewed as ambiguous. Let’s face it, in order to be a good Product Owner you are asked to know your customer, have an in-depth knowledge of how the product or project should satisfy the needs of the product, you must represent the product to both internal and external stakeholders, price and support the product/project to ensure profitability, define requirements, answer questions to the team, be a part of elaboration and planning discussions, facilitate discussions between customers and developers, work with industry analysts, plan and schedule, define what is the most important thing, … ok this is getting ridiculous. This is a lot to ask of any one person.
In years past, when organizations made the transition to Agile (specifically Scrum), the Product Owner role typically defaulted to the Product Manager or the Director responsible for a specific service area (e.g. Customer Service Director). This often meant that in addition to your current job, we are going to ask you to make yourself more available to the development team that is building your product or project. In some cases, this worked out fine — but in most, you’ll see that either the stakeholders are not happy or the development team is not happy. This is simply because there is not enough time in the day, not to mention the expectations and requirements are so broad.
Today, it is common place to see the Product Manager or Director be paired up with a Product Owner. The Product Owner role is given to a Business Analyst or Project Manager that has strong subject matter expertise. In some cases, you’ll see titles stay the same and in others, team members actually given the title of Product Owner. These two (maybe more) team members pair up to become the Product Ownership Team. The Product Manager works the external stakeholder needs while the tactical Product Owner works the internal stakeholder needs — specifically working closely with the delivery team. Arlen Bankston of Lithespeed talks about the roles of Strategic Product Owner and Tactical Product Owner in this blog.
- More brainpower up front to help understand customer needs and align to solutions,
- Time afforded to thoroughly understand the marketplace,
- Capacity to satisfy the “on-demand” need to work with the team, and
- The ability to avoid unnecessary waste due to bottlenecks that result from a poorly maintained backlog.
The possible pitfalls to look out for with this approach are:
- When the tactical Product Owner is not empowered to make decisions — you will likely end up conversations being conducted through heavy documentation and sign-off processes,
- A proxy-type relationship that can keep the delivery team from making a connection with the end-customer,
- The lack of clear vision since the tactical Product Owner my be too far down in the weeds and not able to clearly articulate the big picture, and
- Without the Product Manager (or Strategic Product Owner) interacting frequently with the team members — trust and a positive rapport does not develop between the business and the delivery team. This can lead to poor morale and underperforming teams and products.
What approach does your organization employ? Do you have a single Product Owner? Or, is Product Ownership comprised of a Team? If it is a team, are there multiple players or just two?