At first, when Scrum and when Waterfall?

When your company is first starting Scrum, how do you decide which projects use Scrum and which ones do it 'the old way'?  (Let's assume the old way is a form of waterfall.)

Here are some factors that might tilt a project toward Scrum.

1. Is the Team willing to try Scrum?  The more positive they are toward Scrum, the better.  At first it will be new, bumpy. And you want a Team willing to work through the bumps to get to some success.

In part, you need a little success in your company to get the more skeptical types to feel comfortable using Scrum.

If the Team starts in a skeptical a mood about Scrum, they start to make it fail.

2. Will someone help with the Impediments?  The more this is positive, the more you choose this work.

3. Good product owner.  If for one project you can get a good PO available 80%, and for another the PO is weaker and available 40% -- choose #1.

4. Reasonable stability of work in the Scrum.  If project 1 will not want to change the work during the Sprint much, and project 2 needs the work more often to change in the Sprint, then choose 1.  But this is reason #4.

You want the Team to commit to work in Sprint Planning Meeting, and start to see the positive momentum of completing it by the end of the Sprint.  Fewer changes (zero is even better) increase the chances of that.

5. Do-able project.  It is fine to give a new Scrum Team a challenging project. But do not give them an 'impossible' project the first time out.  Simply because they are just learning Scrum.

Now, sometimes you have to anyway.

6. The skill sets are more fungible.  Fungible is a fancy financial term.  It means that person A is more likely to be able to do (some of ) person B's work.

We want that with Scrum.

And we want it work things can be done more 'all at once'.  For example, we don't feel that we must finish all of A before we can do any of B.

7. More likely to change.
I will use that phrase, but let me explain. Project 1 is more likely to change.

Project 2 will have less change.  And project 2 is a project that we feel confident we know how to do.  Many of the people in the team feel they have done similar projects.  And we have high confidence that project 2 will have few major surprises.

In that case, I think Scrum will help project 1 more. Because Scrum will enable the Team to learn faster and adapt faster.  For project 2, at least now, it appears that learning and adapting will not have as much value.

Still, I find it hard to say this. I have had too many projects that seemed 'stable' at the beginning, and yet when we got into it, all hell broke loose.  And there was plenty of change and learning.  So, watch out for the accuracy of your initial assumptions.  You know about how the word 'assume' works.

***

I think those are the major factors.  I may have left out one or two.  Probably I will revise this post after a few comments.

What are impediments?

An impediment is anything that is slowing down the Team.  (The Scrum Team)

In PMP words, it is any kind of issue. And it may include risks as well, but typically only high probability risks that are likely to occur soon. (I do typically recommend a simple risk log for each Scrum team -- but that is an add-on to Scrum, not part of the bare framework of Scrum.)

Anything.

Even things beyond our control.  A hurricane in NYC. A tsunami. A people issue. Lack of a babysitter.

In fact, since nothing we do is perfect, every team has at least 900 impediments.  Things that can be improved somehow.  The only real question is, what are the top 20 things to improve. Or problems to address.

Some people say that blockers and impediments are different. I say no.  First, blockers are usually defined as a thing (eg, lack of knowledge) that keeps a User Story from being completed in a Sprint. This is an ok definition. But blockers are just one type of impediment.

Just as there is only one Product Backlog for a Team, there is only one impediment list for a Team. 
Thus, there is only one list for the ScrumMaster to manage (on behalf of the Team).  And the SM should always be driving the top impediment to completion.  (To some mitigation, where it is no longer #1, and something else becomes the #1 impediment.)

Some types of impediments:

• Blockers (for a user story)
• People issues
• Technical issues
• Lack of knowledge
• Operational issues
• Managerial Issues
• Organizational issues
• Process issues
• Outside disruptions (outside means from outside the Team)
• External things (weather, riots, war, etc)
• Problems that the Pigs have at home (eg, lack of babysitter)
• Lack of positive things (eg, the Team needs its own Coke machine)
• Business or customer issues
• Culture and waterfall attitudes
• Impediments to faster Scrum/Agile adoption
• Etc Etc

Many of these can be big categories with useful sub-groupings.

It turns out that usually each Team will feel improvement as soon as the agile adoption is 'complete'.  Hence, agile adoption gets on the same list. (This maybe needs more explanation in another post.)

Anything (anything!) that would lead to the Team going at a higher velocity (at a sustainable work pace) is an impediment. So, the lack of positive things (Coke machine) is an impediment.

An FAQ:

1. How often does a Team start with impediments?  Ans: Always.

2. Can the Team do some work even though it has many impediments?  Ans: Almost always.  Except the velocity would be higher if some were mitigated (well, in general, the more mitigation, the higher the velocity).

3. Can a Team be completely stopped by one impediment?  Ans: In theory, of course -- yes.  But in practice, this seldom happens.  Or the duration of the stoppage is not terrible.  Two main points:
a. The Team does not get to use the impediments as an excuse for doing nothing.
b. Someone should always be working on the top impediment, and the firm should always be making a reasonable investment in helping the Team get better.

4. Should the Team stop working if some impediments are not fixed?  Ans: In general, this seems .... not the most mature approach. But in some companies, to break certain patterns, this threat or even this action for some time might be useful and necessary.  To make a point.

5. Should we fix all the impediments before we start Sprinting?  Ans: NO!  First, by definition there are always more imperfections to work on, and we have never seen a real team that could not improve.  Second, Scrum helps the Team the next most important impediment to work on.  Thus, you must be Sprinting to get that information.

6. Who fixes an impediment?  Ans: It depends on the impediment. Obviously, the best person should fix the impediment.  "Best' is a multivariate equation. In practical terms, some are fixed by the SM. Some by the PO. Some by the Doers in the Team. Some by people outside the Team.

7. One can imagine that some technical impediments (eg, inability to do continuous integration) or organizational impediments (a tollgate process built for waterfall) could take many months or longer to fully fix.  Is this reasonable?  Ans: Yes, very often this is the case.

8. Who decides which is the Top impediment?  Ans: Ideally, the Team.  Certainly, it is form the whole team's point of view.  And the SM should force the Team to decide. It is acceptable if the Team decides to let the SM decide.  Although for the bigger impediments addressed in the Retrospective, the SM should force the Team to agree to the ordering of the Top few impediments.  Which still might change by the next day.

9. In prioritizing the impediments, what kinds of factors should come into play?  Ans: Well, for beginners let's say this. Impediments, like large user stories, must be broken down into digestible chunks.  The (expected and actual) impact on velocity is key. Cost-benefits analysis is important. Sequencing is important (eg, for technical impediments).

10. How quickly do we want to benefits from work on impediments?  Ans: About every Sprint, at least.

11. Could the ordering of the impediment list change from day to day?  Ans: Yes. And often not every day, but on many days.  For many reasons.

12. Does the Team always identify the best impediments?  Ans: No.  At least, not without coaching, usually.  We recommend giving the Team a a challenge.  Say: "We need to double the velocity of the Team in 6 months, without anyone working more than 8 hours per day. Ever.  So, what do we need to change?"  If they see it as a reasonable challenge, they often get more creative.

13. Is a public impediment list useful?  Ans: Definitely!

14. Why is a public impediment list useful?  Ans: Many reasons. Here are my favorite three reasons.
a. By seeing everything on the list, Team members can know when it is useful to add things to the list.
b. By seeing the ordering, Team members can know when it is useful to give input on changing the priorities (and when it is only wasteful).
c. Everyone, including the SM himself (herself) knows what the SM is working on.  The top impediment!

When would I not want to do Scrum?

This is a slight variant on the question I asked before.

I wanted to add a few things that I did not say before.  You still might want to do a project despite some of the things I will mention, but I have gotten impatient as I have gotten older.

1. High priority. I want the work to be meaningful to the organization and/or the customers. And for the organization to be committed to it.
Seldom to I see a Team get work that has a very low priority.  But I do see lots of situations where the importance is not compelling enough compared to other things. And I see lots of organizations who
have not gotten the message about 'focus, prioritize, get the top thing done first'.

2. Want to do Scrum. I want 'the right people' to be generally willing to at least try Scrum. And some general willingness by the organization to fix the biggest impediments.
To start, a  willingness to 'give it a try' is good enough.  But I would also be looking for indicators that we can convince them to become truly positive as they start to see it in real life.

3. A real stable Team. To me, if the organization will not give us a real stable Team, things are highly suspect.  I am concerned they are not decided about their priorities. Or they are not decisive. I suppose I could understand certain real-life constraints, but too often I have seen what I have considered ... it just did not make sense to me.  The managers still had not understood how powerful the Team is; they were still too stuck in trying to optimize the so-called 'efficiency' of the skill sets.

As I suggested, in specific situations I might agree that the Team is as real and as stable as we can get.

So, if I did not get some fairly positive feelings in all 3 of those areas, I might not want to do Scrum. 
But I probably wouldn't want to do the work any other way, either.

When should you NOT use Scrum?

I was asked this question in a class recently.  (When should I not use Scrum?)  I gave an answer, but I want to give a better answer.

To be fair, it is a hard question. And a hard question for me.

My personal answer, which I gave, is that I only have been doing projects for 20+ years in lots of environments. I cannot think of a single project (product, effort) that I would not want to use lean-agile-scrum on (ie, use Scrum as the core).

Did I make projects work with waterfall, and have some success? Sure.  And I feel sure that we could have had much more success with Scrum.

***
Are there other types of work than what I have done?  Of course!

So, when would I not want to do Scrum?

I gave two examples.

1. If two people on the 7 person Team say "I hate Scrum", then I probably would not do Scrum with that Team.  Almost surely they will make it fail.  With that Team. (I might fire myself, though, and get on another Team.)

2. If they give you an impossible project (say 18 months of work that must be done in 12 months), and if you don't succeed they will fire you --- then, I recommend waterfall.

Management won't really know how the (waterfall) project is doing.  Just say: Green.  You will have plenty of time to work on your resume, post it on Monster.com (or CareerBuilder), have some interviews, and get a new job.  And it is important that you protect yourself and your family from these jerks (or this situation).

Some people laugh when I describe that situation, but you do seriously have to protect yourself.  And, as you are leaving, wave goodbye and tell them the project is RED.

***
But are there other cases?

A. If the Team is doing exactly the same project again, and you can accurately predict that no other significant change would happen, then maybe consider waterfall. 

B. If you have a completely dysfunctional Team, ...well, I wouldn't do Scrum or Waterfall or anything. Get yourself off the Team!

C. If you can't get anything like a real Team.  Not stable, no Team coherence....then maybe I don't want to use Scrum.  But I really think that knowledge creation in a Team is so key to all our work, so I want to go to 'management' and say 'You all are not committed to getting this done, so let's delay the project until you are committed and we can get a real Team.'

D. No one on the Team is 50% dedicated to the Team.  Then not Scrum.  But then, again, probably nothing else either.

E. People allocated 50%, but clearly no prospect of moving the allocation above 50%.  Umm, makes me question using Scrum. Or even doing the work.  Give us work where you do want to allocate people 100%.

F. Skill sets that are not 'overlapping' (eg, A-people can not help with the work of B-people).  And, in the time line, we need to do A-work early, and B-work later.  In light doses, we have this scenario to some degree every time.  In small doses.  But in this specific case, it is extreme.  In this case, there is no use in a cross-functional team.

I suppose one might use Scrum and a (small) Scrum Team to get the A work done, and then another Scrum Team to do the B-work.

But lots of questions.  One: if this is such a big impediment, why can't we fix it? 

***
You get some ideas.

Ultimately, it depends on common sense (as Ken Schwaber says).
And then he says: And common sense is very uncommon.

***
More later on other situations, and some ideas on the best conditions to start Scrum.

Creativity and Process

Here is a good quote:

Now I have to tell you something, and I mean this in the best and most inoffensive way possible: I don’t believe in process. In fact, when I interview a potential employee and he or she says that ‘it’s all about the process,’ I see that as a bad sign … The problem is that at a lot of big companies, process becomes a substitute for thinking. You’re encouraged to behave like a little gear in a complex machine. Frankly, it allows you to keep people who aren’t that smart, who aren’t that creative.  Elon Musk, founder of Space-X and Tesla Motors

One of the key aims of Scrum is to vastly simplify the process that you have.  The experience is that people need a bit of process.  That the sonnet form leads to greater creativity by poets.  They need a bit of structure.  But then any additional structure needs to be asked for.  Not imposed.

And this is just the way we think with Scrum.

We think Scrum provides just the bare minimum of process that actually increased creativity.

And, we think that, after that, as process is forced on a Team, is starts to reduce creativity.  The heavier, the greater the reduction.  Now, creativity isn't everything, but we think in the knowledge creation business, it is awfully important.  Perhaps the most important thing.

I saw the quote at an article discussing Six Sigma and Creativity.  That article is here.

The ScrumButt Test (3): Enabling Specifications

The third line in the ScrumButt Test is: "The Sprint starts with an Enabling Specification."

What does this mean?

The first practical goal was to eliminate the analysis paralysis and delay associated with waiting until the specification was "complete".

But, on the other hand, too many agile teams are trying to be effective when 'no one knows what we are supposed to build'.

What is wrong with the old waterfall process? (at least in my opinion):

• too much delay
• a pretense that further change (or learning) won't happen
• a magical belief that the customer can really fully understand a spec (I have seen it happen maybe once)
• a magical belief that "all the questions are answered by the spec", when we know that people learn much better in a face-to-face Q&A format

So, what are we advocating in Aglie (Scrum) to replace this broken process?

Well, it turns out to be a Goldilocks idea. We have some wish to make the team efficient and at the same time we know we are learning all the time. So, we advocate an Enabling Spec. Not too much, not too little; just right.

What does this mean?

Well, at a minimum it means that the business person involved (in simple terms, the Product Owner) at least thinks he understands the story (let me assume the team is using User Stories). And at least thinks he can answer all the questions. It is also a good practice for the Business Analyst (or someone) to write down a half-page or a page or two of diagrams or notes. In the course of doing that, she (the Business Analyst in this example) will ask the PO several questions, and find out that he doesn't have the answers yet, and so new learning will happen.

But the enabling spec is very short. Maybe a bunch of diagrams. The good stuff is not buried in wads of paper.

Who decides what the enabling spec looks like for a given team? The consumers. Primarily the coders, the testers and other team members who must use it. Different projects and different teams (and even different situations) may require somewhat different enabling specs.

Let me be clear. Scrum itself does not require an enabling spec.  But I (and Jeff Sutherland and others) are recommending an Enabling Spec as a best practice.

Scrum does say "improve your engineering practices" and I (and many others) would suggest that one improvement area would be around "requirements", and more specifically, one would be using Enabling Specs.

Be aware that some in Agile would advocate no written spec at the beginning of the Sprint. Nothing written; just have conversation in the Sprint. This has worked, although I think it typically is not optimal (ie, the team usually could have done more if they had used an Enabling Spec). While I agree with the importance of the conversation, face-to-face with Q&A, I also think the 1-5+ page Enabling Spec per Story is also helpful. As long as there is discussion between the writer and the readers about what in it was useful or in the way, or just missing (and needed to be written down). (Answer to a question: Yes, all the Enabling Specs developed so far could be in one document, if the team found that useful.)

I would suggest that about 5% of the team's total time in this iteration should be used to prepare for the next Sprint. This includes building and discussing (at a high level) the Enabling Specs for the next Sprint.

Remember that we are always learning. Just because something got put in an Enabling Spec does not mean it can't change (if we now know better). At the same time, an unprofessional attitude about learning ("oh, I'll just let myself learn about that later") is not allowed either. We are trying to learn as fast as we can. By putting all our minds together.

{Note: To find our previous posts on The ScrumButt Test, you might search on that term in the Blogger search box at the top of this page. We have 3 earlier posts.}

For Quick Decisions, Depend on Deadlines

In Saturday’s (8/2/2013) Wall Street Journal, Dan Ariely suggests that to reach a decision, and often just to make progress, you need deadlines.  Deadlines ‘force’ people to take action.

And this is what we have known with Scrum for years.  So, we have timeboxes all over the place (and recommend using them more than just where prescribed by the bare framework of Scrum).

Based on research, Ariely says:

Because deadlines allow us to clarify our thoughts and create an action plan. They are good at getting people to perform a particular act, like submitting a grant proposal.

We feel indecisive, uncertain, unsure, and so we ‘lose the name of action’ as Shakespeare said.  And the deadlines force us to act.  The timeboxes force us to act.

The first timebox in Scrum is the Sprint timebox. Say, 2 weeks, in which we must have working (tested) product.  It helps us get things done. Not just decided, but done.