In my last post we explored a situation where a Product Owner had a long-term challenge with their performance that was weighing their team down.
But as I finished that article, I realized that there might be something else going on that I wanted to explore here.
In that situation, the teams’ coach assured me that conversations and escalations had happened between herself, the team, and the Product Owner. She even said she’d escalated things to the PO’s boss. She made it sound like there was a huge amount of clear feedback over the course of two full years.
Given this, they seemed to be at an insurmountable obstacle—a poorly performing Product Owner and nobody willing to do anything to improve the situation. In other words, they were stuck.
I was talking to a fellow coach the other day and she was venting a bit about one of her teams and their Product Owner.
Bob, she said, I have an outstanding agile team. We’ve been working within our product organization for nearly two years. In that time, we’ve delivered an application upgrade that everyone has viewed as simply fantastic. Now we’re onto a building a critical piece of new system functionality for them—so we’ve earned everyone’s confidence in our abilities.
We work hard, we work well together, we deliver high-quality working code, and we have fun doing it.
Ok, I asked. That sounds like a fantastic situation. To be honest, I’m a bit jealous.
About a year ago my podcasting partner Josh Anderson asked me this question. To be honest, I hadn’t even heard the term before he brought it up. It inspired me to write this brief blog post for Velocity Partners.
I was hoping to get some traction on the questions I posed in the post, but I don’t believe anyone responded. This was about a year ago and I recently attended a presentation that made me reflect back on it.
Here’s a link to the original podcast.
The five Core Scrum Values have been defined as:
- Commitment
- Openness
- Focus
- Respect
- Courage
The reference I’m using for this include a blog post by Mike Vizdos here. And you can see them articulated on the Scrum Alliance site here.
Tobias Mayer wrote a counterpoint blog post on these values and suggested a different set and focus all his own. Here’s what Tobias had to say:
Whew! There, I said it, and now I feel a little bit better.
For years I’ve been coaching agile teams and one of the themes I’ve been emphasizing is:
- Co-location
- Sitting together at open tables
- Face-to-face collaboration
- Pairing: pair-programming, pair-testing
- Whiteboard, post-it notes, and flip charts
Have all been terms that I’ve emphasized during this time. I’ve pushed and tried to inspire teams to break down the walls and tooling and to sit together to build great products.
In a previous post, I tried to create a “Call to Arms” for Scrum Coaches and Trainers to do much more than simple, team-based training. While that seems to be a great deal of our focus, I don’t think it’s creating the environment and landscape for agile methods and Scrum in particular to “Transform the world of work”.
In early May 2014, I was at the Scrum Gathering in New Orleans and hanging out with a significant part of the CST and CSC community. A great deal of the discussion on how to “Transform the world of work” is focused on training and certifications. To be honest, I’m quite disappointed on the lip service that is largely given to the world of agile coaching. And coaching “downward”, toward the team, is most of that coaching focus.
No is a very tricky word. I often talk about agile teams needing to “just say No” to various things. For example:
- If their Product Owner expects them to deliver more than their capacity
- If their Boss asked them to deliver faster and it would violate their Definition of Done agreements
- If a Team Member continues to “go it alone” and refuses to collaborate as a team
Then I’m looking for the team to say No. Whenever I bring this up in classes or presentations, I always get pushback. Always. Usually its not based on the situation, but to the word. It seems No is a word that nobody likes using in the workplace.
There’s a wonderful video by Henrik Kniberg where he explores the role of the Scrum Product Owner. In it he makes the point that the most important word that a Product Owner can use is No. That it’s incredibly easy to say – Yes to every request. To pretend that things are always feasible or easy. But that No is important. No implies that trade-off decisions need to be made on the part of the customer or the organizations leadership. That the word leads to thinking, discussion, and decision-making.
It’s sort of a chicken and egg problem in many agile teams—that is the notion of trust.
- Do you give the team your trust as an organization? Or do they have to earn it over time?
- And if they make a mistake or miss a commitment, do they immediately lose your trust? And then have to start earning it again?
- And is trust reciprocal, i.e., does the organization need to gain the trust of the team? And if so, how does that work?
I want to explore trust in this article. I’ve done it before, but an interview by Jeff Nielsen inspired me to revisit it.
I was once working with a peer agile coach and we were discussing the role of the coach within agile teams. His view was that it was as a “soft, encouraging, influencing” role. That at its core agility is about the team. And the team in this sense is…self-directed.
He also emphasized that taking a more direct or prescriptive approach in our coaching would be anathema to good agile practices. That it was draconian and dogmatic.
He was actually a leader of this firms coaching team, so he had tremendous influence over a team of ten or so agile coaches. I was one of them and I sometimes struggled with his view and approach.
I saw the following series of snippets in a LinkedIn discussion on the Agile ALM tool Rally. Bear with me as you read through them to get the context for our discussion…
Original Question
I have a serious case of "I want to get back to JIRA Agile".
My latest challenge with Rally is to find the best and most true way of dealing with unfinished stories at the end of a sprint.
Story: I as a ScrumMaster want to move 3 unfinished stories from Sprint 1 to Sprint 2 gracefully so that the team will have these stories in the next sprint without falsifying the velocity of Sprint 2 or the backlog and not creating any more overhead for the ScrumMaster.
Acceptance Criteria:
- Total backlog story points stays true
- Velocity of previous sprint stays true (commitment is reflected accurately)
- it's not adding a huge amount of overhead on the ScrumMaster or the person doing it
- It doesn't need a custom app for doing this
Looking forward to your feedback!
