Jason Tanner is a colleague of mine here in the Cary, NC area. He’s a Certified Scrum Trainer (CST) with the Scrum Alliance, which means he can teach certified ScrumMaster and Product Owner classes.
With that title and role comes a responsibility to stay pure to the “rules” of Scrum and its defined practices.
So, Jason will often argue with me about specific agile practices such as:
- Sprint #0’s
- Hardening Sprints
- Release Trains & Planning
As (1) not being part of Core Scrum, and he’s certainly right about that, and (2) just being plane old bad practices. It’s here that I sometimes push back a bit on Jason, thinking that he might be a bit too purist in his approach and thinking.
But it’s all done in good humor and with respect. Or at least I think it is. But that’s beside the point.
Chris Waggoner is a friend and colleague of mine. He is a CSC, Certified Scrum Coach, and a very experienced agile practitioner.
He sent me the following snippet in an email that I wanted to share:
"If Agile is a team sport, then the product backlog is the ball." - Chris Waggoner
I'm trying to get a group of PO's to realize that they should not attempt to complete a product backlog on their own but they should seek help at every phase of grooming stories and massaging the backlog. On the flip side I'm trying to involve teams who believe it’s the Product Owners responsibility to bring them a completed, ready to consume story that they to are responsible for the completeness of stories and the state of the backlog. This metaphoric phrase above came out of my mouth and it made sense to everyone once it did.
Chris Waggoner, CSC
Managing Consultant | SolutionsIQ
It was unsolicited, but nicely aligns with my own thinking.
I’ve been a Mike Cohn groupie for as long as I can remember. Mike has written, what I consider to be, three of the seminal books on agile approaches for software development. I’ll leave it as an exercise for you to lookup the books, but he’s really been one of the leading voices on how to “do Scrum” and “do Agile” for an incredibly long time.
I took my CSPO class from Mike and Ken Schwaber, just so I could learn from two of the “masters” in my agile journey. And when anyone asks me for a recommendation of an instructor for a CSM or CSPO class, Mike is at the top of my list. I remember sending all of our potential ScrumMasters at iContact years ago to Mike’s CSM classes. My logic was, that if we were going to spend the money, we might as well go to the best.
Now that I’m looking at the start of this article, I’m almost embarrassed as to how much of a Mike Cohn groupie I am. But I digress…
If you’ve any experience in agile approaches for software development, one of the common arguments surrounds documentation. Mostly it centers on software requirements, but it also extends to other forms of documentation, for example design or user centered documentation.
Many agile teams struggle with documentation. My experience aligns with folks leaning one of two ways:
- Either they continue to write requirement documentation (and literally ALL documentation) as if they were still operating in a Waterfall environment, or
- They write user stories that are so terse as to be hardly useful in describing the customer’s expectations. And they often stop writing anything else.
In other words, they go to the extremes of documentation instead of finding a healthy, lean, and communicative balance. One of the reasons for this seems to be our view of documentation as being the sole “repository” for product and team knowledge. While that’s true, I also like to remind agile teams that there is another viable form or place for that knowledge – which is the teams’ memory. Since many of the agile ceremonies are whole team events, I like to ask teams to use their collective memory as part of their product information and knowledge archive.
In 2009 I wrote the first edition of Scrum Product Ownership as a way of helping Product Owners understand their roles and responsibilities better. Before that, it was mostly an exercise in guessing and survival. In 2013, I updated the book in a second edition[1]. In both books I took on the topic of Backlog Grooming.
As it turns out the term “grooming” is losing its luster in the community and terms like maintenance and refinement are replacing it. I believe the latest copy of the Scrum Guide uses the term refinement. So I will try to start using Backlog Refinement consistently throughout this article. That being said, I really, really like the implications of the term grooming.
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 think it was George Dinwiddie that first coined the term “3 Amigos” in agile development around 2009. The analogy was akin to the movie from the mid 90’s by the same name. The Amigos in the agile sense are functional roles:
- Developer(s);
- Tester(s);
- and the Business Analyst or the Product Owner.
It could literally mean more than three as well. The point was, balanced collaboration in agile teams across these roles. George was alluding to these roles from an Acceptance Test Driven Development (ATDD) perspective. He wanted these three constituencies to be heavily collaborative (conversations) around the Acceptance Tests or Acceptance Criteria for each user story.
