Dan Rawsthorne

I’ve been using and studying scrum ever since I heard about it from Linda Rising 12 or so years ago. At it’s core Scrum is a pattern language (http://en.wikipedia.org/wiki/Pattern_language), and it’s been evolving as people find better ways of doing things, and thepatterns have changed. This post will give a very quick overview of what I’ve seen change. I believe that Scrum has gone through two significant versions, and I’m willing to guess what the next version is. To track these stages of evolution,  I’ll number them Scrum I, II, and III and then direct your attention towards the interesting points of evolution.

(Scrum I, Early Scrum, 1995-2004-ish) PO usually external to team, negotiates sprint backlog with the team. The team self-organizes, produces “done” product, and has a Sprint Review with the PO, who either approves or disapproves the work. The only way to “officially” change requirements in the middle of the sprint is to have an abnormal termination and start over. After the sprint the team (sometimes including the PO) has a retrospective to improve its process, and the PO modifies the release plan.

This leads to a number of Issues/Forces:
 - adapting to business changes within the sprint is difficult
 - hard to talk to PO for additional guidance during the sprint
 - often caused the team to view the PO as “one of them” and not “one of us”
 - many teams created a “Product Owner Proxy” who represented the PO day-to-day on the team

(Scrum II, Modern Scrum, 2002-Present) PO internal to team, and negotiates sprint backlog with rest of team. The team (including the PO) self-organizes, produces “done” product that is accepted by the PO along the way. Teams develop various methods for reprioritizing and bringing in new work during a sprint (negotiating techniques, mid-sprint replanning, etc). The Team (including PO) reviews the results with external stakeholders during the Sprint Review and receives feedback that changes the release plan and is incorporated into the next sprint’s planning. After the sprint the team (including the PO) has a retrospective to improve its process.

Differences:
 - PO on team
 - more in-the-sprint changes to Sprint Backlog
 - PO is more a part of the team’s day to day work
 - Adaptive Evolution of the Product is finer grained
 - Focus on delivery to Stakeholders, not PO

There were/are some Issues/Forces:
 - Still not quite adaptive enough for some
 - “last few” stories on sprint backlog are always being supplanted by new ones
 - Sprint lengths got shorter to allow for more frequent feedback and planning
 - can’t make the sprints as short as we’d like to because some stories just “take that long”

(Scrum III (KanBan-ish version), 2007-Present) There is no Sprint Backlog, only Work In Progress (WIP), which is fixed length set of stories currently being worked on. There is still a Sprint, which is a fixed-length timebox that defines the time between reviews, the changes to release planning, and the setting of sprint goals. At the beginning of the sprint the Product Owner negotiates goals for the sprint with the team. The team is constantly grooming and reprioritizing the backlog. When a story is completed, a new one is moved up to the WIP and begun. At the end of the Sprint there is a Sprint Review for the Stakeholders where the completed work is reviewed.

Differences:
 - Sprint Backlog replaced by WIP
 - because is WIP, stories can go across sprint boundaries

Note that this evolutionary change is much smaller than the former. Perhaps we are converging on a final solution – I don’t know. I have no idea what comes after this. We’ll just have to wait and see what issues come up, and what patterns emerge.

Dan  

admin scrum evolution, planning, po, scrum, sprint review

There has been a lot of talk lately about the Product Owner, and people are getting quite heated about it. Here’s my take on it.

The Product Owner is the person (not role, person) who is held accountable for the success of the team. He/she is the boss, commander, one throat to choke, MFIC, single wringable neck, Big Cheese, etc. If you want to know who the PO is, just ask management who has the bullseye painted on his/her chest. Period… and that’s all I have to say about that.

Well, maybe not. Because of this unique relationship the ProductOwner has with both management and the team, some things should be obvious. Among these are:

 1. the ProductOwner has the right to be involved in every decision the team makes, and has veto power at all times, and

 2. the team has the obligation to give the ProductOwner all the information needed to make good decisions.

Wait a minute, though. Scrum has 3 roles (roles, not people) defined: ProductOwner, ScrumMaster, and TeamMember. Oh… so we have a person called the ProductOwner, and a role called the ProductOwner. How interesting… could this cause a problem?

Yes. It gets people confused. Don’t be one of them… just follow along. 

On a scrum team there are three sets of responsibilities:

 1. Whats and Whens: What are we building? When do we need it? What does that requirement mean? What provides value to StakeHolders? Etcetera. These are usually called the ProductOwner responsibilities.

 2. Hows and Dos: How do we do it? How do we verify it? Actually Do the work. Etcetera. These are called the Team Member responsibilities.

 3. Team and Process: How does this team work? What is the Process? Facilitation. Etcetera. These are called the ScrumMaster resonsibilities.

Here’s the rub – SELF-ORGANIZING TEAM. People have skills, people don’t play roles. THe scrum team makes up its own rules obout who does what – that’s the essence of the team’s process in scrum. That’s why the PO(person) writes the stories on some teams, and not on others… that’s why the PO(person) does acceptance testing on some teams, and not on others… that’s why the PO(person) does design and architecture on some teams, and not on others… the list goes on and on.

Of course, some organizations have attempted to “processize” the job of the PO(person), so that they all do the same things on the teams within the organization. Other organizations have insisted that just because you do some of the ProductOwner responsibilities, you must BE the ProductOwner. (do you really think an analyst is the “single wringable neck”? I didn’t think so…) It’s your team, it’s your organization, you do what you want to do… This is just my opinion.

But, as far as I’m concerned, here’s all you have to remember about the ProductOwner: 

 - the ProductOwner is the TeamMember who is the “single wringable neck”

 - what the ProductOwner does on the team is based on his/her skills and the needs of the team

 - all ProductOwners are different

Thanks,  Dan  ;-)

Dan Rawsthorne product owner product owner, responsibiity, role, scrum

I’d like to rant a little bit on something that I find prevalent in the teams that I coach and in the classes that I teach. When I talk to people about scrum (and agility in general) I invariably hear things like “I’d like my teams to be more efficient,” “we’re using scrum so that will be more efficient,” and of course, “we’ll be more efficient with this process and save some money, right?”

The answer is “no” or “not right away”, and this usually leads to a conversation about effective versus efficient. By definition, effectiveness is “producing a powerful effect”, which in software means that we deliver something useful to the business. Efficiency, on the other hand, is “producing results with little wasted effort” which is a completely different thing, and is a totally non-agile concept.

Now, let’s look at what businesses usually do (Remember that you are what you actually do, not what you say you do). In my experience, most businesses are in the business of “keeping their people busy” rather than in the business of “producing product”. That is, managers get in more trouble for their people “wasting time” than they do for their organizations not producing the right product. This is a shame.

Agility is all about “inspect and adapt” cycles, or feedback. The more feedbacks that you have the more effective you’ll be, but the more effort you’ll be spending. This is inherently inefficient — we are sacrificing efficiency for effectiveness on purpose. In order to be efficiently agile, you would need to have feedback loops that got you the answers you needed as fast as possible, and have as few feedback loops as possible. And we don’t know how to do that, now do we?

This is where we get phrases like “fail fast, fail early”, which is a way of saying we like to be efficiently agile, by learning our lessons as fast as possible. Okay, I wouldn’t mind being efficiently agile, but I’d much rather be effective than efficient. And, in my view, it doesn’t do any good to even try to be efficient until you already know how to be effective. That is, if you can’t produce the right product every time (or virtually every time) then don’t start adding efficiencies to your process.

To put it quite simply, “waterfall is efficient — agility is effective”, and when we try to be efficiently agile we often wind up introducing false predictability into our process that winds up hurting us in the end.

Enough for now, just my two cents, Dan

admin scrum agile, effective, products, scrum

I have worked in software for more than 25 years in many capacities, from coder to product/project manager. I have worked small (3 people working on an e-commerce web site) and large (500 people working on aircraft avionics) projects, and have learned many things about what works and what doesn’t. I’ve worked in small hack it out” companies and big CMM and ISO organizations and have been involved in process improvement in most of them.

At Danube I am a transformation agent I help organizations transform themselves through applications of common sense and agile techniques. My formal training (PhD in mathematics) guides me to look for underlying problems rather than focus on surface symptoms; my military background (retired reserve officer) helps me understand the importance of teamwork and empowerment; and my common sense tells me that change must happen in small manageable bites.

I am a Certified Scrum Trainer with knowledge of many software processes, procedures, and techniques and bring them all to bear on the problems I see. I’m a firm believer in agility, having been introduced to eXtreme Programming (XP) by Kent Beck in 1995, and to scrum by Linda Rising soon after. It was these experiences that led me to move from government consulting to become a coach and consultant.

Lately I’ve been doing a lot of bowling with my daughter, and thinking about large scale agility.

Dan Rawsthorne Uncategorized agile, done, scrum, software