Change Starts From The Beginning

In a conversation with a fellow Scrum Master recently, my mind spit out a phrase that I thought was actually quite good: “Change doesn’t happen from the rear, nor the top or bottom. Change starts from the beginning.”  It was sort of off the cuff, but I really rather liked it, and it inspired me to write a little bit more about the statement.

Getting “Work” Done

This phrase came about based on some feedback I was receiving about a different conversation, in which I’d talked about the putting problems and/or objectives into a product backlog, as opposed to “work”, a.k.a. the actual tasks team members will be undertaking.  Many teams and organizations transitioning to Agile experience a phase where, not understanding any different, they map their old mindsets to new practices. Unchecked, we call this “Lipstick on a pig”: fancy window dressing on old concepts.

A particularly damaging instance of this is taking everything a current team is doing, of course formatted in a task list or something similar, and declaring that the team’s Product Backlog. After all, the Scrum Guide says “The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases”, and that sounds just like the current task list, work breakdown structure, or Gantt chart we already have right? Score! Mark one off the list. Yes, except… well, no.

In many (most?) cases, an Agile Coach or Scrum Master will advise you that your product backlog should stop short of listing the tasks a team will take on. There are many reasons for this, all of them valid:

  • Many Product Owners will not have a deep understanding of the value delivered by a given task.
  • Product Owners are not responsible for determining how we deliver value, just ensuring that we are doing our best to maximize the value the team delivers.
  • Individual tasks may only be part of a vertical slice of functionality, which doesn’t constitute a “Potentially Shippable Increment”.
  • Task lists have even less meaning or value for external stakeholders.
  • Tasks generally represent a solution (or part of one), and solutions don’t generate nearly as much conversation or problem solving effort as, well, problems or questions.

I’m sure if I thought about it longer, I could come up with more, but I hope you get the idea. The point is that just cutting and pasting your current task list doesn’t constitute making a product backlog.

Starting at the Beginning

You may ask, “OK, but we’ve re-formed the teams, moved people around and we’re doing all of those darned ceremonies Scrum ‘forces’ on us… this isn’t really that big of a deal, right?” After all, we can inspect, adapt and use Scrum in all its glory. I would challenge, though, that true change must come from the beginning, and I see no more natural “beginning” in Scrum than the Product Backlog. On just about any representation of Scrum (or just about any other flavor of Agile), the Product Backlog will be the beginning of the flow. And if you pour garbage into the head waters of a river, you will pollute the entire stream.

There’s always commentary on whether a change to Agile needs to come from the “Top” (management) or the “Bottom” (teams and developers), but if you want to achieve success in such a major upheaval as an Agile Transformation, you need everyone to be part of the change, and even people outside of your traditional IT/Engineering structure. These are your stakeholders, and keeping with the river analogy, they’re floating right along with us.

The very nature of our conversations need to change. Change the backlog, change the conversation, and by its very nature you’ll change the way things are done.  Trying to change the way things are done in order to change the conversation is like swimming upstream: you can get there, but it can be MUCH harder.

Next Time: What Does Changing the Product Backlog Look Like?

I am going to give some time for this concept to sink in for a bit. In my next post, I’ll talk about some tactics and techniques for changing how we represent our Product Backlog, and the necessary changes that are required to make that happen. At some point, I’ll also cover some of the results you may find by changing how we talk about “work”, both obvious and subtle.

Thanks for reading! As always, I welcome your feedback, questions, thoughts and concerns.