I think it’s obvious to everyone that Scrum and the product backlog are not the same thing. Sometimes stating the obvious is useful. Scrum is a structured process of which the product backlog is a part. Mechanism Alley has posted an excellent, thoughtful article about Scrum with some references to some of what we’ve been saying about d3. It’s worth a careful read. In fact, I want to personally thank MSM for not perceiving our comments as an invitation to start flaming about this or that pet methodology.
I certainly don’t want our conversations about Scrum to be alienating to any of the excellent folks working hard under the agile umbrella. Further, I don’t want Scrum only to be the focus of these conversations. Finally, I’m not particularly interested in pumping another meme through the well-oiled Rails machine. Are we restating things said by others? Hell yes! We are standing on the shoulders of giants.
What I find a bit disturbing is that while I said a number of things about Scrum, only what Robby and I have said about the product backlog is getting attention. Further, the responses seem to fall generally into three categories:
the literature we read misrepresented the Scrum process
we have misunderstood the literature
the way the commenter uses the product backlog involves a lot of conversation, not a lot of dictation
Firstly, the book I referred to, Agile Project Management with Scrum by Ken Schwaber seems to be a good source. It seems consistent with everything knowledgeable people have posted about Scrum. And it clearly advocates agile methods. Consider this quote:
You can get through almost anything if you don’t try to impose rigid solutions before problems even arise, instead devising solutions as necessary when problems crop up. (pg 131)
That’s from chapter 9, Scaling Projects Using Scrum, which described application of Scrum to a difficult project and discussed solutions implemented in the spirit of Scrum but rather far outside of a “typical” Scrum process (if such could be argued to exist).
Secondly, we are not claiming to be Scrum experts, but that said, I don’t think I’m misunderstanding the literature. What we are aiming at are things that we think could be better understood and articulated. Just like the agile manifesto doesn’t prescribe a “right” way, it’s clear there are many implementations of agile processes. At the same time, the agile manifesto is certainly opinionated about certain processes being preferred for (and I would go as far as saying essential to) effectively creating software.
Thirdly, commenters that relate, in their experience, how much conversation is required around and facilitated by the product backlog are contributing to our confidence that there is a lot to say and understand about the dialogues we are having. Further, we are really interested in dialogues we are having with clients. We are finding this to be very challenging at best.
As Robby recently pointed out in a conversation with me, development processes often seem geared toward making the developers look good based on all the items they’ve checked off the list of the client’s wants. “See, we’ve delivered everything you’ve asked for, and on time even!” Yet through these processes, we (collectively) continue to successfully create software that sucks! We think that’s because it’s extraordinarily challenging to get processes to be goal directed based on requirements versus solutions. The way we get to this is through a lot of dialogue. We want to better understand the process and patterns of this dialogue.
And, ultimately, whether you are using Scrum or some other process under the agile umbrella, knowledge of how to conduct and facilitate this dialogue will be extremely valuable to you. So, please help us understand how you dialogue. If the product backlog is an artifact in this, please help us understand how?
Previous Topic
