Tag Archives: accountability
One of the foundational tools for Agile is Working Agreements. This blog will explore three uses for this power concept.
First, what is a working agreement?
A working agreement is a document of the values and behaviors that apply to a team. It facilitates great discussion about what will work for all team members. For software development teams, it could address topics such as after-hours availability, meeting etiquette, team member attitudes on interruptions, philosophical positions on accountability and more. Working agreements are powerful because they are crafted by the team, for the team. This is not management dictating terms; it is the team coming together to decide what works best for them. No two working agreements should be the same, and as team members change or teams evolve, working agreements should be modified to stay current.
Now that we know what they are, how can they help build teamwork in even the most dysfunctional team?
Facilitate Difficult but Necessary Conversations
When developing a working agreement, the team is gathered in a relaxed setting where difficult conversations can arise without drama and theatrics. Let’s talk about whether starting meetings on time is important to us. If so, we can add it to the working agreement. If there is a team member who is chronically late, then this discussion isn’t about singling them out, but rather figuring out what works best for all team members. Agile is a powerful way to do business. It is not a magic pill and it will not solve all of your problems – but it will bring them to the surface where they can be positively and proactively addressed. A working agreement is one of the tools to drive that critical conversation.
I went to a meeting last week and we were discussing how to measure a Product Owner. The concept is completely understandable, but there was something about the meeting that didn’t sit well with me so I am devoting this blog to trying articulate my concerns and things that I think need to be considered.
The premise is sound – how do you know if the Product Owner is leading you down the right path? What if you build the wrong thing? And how can you assess their mis-direction before precious time and resources are spent?
That is a 100% valid question and one that we should certainly spend time and thought to resolve. The idea that there are ratio-driven metrics to measure the PO’s performance, though, seems counter-productive.
First, I think Product Owners have a very difficult job and I think very few people are naturally great Product Owners, if you go by the broad definition. Product Owners are supposed to understand the market place, stay on top of the competition, interview current and prospective clients, and break down all of that data into meaningful features that will be delivered in order to drive the most business value. They are also supposed to be experts at writing user stories, adding acceptance criteria, understanding at least some level of the technical details associated with the application, and they need to be decisive, informed and immediately available for the Scrum Team. That is a tall order. In fact, I recommend splitting the Product Owner’s responsibilities between the Product Owner and a Product Manager, as I referenced in a previous blog.