The ScrumButt Test (2): Working Software

The second line in the ScrumButt Test says: Software must be tested and working by the end of each iteration.

This is the second of three items that confirm that the team (project) is “iterative”. Then there is a series of small tests (within the ScrumButt Test) for whether the team is really doing Scrum (in our opinion, quick test).

Why this second line (element)?

As with almost everything in Agile, there are many good answers to that question. I will highlight three.

1. We can get better feedback. Only by having the software tested and working, can the Product Owner and the Stakeholders give the best feedback. And we want short, small, fast feedback: “Yes, it’s what I said, but now that I see it, it’s not what I want.” When it works, and they put it together with everything else that is working so far, then they can lift their eyes up from the weeds, and start to see if a real customer product is starting to emerge (be formed). Sometimes this allows them to creatively discover other visions for the product (or improvements to the vision of the product).

Arguably, one could get feedback without being fully tested. I am not particularly impressed by that argument, but I’ll leave it for now. But my next reason for this line in the ScrumButt Test addresses that argument.

2. Working (fully tested) software is the primary measure of progress. This is straight from the Agile Principles that were agreed when the Agile Manifesto was written.

And why is that important or right? Well, before that, many were measuring progress by how much paper was churned out, or how many detailed tasks were done, or by the dev team saying “We’re 63.2% done”. None of these were ever very reliable (at least in my experience and that of many others). Certainly they had minimal meaning to a business side person who had to manage the risk of delivery by a specific date.

OK, so what does it really mean to have working, fully-tested software? Well, each team must define at some level of detail what “done” means. A company, at a slightly higher level, might also have a standard definition of done (with perhaps some wiggle room for special cases).

That definition of done would typically include (or at least address) things like:

• coded (duh!)
  
•   automated unit tests built, in the configuration management system, run, fully passed
  
• refactored (anything that needs to be refactored has been: code, design, arch) Note: some refactoring might also occur after some things below
  
•  put into the integrated build and a new (QA?) environment (the new story does not break other things, etc.)
  
•  automated functional tests built, in the CM syetm, reviewed by business guys, fully passed per a QA person
  
•  other testing done (more variable by effort…eg, some performance or exploratory testing)
•  business side testing and review (maybe by the Product Owner…full thumbs up)
  
•  fully documented (any docs that need to change because of this story have been changed and reviewed and are perfect)
  
•  no outstanding bugs (or none of any consequence)

If a story passes the above criteria, then a business person (in most projects) can assume a fairly clear and small amount of additional effort to take that story or feature live. This knowledge can be very powerful and give the Product Owner the courage to identify more early releases.

3. Working and fully tested software is necessary to know (meaningfully) the team’s velocity. (Velocity is really a later element in the ScrumButt Test, but this line in the test is setting up the team to have a meaningful velocity.) Velocity is useful in many ways, but I’ll just explain it with the family vacation metaphor. When the kids in the back seat ask “when will we be there?”, if I know we are going 60 mph (our velocity), and it’s 180 miles to go, even I can give a pretty accurate answer. Good enough to make mission critical decisions like whether to pull over for a potty break. And, as it turns out, good enough for most real business decisions. And, as it turns out, giving us about as info with as much quality as we can get.

Do we need an Impediment List? Why "yes"

Yes, we need a public impediment list. Every Team does.

Why?

One argument against is that all impediments should be eliminated immediately.  Yes, if this were possible, this should be done.  But I think that thinking assumes an incorrect view of what impediments are.

Yes, it is true that some obvious impediments only appear from time to time. If if you only get small ones that appear at most once a day, then ‘fix it immediately’ is the right answer.  And you need no list.

But I think we should have a totally different attitude toward impediments.

As with Lean, we should give ourselves the ‘perfection’ challenge.  That is, we do not indulge in the fantasy that we will ever become perfect, but we challenge ourselves to strive toward perfection.  Or, more concretely, to become the best Scrum Team ever.

So, an impediment is anything that can be improved that might lead us to becoming the ‘perfect’ (best) Scrum Team.

And, of course, nothing around us, and nothing that we do, is perfect. So, everything needs to be improved.  Even Michael Phelps can swim a better race.

So, then the public impediment list really should be just the top 20 things we should fix. (If we listed everything, we might have 900 items, but in this work, it helps not at all to have a list of 900.  Just the top 20 will do for now, and that short list will be helpful.)

Impediments can be anything — anything — that is keeping the team from being perfect. Missing fun, blockers of stories, people issues, slow CI, managerial interruptions, task-switching, poor organizational incentives, bad user stories, weak PO, waterfall culture, Scrum not fully implemented in the organization, lack of urgency for change, bad corporate culture, a culture that requires hiding any ‘failure’, etc, etc, etc.  Anything. Of any type.

Also, many impediments are quite difficult to fix.  Might take time.

Also, in my experience, many quite obvious impediments are begging to be put on the list, and people pretend that the ‘rock’ is not there.  In part, because no one gave them the notion to start a list.

Lastly… Some complain, rightly in some cases, that an impediment list implies inaction on the impediments.  But of course, the purpose of the list is NOT to stop action on fixing or ameliorating them.  In fact, the list is supposed to help us attack them.

So, have a list. Attack them. Aggressively.

Impediments ( or symptoms of) - Montreal Class July 2013

Below is a list of ‘failure modes’ for projects, as identified via the experience (in waterfall, whatever, agile or scrum) by the people in the Montreal July 2013 class.  These are not in priority order.  They might suggest certain impediments to add to the list for your team.

Lack of communication

Too many impediments

Not responsive to change

Scope creep

No (or different) work approach

Too much indirect communication

No budget

Bad (or lack of) leadership

Poor quality

Too much process

Toxic teammate

No access to client

Too much documentation

Too many meetings

No teamwork (individual work silos)

Change in requirements

No Org support

Unsatisfied customer (at the end)

No vision

Unclear requirements

Delivered late

Too little experience in Team

Lack of planning

Unrealistic timelines

No fun

Lack of consistency

Hidden agendas

Lone wolves

Switching team members

Micro-managing

Too many chiefs

Over-work

No Buy-in

Starting with Scaling

I have gotten a few questions lately that go about like this:

We are starting Scrum. We have the kind of projects that require scaling. But how do we start with Scrum and have some scaling?

The first thing to say is: The basic framework of Scrum does not attempt to answer this question.  It assumes you will use lean-agile-scrum principles and values, and devise your own, specific solution to this problem.

Still, the Scrum community has dealt with this problem many times.  So, here is what Jeff Sutherland and Ken Schwaber and lots of others think are some good ideas to start with.

Let's assume you are talking about putting 3 teams together to work on one project.  To release roughly every 4 months. Let's assume each team is about 7 people, including the PO and the SM.

Let's also assume that we continue to focus on Team success.  Meaning: We realize that the core of activity is inside the Team.  If each Team is not 'working', then no amount of scaling is going to help. 
So, the Team's are real teams. Each person is 100% dedicated to one Team.

1. Chief Product Owner.  Each team has a product owner, and, in addition, there is a Chief Product Owner -- who manages the Master Product Backlog for all 3 teams.  So, the CPO is not dedicated to one Team, but to all 3 teams.

2. Product Owner group. The CPO and the 3 POs all work together.  They meet daily, in a separate 'daily stand-up' (brief, 15-minutes) meeting. To be sure things are coordinated from the business side across all 3 teams.

3. Scrum of Scrums.  SoS.  This means a Daily Scrum across all 3 teams. Specifically, each Team does the usual Daily Scrum.  Then, at least one person from each of the 3 teams comes to the Daily 'Scrum of Scrums'.  The questions are: (a) what did your teams get done yesterday, (b) what will your team get done today, and (c) what is your team's biggest impediment.  A Scrum of Scrums Master facilitates this meeting.  And addresses the impediments.

4. Scrum of Scrums Master.  There are few rules as to who this should be.  It could be a manager who is not on any Team. It could be one of the ScrumMasters on one of the Teams. Etc.  But this person becomes the 'impediment-remover-in-chief' for the impediments identified in the SoS.

5. Technical Issues. The main work of the SoS is to remove technical impediments. If a business side impediment is high, that probably would be given to the Product Owner group to address.

6. Continuous Integration. To have scaling across 3 teams, it quickly becomes very important to have much better CI (continuous integration).  This is true with just Scrum for one team. But becomes extremely urgent with scaling with 3 teams. Because they are all playing in the same code base.

7. Attendees at the SoS.  The initial idea is that the SMs from each team would form the SoS. This works fine some times.  Other times, the SoS works much better if the best technical person from a team attends.  Use common sense (which is uncommon).

8. Focus on the Teams. It is apparent that, as soon as you have a 'superstructure', people lose sight of the Teams and focus on the superstructure. Do not fall for that temptation. Of course, this is quite easy to say, and far harder to do.  Again, everyone should focus mainly within the Teams, and on what each Team produces. As much as they possibly can.

Those few ideas should get you started.  More later.

The ScrumButt Test (1): Iterations must be timeboxed

I will be doing a series of posts that discuss each element in the ScrumButt Test (see earlier post). In this first post, we will focus on the first element in the ScrumButt Test: "Iterations must be timeboxed to less than six weeks."

First, remember that the first section of the test is to determine whether a team is iterative. (The second section determines whether they are doing Scrum.)

This first element, the length of the iteration or sprint, in standard Scrum according to Ken Schwaber is one month. There are many Scrum teams now doing 2 week sprints. Or even less. Note: In Agile maybe iterations can be 6 weeks, but in Scrum a Sprint can be no longer than 4 weeks (one month).

The iterations are time-boxed. This means that the length of the iteration does not change from iteration to iteration. And we do not extend any single iteration (or sprint) because "we're not quite done yet".

Why are time-boxes important? First, "when a man knows he is to be hanged in a fortnight, it concentrates his mind wonderfully." (Samuel Johnson) It is easy for us to get distracted, and the time-box forces the team to face the real world. It forces them to cut through analysis paralysis.

Time-boxes are also wonderful is a slightly different way. You are no doubt familiar with the Pareto principle (aka the 80-20 rule or the law of the vital few). So, the team is forced to choose those "20" most important things to do and get done in that time-box, out of the wonderfully long list of "100" good things to do in their lifetimes.

And, by making the goalposts immovable, the team starts to see that the time-box has meaning. They must estimate better or work better or in some other way improve if they want to complete their work consistently every iteration.

The time-box also enables the team to reflect, on both their work product and on their work methods and approaches. And to get feedback, and make mid-course corrections. This feedback mechanism is not stated specifically in the ScrumButt Test, but to me the feedback is in there because it is such an important part of Agile and of Scrum.

We will come back to the usefulness of the time-boxed iterations as we discuss other parts of the ScrumButt Test. While, for the sake of small blog posts, we are looking at each element, it is really when the elements are together that the test starts to have real power or meaning.

The whole is greater than the sum of the parts.

Achieving the Goal of a Retrospective

Some teams seem to approach Retrospectives without a real drive to succeed.  Or so it seems.  They just use it to ‘talk’.  About the ‘good, the bad, the ugly’ as I sometimes tease.

Now, talking can be helpful.  Still, we can usually do better than this.

What is the goal of a Retrospective?  Well, I think it should be to seriously improve the Team.

Sometimes, to help them have more fun. And other times to become --‘more productive’ is the usual phrase.  And becoming more productive should be a point of pride for the Team.  That they are good, and they are always getting better.  And that mere fact should be part of what makes them happy.

How do we mean more productive?  Well, I am ok with two ideas about this.  One: we are delivering more business value. Or,  two:  that our velocity has increased (and not by working harder or longer).

So, how do we make this happen?

Well, there is no end of ideas about the details of the Retrospective.  And we need o have many ideas.  Because we need to be creative about improving ourselves.

But let me suggest two basics.

1. Starting Stuff
2. Attacking one impediment

By ‘starting stuff’ I mean something fairly brief.  Let’s sat about 15 minutes.  And this section might include the following (or not, if already done or done elsewhere).

• Some appreciations or ‘yea us!’ or ‘let’s continue’.  Some good news of things going well.  We need some good news.
• Eliciting some ‘bad news’.  Mostly what we need are new impediments, or impediments not previously identified.
• Deciding on the top impediment as a team

Note that additional impediments are only useful if it or they are within the ‘top 20’ impediments.

Almost surely, anything less important than that is just distracting for the team.
Also, some times the top impediment is entirely obvious to everyone on the team. But certainly not always.

There are lots of detailed techniques for doing this starting stuff.

Also, note that I have implied (and am now saying) that the Retrospective is not a a general talk session.  It is not for general ‘bitching and moaning’.  It is not to ‘answer questions’ or just to ‘look back’ or simply to gather ‘lessons learned’.

And, we must prioritize. And make a significant improvement.

We must work on the top impediment.

Will we always choose the real top impediment?  No.  But we pick the one we think, when worked on, will give us the most benefit (improvement) per unit of cost.  (Ok, a few other factors might also be included.)  We pick our best guess at the top one.

Three things the Team should typically do in the Retrospective to attack the impediment.

1. Devise a solution.
2. Develop an implementation plan for the solution.  I do not mean a detailed Gantt chart or WBS. No.  But an approach, and identify who is needed, the basic activities, a sense of who needs to do what.  So that it can then get done.
3. An A3. Or a business case to a manager.  To get the manager to say ‘yes’.  To money, to providing people, to just approval that the change can happen.

One or more of these 3 should normally take up the bulk of the Retrospective. Normally, actually fixing the impediment is done outside the Retrospective.  By the ScrumMaster, or by the Team, or by someone outside the Team

And, we expect to get measurable improvement (eg, better velocity) in the next sprint.  Usually.
We think if you follow this advice, that your team will find the Retrospective more useful, and will become more productive overall.  And enjoy the happiness of being more successful.

Enabling Specifications

We recommend using the ‘Enabling Specification’ practice. This is NOT part of the bare framework of Scrum. But it is a frequently recommended practice. Typically recommended.

This is: Just-enough, just-in-time documentation. Meaning that the implementers in the Scrum Team have enough information to build the user story correctly the first time. Or at least they think they do before the Sprint Planning Meeting.

We are NOT recommending eliminating conversations. In fact, we always want more conversations.  The PO should be available during the Sprint to answer questions ‘immediately’. (Of course, he/she is not always able to answer them immediately, but that is what we want.)

Jeff Sutherland says this is like a patent. An enabling specification.  See the Scrum PLOP, and this blog post. Some call it an Enabling Specification.

When is each Enabling Spec built?  Just-in-time. Just before the sprint in which that user story is built.

Who creates the Enabling Spec?  Well, it is built by the right people, of course. Typically the PO will help, if there is a BA-type person in the Team helps, a BA or two outside the Team might help, a business stakeholder might help, etc. It depends on the situation.

The PO is ultimately responsible for the quality of the Enabling Specs. And the implementers in the Team are the final authority of what should be in them.

So, the Enabling Specs are ‘owned’ by the Product Owner. And then the PO must find the right people to build them. (I think it best to usually think of the Enabling Specs as one-to-one with the user stories.)

What does an Enabling Spec contain?  Well, just what the implementers want and need.  And this varies a lot from situation to situation. It depends on the nature of the story, it depends on the memories of the implementers, it depends on what they already know well (please do NOT repeat what they already know well), it depends on their skills and experience, …it depends on many things.

Here are some things that people have wanted an Enabling Spec to include:

a use case (picture)
business rules
mock-up
wire frames (I won’t bother to give a fine definition to distinguish a mock-up from a wire frame.  Although we can distinguish a picture of the main ‘screen’ we are working on, versus a picture that gives us a sense of the ‘flow’ from one ‘screen’ to another.)
business flow (often quite similar to a use case)
date elements (or columns or however you think of the data)
questions answered (the implementers can ask almost any question and we write down the answer(s))
technical issues – decisions or description of some key technical issues. One simple example: ‘The scope is only iOS.’
data flow diagram
design issues – Example: if this story will break old design patterns or create new design patterns, talk about it a bit.
acceptance criteria
other information, assumptions, or notes
If you can have a conversation and the specific implementers take good notes, and will remember correctly, the information does NOT have to be documented (again) in the Enabling Spec.

And you do not have to cover all the above sections in every Enabling Spec.  You should NOT cover all these things. Pick and choose amongst them, what is most important, most useful to your team and your situation.

And exactly what to include (or exclude) from the Enabling Spec for your Team will evolve.  The PO is always asking the Team two questions:

What did this Enabling Spec include that you found useless? (Remove that stuff on the future.)
What did we leave out in this Enabling Spec? (Start adding that stuff, where appropriate.)
Couple of things to note:

It is more important that the implementers get the information they need quickly than that the Team (PO) has an Enabling Spec.

We do not build all the Enabling Specs up-front.  This would be a big waste and a big delay.  We only build Enabling Specs for the stories just about to go into the Sprint.  Are we always correct (in guessing ahead of time which stories will go in the next sprint)?  No. But it is usually a very good guess.

Is everything defined in the Enabling Spec?  No. Only the essential stuff.  We fully expect some questions to be raised during the Sprint and answered quickly.  If the PO is less available or cannot answer quickly, then probably the Enabling Specs are fuller.  If the PO is available and can answer quickly, then the Enabling Specs are probably smaller.

Am I ‘successful’ if I just ‘complete’ the Enabling Spec?  No!  The software (product) must be truly useful. An implementer does not have ‘CYA’ simply by ‘doing’ the Enabling Spec. The real test is real progress in satisfying the customer.  The Enabling Spec is only a means to that end.

How big are they?  That varies of course.  How big do you draw? (They are largely pictures.)  Probably slightly smaller than they should be. (smile)  Half a page. 1 page. 2 pages.  Something like that.  And that is based in part on the assumption of about 8 stories in a 2 week Sprint.

Can this help you?  We of course think ‘yes’.  How much it will help will partly be based on how much the Team is ‘spinning’ on the requirements.  Sometimes the spinning is clear and obvious, and sometimes the spinning is hidden.

Does this help you?

The Team is primary

There has been a lot of discussion in the community lately about scaling.  With specific discussion of the SAFe and LeSS frameworks.

We don't have a strong opinion on many of the issues. We do think that each scaling situation is different.  We do think the music (the values and principles inside the players) is at least as important as the dance steps (the specific practices and artifacts).

One thing we do feel strongly about: the Team is primary.

Meaning, for example: It is easy for managers to think they are important. It is easy for the General to think that he alone wins the war.  But in fact, it is the soldiers who win the war. And the General's plan is always ... well, a nice piece of fiction, or a nice fantasy.

It is the innovators in the Team who do the real innovation.

Now, there can be a few key guys.  Maybe Steve Jobs was such a guy to Apple. But for most of us, the real innovation happens inside the Team.

Always keep the Team primary.

Never get so involved in SAFe or un-SAFe, LeSS or MORe so much, that divert attention too much away from the Teams.