Dan Rawsthorne

Imagine you are at the sprint review and the Sales Manager says “that looks good – I can sell the heck out of that – ship that puppy!” Now what? what do you need to do to get the system shipped, and how and when will you do it?

First of all, what does the Sales Manager mean when she says “ship that puppy!” anyway? Well, here is a list of things she might be expecting to see once the system is shipped:

  - The product is available to users. It provides value, doesn’t break or blow up in their faces, meets performance requirements, and so on. It has accurate documentation, and the Help Desk is prepared to answer questions about the new version.

  - Marketing has new materials and the marketing plan is implemented, including advertisements, YouTube videos, Google key words, and so on. 

  - Sales is able to sell the new version. The Sales System is updated to manage the sales, new sales forms exist, the website’s sales pages are updated, and so on.

How much of this is your team’s problem? What has your team done, what is it doing, and what must it do to make this happen? Good questions! In any case, It’s pretty likely that much (if not most) of this stuff has yet to be done, so let’s discuss how and when it might get done. To do this we need to understand the notion of “done” from a release’s perspective.

There are three definitions of “release done” that I’d like to discuss: ‘feature complete’, ‘code complete’, and ‘releasable’. We know that the Sales Manager believes that the system is feature complete; that is, it does what we want it to do in order to provide ROI. We’re not going to argue with that – she’s the boss!

What about code complete? Well, what does that mean? It means that not only does it do what we want it to do, but it doesn’t do what we don’t want it to do. The edge cases don’t blow up, and there are no surprises. It satisfies the “ilities” requirements, like security, performance and interoperability, and it just plain works. 

And what about releasable? Well, in order to be releasable there is lots of other stuff we need: user documentation, training materials, sales and marketing materials, training and documentation for the help desk, and so on.

We need to move our system from feature complete to releasable, if it isn’t there already. If it is there, congratulations! You are one of the few, and truly special, teams, and need read no further. If it’s not there (like most of us), you need a Release Sprint. It is generally accepted guidance in the agile community that it should take no more than one Sprint to move from feature complete through code complete to releasable, and we call this sprint the Release Sprint. 

The Release Sprint is at the end of the release to move the product from feature complete to releasable, and since most systems aren’t always in a releasable state, I am recommending it as a standard practice – at least for go-live releases. For alpha and beta releases we may release with lesser standards – we must determine that on a case-by-case basis. So, what sorts of things do we do in this release sprint? Let’s just look at the preceding paragraphs and make a list:

  - Exploratory Testing to find what things need to be done – what holes need to be plugged – in order to assure that the system doesn’t blow up, the edge cases are handled, and there isn’t something else going on we don’t want it to do

  - Performance testing (may need to be done in a test lab we don’t own) to find defects and holes to be plugged

  - Interoperality testing (may need to be done in a test lab we don’t own) to find defects and holes to be plugged

  - Plug those holes and fix those defects

  - Finish User Documentation

  - Finish Maintenance Documentation

  - Finish Help Desk Documentation

  - Finish Training Materials

  - Support Marketing and Sales as they finish their documentation and materials

  - Train the Help Desk to support the new system

  - Other stuff – it’s up to you…

I’m pretty sure that this is more than one sprint’s worth of work for most teams, so you’ll have to actually be closer to releasible – at all times – than you really want to be, in order to be ONLY one sprint away from releasable (for example, it is my experience that teams that think they are ready are often 3-6 months away from being releasable). Of course, there is NO ROOM to defer additional work to this sprint – that way lies madness and sure failure! You and your team must realize that the “release” Sprint is NOT about adding functionality, it is not about doing work you deferred, it is only about coming to closure and making the product releasable once it is already feature complete! 

Thanks, Dan  ;-)

Dan Rawsthorne product owner product owner, review, sprint

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

Imagine our Product Owner says: “I want this feature by tomorrow, and I don’t care if you’ve got to hack it in – if we don’t deliver it tomorrow it will cost us millions of dollars!!” What do we do?

That’s a rhetorical question, I hope. Of course, we just hack it in – You intentionally create technical debt – because doing the “right thing” is not always the right thing to do. There could be a higher business value that overules quality, right? Now, I know that there are those that don’t agree with me here, but I certainly hope you’re not one of them

But, then what? We’ve got this part of your code that’s just hacked in, sitting there stinking up the place. We’ve got to live your values. The scrum values I teach are openness, focus, commitment, courage, respect, and visibility (this is a non-standard list). The values that are relevant to this situation are respect and visibility; we must respect our product, and make it visible that we just created technical debt. By the way, I should have the same feelings even if I was the one to put in the technical debt, and it wasn’t the fault of my Product Owner

 

So, I recommend that we add a “make-up” story to the backlog; a story that apologizes to our code base and promises to fix it. For example, let’s say that what we did while hacking the code was forget the unit testing and create some badly designed code (in module XYZ) that needs re-factoring. Then, what we would do is add a story to the backlog named “Fix up Module XYZ” in which we would explain what unit testing needs to be done and what code needs to be re-factored.

This story serves two purposes. The first is that it formally admits that we left a mess behind, and can be thought of as an apology to our product. The second is that it forces our Product Owner to make conscious decisions in the future NOT to “Fix up Module XYZ” in order to add other features. The first purpose proves that we are living our values, and the second purpose forces the product owner to make active prioritization decisions of features versus quality.

Both of these purposes are in the best traditions of scrum, but the second might be the most important. We need to “force” our Product Owner to make active decisions (both good and bad) about what our system should be. I have found that passive decision-making is almost always bad for our product, and reflects the fact that “all that is necessary for the triumph of evil is that good men do nothing” (Edmund Burke, 1790)

Thanks, Dan  ;-)

Dan Rawsthorne technical debt scrummaster, technical debt, technical owner

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