Giving context

I am in Norfolk and the weather is foggy. And I am thinking about how best to do Release Planning. More specifically, how to plan for a big 2 year project where everyone is used to a waterfall approach.

So, here are some thoughts.

Our problem is like being lost at sea in a fog.  We need to get our bearings.

One metaphor is that we need to triangulate.

And, in our situation, we need not only the skipper or captain to understand our bearings.  We need everyone participating, eg, everyone on the team doing the estimating, to have their bearings.

Now, also imagine that we are doing this at scale, meaning, for example, with about 28 people in 4 release planning teams.  We have done a high-level overview of the 15 key high-level 'features'.

So, within and between features, how do we enable everyone on the team to get their bearings?  What are some good practices?

First let's understand the problem better.

One thing is to give them confidence that they basically understand the stories.  If they lack confidence, they get scared to estimate.  They slow down too much, and, if the stories are too vague, they should 'slow down'.  But at the start there is always some vagueness, so we must live with some of that.

As I say, 'if you wait for perfection, you might wait too long.'

One thing is that they need to understand the stories in multiple dimensions.  And in all the key dimensions that affect business value and effort (story points).

One thing is that they 'basically' understand the story, but they don't feel compelled to understand 'everything' about the story now.  They feel ok to discover much of the detail later.

So, we want context at the high level, including very high level process flows, business value, large epic relationships, etc.

We do NOT need context at the very low level. At the extreme, we would have to do the whole project to discover 'all' that detail.

But, we do also need some 'middle level' detail or context.  And each project or effort has to argue about how low is this middle level.

Part of the problem is sharing the explicit and tacit knowledge about what the customers and the firm want throughout the whole team. (i won't try to explain now why the whole team is so important.)

So, here are some suggestions about giving or sharing context.

1. Creating the stories as a whole team. Among other things, the whole team starts to own the stories.

2. Discussing the relative business value of each story as a team. Perhaps with business stakeholders.

3. Seeing all the stories on the wall, and discussing relationships or groupings of stories.

4. Good use of the 'role' in story writing.  Gaining clarity about each role.   Personalizing each role ('You saw Suzy; this is what she does.').

5. Better use of the 'so that' clause in the story line.

6. Reviewing the stories against the INVEST criteria. Are all the stories 'good enough' by these criteria?

7. More artfully sliced stories can be easier for everyone together to understand. This is a skill that the PO and the team get better at with time. Focusing on the INVEST criteria is a good place to start.

8. Middle level business process flows (middle compared to the big system). Maybe 'high' compared to the big feature.

9. More high level acceptance criteria per story.  Eg, 1-4 acceptance criteria bullets. Not necessarily for every story, but maybe just for some of them.

10. Pictures of interrelationships between modules of the big system.
'That info will be here, and we use it there.'

11. Pictures of interrelationships between 'layers' of the system or 'features' or what role 'x' wants.

11. Seeing how stories are grouped, or how they were broken down. 'we had this big epic, and we broke it down into these smaller stories.'

12. Understanding 'what role x is really trying to accomplish here' can be very useful.

13. Reviewing the relative business value of each story.  Business value is not just what customers want, but also what the firm needs (eg, lower risk or more revenue).

14. Pictures, pictures, pictures.  Drawings, drawings.  Discuss them. Again. Use the white board.

15. 'It is not what I know as the PO or BA; it's what the whole team knows that matters.'

16. Some sense of the relative complexity of the business rules in stories.

17. Some sense of the relative number of data attributes (or whatever phrase you prefer) in a story.

18. Some sense of where this story ends and these other related stories begin.

19. Using Planning Poker to determine how much more context is needed.  If they have some context and then vote, and the votes are close or quickly become close, then probably no more context is needed.

20. Communication.  Doing something, and then asking everyone 'how can we do this better given our situation?'  This includes our work, our people, and what information is already available.  Often they will end up with something that we meant above, but they want to use different words to express it.  Which is of course fine.

Final note (for now): different teams get 'stuck' at different points.  This is normal and not a big problem.  Unless they can't get themselves 'unstuck'.

Agile & Religion - 1

I heard recently someone comment: "Well, watch out for those guys who get too religious about Agile. We don't want that around here."

This general topic gets talked about in the Agile community a lot. And, I think, often ineffectively.

But I think it is a difficult topic. It is hard to explain the issues around this well.

So, I will try to do several posts with specific examples and situations.

The first thing to say is that lean-agile-scrum is mainly about results. Results for the individual, the team, and the customers. Results such as: better products, higher quality, more fun, better work.

It is not about doing Scrum just for the sake of doing it. As though purity of Scrum, alone, were a high value.

It is important to say that virtually all the people who are experienced with lean-agile-scrum are concerned that they see too many people doing it "weakly". Schwaber talks about 'flaccid Scrum'. The XP guys talk about how Scrummers don't have strong engineering practices. Others talk about ScrumBut (or ScrumButt). And there are other phrases.

What is important is that they have a sense that playing Scrum 'weakly' means that the people are getting FAR less of the value than they deserve.

In summary for now: lean-agile-scrum is not about religion or belief or faith. It is about reality and testing and real results. That seems to me to be pretty far from 'religion' as most people use that word (when they use it as a put-down).

The next thing to say is: when a Scrum advocate talks about doing Scrum better, we should talk more about WHY 'better Scrum' means a better life or better results. More on this in the next post.

Scrum and Release Planning

I went to the Agile Ottawa group last night. Mostly I very much enjoyed the meeting. A lot of smart people, a lot of good discussions. But...

A Sad Tale

A gentleman there, a serious business guy, new to Scrum, said something like this: "It seems to me that Scrum has no up-front planning. And for those of us in the business world who must give some up-front estimate of time and dollars, this is not going to work for us. Does Scrum have some up-front planning?"

Several people answered. And I gave an answer: YES it does have up-front 'Release Planning.' Scrum does normally include up-front planning. This is somewhat controversial in Agile, but we have it. It is called Release Planning.

And I went on to say some of the things I say below. But my comments were brief, and it seemed to me they were drowned out by Agilists saying "why do you want to do up-front planning?" (and similar comments)...which is a good question, but again, it likely implied to the gentleman that all we 'scrummers' hate up-front planning. Perhaps I am wrong, but it seemed to me that he heard 'Scrum does not do much Release Planning'.

I discussed this with a person in my CSM class the next day. His comment was "yes, based on the stuff I have read [and he had read several things] Scrum does not say much about the up-front planning. I can totally see how that person had that impression."

To me this is very unfortunate.

[Aside: I call this a sad tale, with my tongue somewhat in my cheek. These are relatively normal human misunderstandings. Perhaps a bit sad, but nothing to compare to the sadness in Libya right now.]

Let me now make two references.

In the Scrum Guide (located here, among other places), Release Planning and a Release Planning Meeting are specifically mentioned and discussed.

In "Agile Project Management with Scrum" by Ken Schwaber there are only two mentions of Release Planning (according to my Kindle) in the book. Both not favorable (really about bad release planning). So, one can see why some people might get a wrong impression from that book. And some other sources as well.

What's Wrong With Up-Front Planning

Now, let me guess why Ken Schwaber minimized the mention of Release Planning in the book mentioned above. First, Schwaber and Sutherland note in the Scrum Guide that a lot of the details about how to do Release Planning are outside the purview of Scrum. Meaning: Scrum is a framework only, and as such, it is probably not useful or necessary for Scrum to give guidance on this that could be seen as Scrum's "answer" for everyone. Starting to do that risks making Scrum too big to implement in one step, relatively quickly. And risks giving great advice (for one effort) inappropriately to another effort or situation.

To me, these are quite reasonable concerns, and I think it stretches the point, though, to be so quiet about Release Planning more generally. And, indeed, the Scrum Guide, short as it is, does give a fair amount of guidance on Release Planning.

Another hypothesis I have is that Schwaber was concerned at the time he wrote that book that he was seeing too much Release Planning in 'scrum' implementations that looked too much like waterfall release planning. (I think I have seen this some too, although perhaps not as much.)

So, what's wrong with that?

Well, first, the customer sees no value in Release Planning per se. It is, to use lean terms, at most a 'necessary' waste. So, we want it to be as short as possible (but not shorter).

Second, too often people think the main (only) value from the initial release plan is the initial date and budget. Usually, as indicated above, that initial date and budget are necessary information to make some initial basic decisions. Maybe even accurate information if there were to be no changes. But anyone with much experience with projects has a near 100% experience of changes to projects after the initial Release Planning. Usually quite a number of changes and quite significant. In which case, the initial date and budget quickly become moot (in terms of accuracy; possibly still "directionally" useful, if you have a firm that thinks in those terms).

Third, often the initial Release Planning date and budget are used to drive people on Death Marches. This is an horrendous and utterly scandalous thing in our industry. It is shameful that we let stupid managers use this information this way, but that's the way it often happens. And unfortunately, this gives Release Planning a bad name too.

And partly because of this, many coaches recommend that Release Planning not be done until the Team has established a real velocity. (To me, for reasons I will not explain here, this is the wrong solution to a very real problem.)

Fourth, because of the rapidity of change in many areas, many agile people feel that the YAGNI (You Ain't Gonna Need It) principle means that up-front planning should be minimized. Very minimized. Often these people are from business situations where keeping Release Planning quite minimal will actually work. But, in my professional opinion, other business situations actually greatly benefit from some up-front planning....so long as everyone uses the plan (and all its refactorings) to drive good behavior (such as minimizing the stories that get in the real "minimum marketable feature set" of the next release).

I guess we need to be concrete here, to avoid silly discussions. I won't give all the parameters here (and, to be more accurate, one should), but let me ballpark and say that a typical 3 month release for a Scrum team can probably be planned usefully using agile methods (Release Planning) in about 3 days or less. Not a half-day, but again, not 2 weeks or a whole week either. Again, there are potentially a host of possible factors; these are fairly typical real-life situations I have in mind.

What's Right About Release Planning

OK. So we acknowledge that there are 'issues' with up-front planning. (And more than we said above.) These are not issues that either Scrum or waterfall create, but issues nonetheless.

Now, let's look at some of the positives.

A. Businesses need some way of comparing efforts, to decide which efforts should get started, and which should not start. Exact or even somewhat 'accurate' numbers are not essential here...just some rough sense of date/budget and level of accuracy. In virtually all businesses that I work with, this is (or should be, in my professional judgment) a requirement.

B. The team needs to start to see, at a middle level, the interrelationship of the benefits and costs of the work (features) it will be building. To make many other decisions (architecture decisions, among them). Again, rough numbers are sufficient usually. And even very rough numbers are better than nothing. Release Planning provides this information.

C. A sense of the rough time trade-offs is needed. Customers always want features immediately. When the initial conception of the first release looks, as an example, a long way off, it forces the mind into innovative solutions about how to scope down the first release. Release Planning can give the team enough information to start being innovative this way.

D. I think the biggest value of the initial Release Planning is that the whole team starts to see the same elephant. The same effort. In multiple dimensions. The stories (functionality), the business value (at a story level), the effort (at a story level), the risks and dependencies, etc. This is extremely valuable and, in my experience, the level of 'same-page-ness' is so very much better than what I always did in waterfall planning (and what I still hear). Again, extremely valuable, even though it will change.

E. Re-Planning. The initial Release Plan sets up a base from which re-planning canbe done easily. Each Sprint. I like to call this Release Plan Refactoring (and sometimes we use other names for it, such as: Product Backlog Grooming, Product Backlog Refactoring, etc, etc.).

Re-planning, as Eisenhower implied, is essential. The way I will put it (maybe mixing some metaphors) is: We have to use Pareto to deliver just the most essential stuff so the customer gets the coffee while it's still hot. A continual daily-hourly fight to see that most essential stuff. Mark Denne's "Software By Numbers" talks more about why it is so essential to release a "minimum marketable feature set." A great phrase.

Let me emphasize that in Scrum, we are always doing "Release Plan Refactoring" every Sprint. It includes re-planning in multiple ways, such as: adding new stories, using a new known velocity of the team, refactoring the story points on a few badly estimated stories, adjusting some business value points, slicing rising epics into smaller stories, etc, etc.

Having mentioned all these things: Scrum does not define these activities. Again, Scrum is a framework only. I have given you what I see and teach and advise for almost all situations. (And other people whom I respect also concur with these.) But the activities just mentioned are not defined in the Scrum framework. Scrum only defines a 'short' release planning, and then release plan refactoring (although the Scrum literature does not use a consistent term for release plan refactoring).

E. The final value is motivation. The team no longer feeling like they are getting the mushroom treatment. They see the 'big picture' at a more meaningful and richer middle-level. The team feels like they are respected. They see themselves as adults making an adult, well-considered commitment to build that product. This motivational impact is quite important. And is not affected by the inevitable changes much.

***

More to say, but enough for now. For those interested, see our earlier posts on Release Planning. And future ones.

Additional ideas: adopting lean-agile

This topic is being discussed here. And many places. I think I will be discussing it with a senior executive in Canada on Monday. So, very pertinent for me. And likely many others.

A lot of smart people in that discussion (I know some of them personally). A number of great ideas were mentioned by these people in that discussion, and I wanted to summarize them and react to them.

1. My advice might differ greatly if I understood Mark's specific situation better -- really, if I understood it at all. So, my comments in the prior post are based on what I find is the typical situation.

2. As discussed here earlier, asking people to do something (Scrum) that they really do not (yet) feel an interest in doing, is not a recipe for success. So, typically, one must influence them to want to do Scrum. Usually a fair amount of work itself.

3. To re-phrase Steven "Doc" List's main point (I think fairly): In Scrum terms, it is always in my experience useful to do a decent Release Planning with the whole team. (We do this in the Workshop, although not always with enough time to do it 'well enough for now'. So, it may need some further work before Sprinting starts.) To me, the biggest advantage in this is that it gets the team all on what page: what is this effort all about.

In Scrum, we refactor the Release Plan every Sprint (to some degree).

4. As Eric L said: Bringing in an external person (or people) is valuable. This is one of the patterns in Fearless Change by Manns and Rising. (In fact, get that book. And do all the patterns in it. Repeatedly.) The external person can do training, coaching, a speech...many different things.

5. I know people at Rally Dev and at Thoughtworks. All the people I know are good (although not all equal). Each brings 'their thing' to the table.

6. Jay C. mentions being prescriptive. There is a paper that Jeff Sutherland contributed to called Shock Therapy, which describes an approach to this. While it is risky in some ways, I think it can be very successful to be prescriptive about what Scrum is (for a period of time). Not prescriptive about how they do their 'real work', but about Scrum.

7. Jay C. also mentions being value centered, about which I strongly agree. I start this in Release Planning. My fuller approach I call Business Value Engineering, where I steal ideas from Scrum and Lean to incrementally improve the approach to delivering higher business value. As one very small example, from the beginning I advocate Priority Poker, which is much like Planning Poker, only done with the top 5 guys and about Business Value.

8. Bob M. mentions the idea of doing agile-scrum outside of just the software building part of the overall business process. I concur. It often would actually be more valuable elsewhere. The question is how and when. Sometimes useful to demonstrate that agile-scrum is successful here (sw dev), and then expand it out.

9. Matthew H. mentions an analysis of the organization: what's working and what's not. I would definitely do one initially. (Maybe an hour or two.) I would say the key is: prioritize your battles (if you like the war metaphor). Scrum by the way can be said mainly to be a way of seeing your problems more clearly --- then it takes the guts to actually act on that new information.

10. Matthew H. talks about understanding the leadership team. This is often a key part of the organization, and analyzing and getting an action plan around leveraging their strengths and mitigating their weaknesses can be very useful. This has to be done in a timebox. Everything does not depend on these people. The most important person is really the 'agile advocate' (typically, that is you). Again, see Fearless Change by Manns and Rising.

11. Daniel G. gives a link to a very nice list of the basics of Scrum. This is a useful thing to use, particularly with more than one team, so there starts to be a good discussion around "why aren't we all doing the basics of Scrum?" Other uses too, of course.

12. Robyn D. gives some great advice about how to set up the first team at the very beginning. Get a good set of work, do some release planning, get them to collaborate, etc. Being realistic about the 'quality' of the first few sprints is very good advice. My advice (prior post) took a somewhat longer term time frame.

13. Robyn D. mentions XP practices (TDD, CI). Concur. I would implement the fixes to the biggest impediments first. Usually the value in doing these XP practices should be either: faster velocity (at sustainable pace) or reduced technical debt, or both. But, sometimes these XP practices are a great hammer, but we are not quite ready to get to the nails yet. If see what I am suggesting. Anything can be the biggest impediment; fix the biggest one first.

14. Matthew H. mentions 'silver bullets and ideology'. Umm. This is hard to explain well. On the one hand, "it depends on common sense" is always useful advice. One the other hand, common-sense is not that common. Then we observe: There is a lot of Scrum-But out there. And usually we find people acquiescing to it, with no good long-term reason (often the initial short-term compromise was quite sensible).

We do find people in agile whom I would characterize as impractical or too impatient about the initial implementation. They want a team to do all of Scrum and all of XP on day one. For example. So, being impractical in this way about existing impediments on day one seems to me wrong.

We do find people in agile who say or imply 'do Scrum [or XP or whatever] and all will be well'. Let's be clear. Scrum cannot guarantee success. Example: If you have a great team at American football, and you ask them to play soccer, they will fail at that against a world cup level soccer team. But (back to our regular situation) if the team is not sufficiently competent for the work they have been given, Scrum will enable you to see that impending failure sooner.

On the other hand, as I suggested earlier, typically we think people should be very aggressive about removing impediments (within the rule that 'a dead ScrumMaster is a useless ScrumMaster'). And we also find in very many scrum implementations a lack of aggressiveness about removing the impediments (eg, the Scrum-Buts that we had to start with). So, we need some 'fire in the belly' about eventually getting to 'better Scrum' (and better lean-agile-scrum more broadly).

Our overly simplistic motto for the right attitude is from lean: 'The relentless pursuit of perfection.' Meaning: We accept that we are imperfect. We define a 'better state' and we relentless pursue that until we are close enough to see that we can define a yet higher state of 'perfection'. In other words, we relentless pursue getting better, without the illusion that we will ever become truly perfect.

Wow, that balance between being practical and being idealistic is hard to explain. I hope you could get the idea-action that I meant.

I hope you found one or two of the ideas here actionable in the short-term. (It is important to think and then act, in a tight cycle.)

Comments or further comments welcome.

How do we start agile/scrum?

In the Agile Alliance LinkedIn group discussions, there is a discussion about 'how to adopt agile in my organization?' by Mark Lummus. This is a complex topic, with many things to say. Here is most of my first post (in that group) about this. There are many other things I might have said.

QUOTE
Mark,
Here are my opinions on this (based on much experience). And I am talking not so much to you (you probably have the experience to consider some of my remarks as obvious) as to a broader audience.

First: I think really doing lean-agile-scrum well requires lots of things. But I think I am agreeing with you to say: Start the change with Scrum.

Second: Go high and go low. Meaning: Get senior guys in support and get people in the teams to support.

2b: You need to build a team (or each one needs to be a real team), and it needs to be a team with a winning spirit. Scrum helps with this, but there are many other factors that contribute.

Third: Use some metrics to show that you are making progress. Do not let them insist on perfect metrics (never exist) and make sure people use common-sense in interpreting the metrics (common-sense is not so common).

Fourth: Being aggressive about removing impediments is key. In the team, by the ScrumMaster, by the managers. Hard to predict from afar where your biggest impediments will lie: people, rigor in doing Scrum (too much ScrumBut), engineering practices (see XP!), the flow of business info into the team (eg, weak PO), or what.

Fifth: Build off the success of the team(s). To me, success is more business success (as in: the customer is really happy) rather than technical success (we did what we said we would do X months ago). I don't know what you all do today, but I can just about guarantee, after 3 Sprints, some degree of relative success. Build on that.

Fifth: The 'change management' around good lean-agile-scrum is quite significant. It is never-ending. People think they understand lean-agile-scrum, but I think the paradigm shift is actually hard. Typically firms need coaching for the teams (and surrounding managers). We have seen a team have a full-time coach for 2 months. And I have seen a team get a coach for 3 days out of each 2-week Sprint, for a bunch of Sprints. Almost always, when I see a firm that chooses not to get coaching, it smells to me like being 'penny wise and pound foolish'. But I am sure there are also some cases of strong success without coaching...just not often, percentage-wise. (I am a coach; you might call me biased.)

Sixth: Technical debt and better technical practices will be very important, sooner or later. Start attacking them soon.

True success with Scrum should be measured as 5x-10x better than your current baseline. Some firms do this quite well and often, but most never get there. Far, far too many settle for minor success (eg, a 50% improvement). I think the secret sauce is not so much the practices of Scrum (the dance steps), but rather more people 'getting' the underlying values and principles (the music). The dance steps become truly powerful when in sync with the music. Without the values and principles, a 'daily scrum', for example, can be almost a waste of time.

What would others put as the top 6 or 7 things for 'Mark' to consider?

UNQUOTE

More on this topic in a bit.

What we do...

Here is an interesting post by Daniel Glyde, about what his team does at wiggle.co.uk

Scrum, and....

http://danielglyde.blogspot.com/2011/03/agile-software-development.html

Implementing Scrum when not everyone is a believer

How do you implement Scrum in an organization where not everyone is a believer?

Umm. This is a common question and a hard one. And yet also easy.

First, one misconception is that Scrum is a religion that only true believers practice. Scrum is actually empirical. Now, it should be said that Scrum (and lean-agile-scrum) has ideas that are on the surface counter-intuitive, perhaps we might even call them paradoxical. Example: "You have to go slow to go fast."

(I hope you will smile to see the picture of the waterfall model true believer.)

But mainly, we want everyone practicing Scrum to do so out of free will, and with an appreciation that it can and will produce a better result. And, if, after giving it a fair trial, it does not produce a better result, then you should examine the root causes. It just might be that the root cause is that Scrum is 'wrong for us'. Scrum is empirical. We live with reality; we face the truth.

Let me be honest. I do think there are some people in a few of the Myers-Briggs categories who should not be doing Scrum. Because it has too much relative 'chaos' for their personality type....but indeed, for that personality type, there is in reality too much chaos in new product development in general. They also should not be doing new product development.

Still, for most people, if 'scrum' seems to fail, I have never been convinced that it was really Scrum that failed. Typically, at least in my opinion based on what I knew, they did not do it well enough, fully enough or professionally enough. So, it was not truly Scrum that failed. But I might be wrong; I certainly have a limited data set; I have not seen anything close to every Scrum implementation.

Next: Most people who start Scrum are not really all that familiar with lean-agile-scrum ideas when they start Scrum. So, we are asking them to willingly suspend disbelief for some trial period. They are welcome to remain skeptical in a sense, but should make every effort to give it a fair trial. And they will do it 'ugly', as any beginner will. What is quite remarkable, in fact very very remarkable, is that even after only three 2-week Sprints, the Scrum that the beginning team plays is already better than what they were doing before (which they had practiced and used for some years, typically). This is really extraordinary!

Let me emphasize this again, another way. Many of the ideas of lean-agile-scrum are counter-intuitive and for many people will appear to be 'wrong' in many common situations. It is only with experience that the ideas will start to be regularly obvious and intuitive. This is not because the ideas are wrong, but simply because our minds are so used to (wrongly) another paradigm of looking at our work.

Now, sometimes, especially if they feel forced to do Scrum, the team cannot help but sabotage it. They can indeed, in my opinion, make it fail.

So, before the trial project, we should make reasonable efforts to get them to a place where they can give it a fair trial. And feel somewhat comfortable doing so. (Change is always somewhat uncomfortable, so expecting every team to start with 'excitement' is not realistic.)

Some suggestions in this area:

1. Give them training. Example: A Scrum course.

2. Give them a workshop. Example: To do release planning and sprint planning as a team.

3. Give them coaching. Example: Coaching for 3 consecutive days at the beginning of the first Sprint. And then 3 more days at the end of the first Sprint and the beginning of the 2nd Sprint.

4. Talk to them about lean-agile-scrum principles, so they start to understand the music behind the Scrum dance steps. Reinforce this as they experience 'issues' in the real-world implementation of Scrum. ("Talk" can include books and articles.)

5. Do not expect that they will fully understand it immediately. (Did you fully understand baseball when you first started playing it?) Expect them to forget even some of the basics that you told them or they were taught. All lessons, for all humans, must be repeated. The best we can say for people good at change is that we need fewer repetitions of the basic lessons. And do not expect all your people to be good at change. (That does not mean that they will be bad team members....They are good at other things, just not good at change.)

6. Do not let them feel Scrum is the idea of one person. It is not owned by you. It is not 'owned' by one trainer. It is not just Jeff Sutherland's or Ken Schwaber's idea. Many, many, many people have contributed to the idea set. Many, many, many different teams have used it with success. In almost every conceivable environment.

7. Find out what they might propose instead of Scrum. If it is waterfall, help them to understand that even the key people who originally advocated waterfall (the US DOD and Dr. Royce, for example) no longer do so. (In the case of Dr, Royce, his son no longer advocates waterfall.)

8. There are lots and lots of techniques and an endless list of specific things you can do to influence people. See, for example, Fearless Change by Manns and Rising. The list is indeed endless; you never run out of more things you can do. You might exhaust you own patience to continue trying to change someone who seems completely unwilling to change.

9. Remember this famous adage: "People do not resist change. They resist being changed." One meaning: Be sure your 'target' does not feel you have to change him. He should feel as though you are helpfully, fairmindedly sharing ideas that might actually help him in his own life (as he values things in his life).

10. Remember to go with the flow. In Hapkido (martial arts), if the opponent resists going one way, then we use their counter-energy to flip them the other way. There is always a way you can use their energy against them. Assuming you are aligned with the source of energy and truth. Laughter is one of those paradoxically powerful forces.

Remain positive, realistic and undaunted. You are indeed helping the world be better; yet you know it will never be perfect. Be patient with those whose eagerness to change is less than yours. As Yogi Berra said: If the world were perfect, it wouldn't be.

Scrum, Sprint Zero (NO), and Prototyping

I was talking with some smart people at a client. They said: "We do a Sprint -1 where we do rapid prototyping. We do a Sprint every day, produce a new version of the GUI, etc and review it with the customer team daily. It lasts for 2 weeks, or did last time. It is mainly visuals to help us in discussions with the customer about what they really want. Generally low fidelity, generally throw-away code (to the degree it is coded)."

I am, perhaps slightly famously, against the Sprint Zero concept. I will describe that more fully elsewhere. But the basic idea is that I don't like a Sprint that results in no working software. More generally, I don't like a Sprint Zero because it includes (mostly/only) work about which the team can get no objective feedback from someone useful...did it contribute toward what the customers really want?

So, it is mainly the lack of real feedback that troubles me.

So, how does the situation presented by this client compare to this?

To me, the client is doing an excellent job, at least so far as we can tell from the conversation, in trying hard to understand what the customer really wants. In general, I find abstract conversations with customers are of low value, while conversations that include visuals, and include, where relevant, some work flow, can be much much more useful. This seems to be the case.

That they produce some 'working product' DAILY that can be usefully discussed with the customer to get feedback seems excellent. Yes, this working product is not working software as we typically have in a Sprint in Scrum. But this seems far less important in this case than that they are increasing and tightening the feedback loop with the client.

That they call the 1 or 2 week effort Sprint -1 does not thrill me, honestly. It suggests to others that a Sprint Zero concept is ok, even good. That someone speaks of doing a daily 'sprint' within the Sprint -1...well, as an English major I want to quibble about word usage. (Minor really.)

That the prototypes are throw-away does not seem, on the surface, ideal. But maybe quite appropriate.

To me, the main thing is that they are increasing rather than decreasing the feedback. And tightening (speeding up) the feedback loop. This has to be good.

What is less clear (at least from that conversation) is how well the feedback is happening through the rest of the delivery effort. Perhaps more on that later.

Net, net: Some people feel that every accommodation made between Scrum and reality is necessarily not doing Scrum 'right'...although maybe still the right thing to do. It is true that too many people are subtracting from Scrum (which we tend to call 'ScrumBut'). And in almost every case we find that to be....not good for them, really.

But adding to Scrum, and I want to call the above usage of 'Sprint -1' an addition, adding to Scrum is, in general, necessary and typically a good thing. Yes, a Sprint Zero (as described above) would be a bad addition, in our view, but in general additions to Scrum are necessary and useful.

The key is: are the additions made in the context of lean-agile-scrum values and principles. Such as, the principle of increasing the feedback so that the bad news does not get better with age.

Sometimes, two or more lean-agile-scrum principles will come into conflict in a specific case. Then the question is which principle should have precedence.