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!
Last week I attended a 4-day Scaled Agile Framework class with a result of sitting for my SAFe Program Consultant (SPC) test. A few days after the class, I received an email telling me I passed the exam. I am now a proud and newly minted SPC. This enables me to teach several SAFe courses, to kick-off and coach Agile Release Trains (PSI’s), and to generally coach organizations that are adopting SAFe.
But to be honest, I’m still digesting SAFe. It’s not that I’m having trouble with the concepts or approaches. It’s more so that I’m having a challenge fitting them into my own experience in a useful way. You see much of what I learned in the class I’ve been using and doing for a long time in my own agile journey. But I’ve couched those techniques under Scrum of Scrums for agile scaling—and with fairly good success.
I’m a Certified Scrum Coach and I know quite a few CST’s. Many of them offer training and coaching as part of their services. However, the typical client interaction, either with public classes or private training engagements, for many of them is as follows:
- Deliver a 2-day CSM class to a group of mostly client team members
- Rarely deliver a “talk to leadership” as part of the engagement, as theirs is more of a team-centric play…
Then they move off on their merry way. One of the “tag lines” of the Scrum Alliance is “Transforming the world of work”; so many CST’s get a sense of accomplishment at this point—feeling that the world of work has been, well…transformed.