- Written by Lee Allison
What is the differences between product and process?
In the agile world we are obviously dealing with both product (what is being built) and process (how it is being built). Now, when I say how I'm not talking about technical architectural decisions like using Amazon Web Services over Microsoft Cloud Services. No, I'm talking about the implementation of your company's Scrum or Agile process. I'm coming to see that we break apart these aspects of our work all the time.
Earlier today I was in a conversation with David Hawks of Agile Velocity here in Austin and we came to realize that one area where this distinction is clearly made is in the Acceptance Criteria vs the Definition of Done.
Acceptance Criteria are all the things that the product has to do in order to make the stakeholders and Product Owner happy with the product. Can the user log in? Can she retrieve past orders? Can she re-order something? Things like that. These are all things that are mostly product-oriented. Outside of the builder team, no one really cares how the product accomplishes these things, they simply care that they can be done.
Definition of Done, on the other hand is mostly concerned with the how part of this discussion. Was the code either pair programmed or inspected? Was the code properly checked in? Did the code get through testing? See the trend? All of those items that I mentioned had something to do with the actual process and were aimed at getting the team to write quality code.
To check for validity let's look at this from the other perspective... Can I write code that easily passes the DoD but not the AC? Absolutly. I can perfectly check in good quality code that has been pair programmed and tested but doesn't even allow my users to log in. Done it is, but accepted it won't be.
And reverse? Yes, indeed... I can write munge-code that can't even spell QA let alone pass the tests, but (for now) it fully supports all of the AC that were written on the back of the story card. Just be very careful allowing anyone else to touch that code or do anything with it. :)
What's that? You want another example? OK... Sprint reviews vs Sprint retros. Empirical processes require that we have Inspection, Adaption and Transparency. Both the review and the retro provide mechanisims for achieving this goal but with different focuses. The review is entirely focused on inspecting, adapting and being transparent about the prodcut. But as soon as we're done with the product we turn right around and start the same excercise but this time we're dealing with the process!
Oooh, this is fun!
Product Owner vs Scrum Master (this one is dead easy!) The answers are right in their names, to be honest. PO is all about the product, SM is all about the process.
I'm sure there are more examples but those will get you started. I like looking at Scrum through this lens because it helps me keep track of what portion of the Scrum whole I am supposed to be working with. What about you, Dear Reader? Any other examples you can think of?