Public Impediment List !!! – 2

Posted on December 21, 2011 by Joe Little

There is a good Scrum trainer who thinks that a public impediment list is not important. So, if he can mis-understand, then we all can. See here is a yet better explanation. I hope.

****

I find that the lack of a public impediment list is a prime indicator of a lack of focus on removing impediments.

This is essential in Scrum. Why?

Well, first it is important to say that the public impediment list is not the main deal. The list must be acted on. But, like 12 lawyers at the bottom of the ocean, it is a good start.

The real deal is removing impediments, and making the lives of yourself, your team and your customers better. And the impediment list is one way to do that. Or, better to say: fixing impediments is one way to do that. And the impediment list (public) helps you do it better.

Why have a list? Well, we believe in doing one thing at a time, and getting relatively quicker results from that. Rather than working on many things and usually not making any tangible progress.

So, the list enables the team and the firm to order the work on the impediments.

How? Well, first an impediment is anything, anything slowing the team down. Or, if fixed, would speed the team up. (Speed meaning both higher quality and higher productivity.) The team gets greater benefits sooner by working on the top priority impediment.

But we forgot to mention that the first one might be the one that gives us the greatest bang of the buck, meaning “business value” divided by effort. (Business value for impediments might, too simply, be thought of as the velocity increase for the team.)

So, we can always be working on the top item on the list.

And, by the way, every team has not reached anything close to optimal velocity, so there is always a top impediment. In fact, always a list.

Why public? Well, so everyone can see and offer feedback on what are our team’s biggest impediments. Otherwise, Brian thinks he told George about Item X, but George forgot to put it on his personal list….so, it was forgotten. All these little human errors are less likely with a public list.

And we mean everyone. People in the team and people outside the team. And including the higher level Impediment Removal Team (IRT). Anyway can make suggestions, and help us get better. [I call it IRT. Ken Schwaber and Mike Cohn and others have their own names for it. I assume you are in a company with 4 or more Scrum teams, where an IRT starts to make sense.]

A public list reminds everyone that someone should be working on the top item, well, and that would be today! “Has anyone started?” “Oh, yeah, I’m about to start that!” Human nature again.

And a pubic list enables Mary… who was sure her Item B should be number one, but shows as number 10 now…. identify the problem. So, now she knows to go to George the ScrumMaster and make the case why her Item B should really be #1 on the list. Otherwise, she might just guess that George “got it” after their hallway conversation (where he actually was thinking about the Christmas presents he needs to get).

****

The list is prioritized. If the priorities are not obvious, then the ScrumMaster breaks ties.

And the real juice is that the SM is making sure the top impediment is always getting worked. And indeed someone is fixing one almost daily.

Again, there never comes a day when there is not a top impediment. (We never become perfect.)

Now, it may also be that the public impediment list reminds the SM (and everyone else around) why the heck we have an expensive person (the SM) over here *not* doing “real work.” (By the way, I think the SM easily pays for himself by removing impediments. But you do the math. Of course, that assumes that the company culture does not stifle all the impediment removal efforts — which has been known to happen.)

For you all into Lean, a public impediment list relates to Visual Management and to Kaizen. Two big practices (or ideas) in the Lean community.

The exclamation marks in the title are there to suggest that way too often we find teams without a public impediment list.

Finally, let me recommend a public list of impediments already fixed. How quickly we forget our successes. Oh, yeah, that’s why we have the stupid ScrumMaster around….

Your thoughts?

Why call it "BV Engineering?"

Posted on November 29, 2011 by Joe Little

A man I greatly respect wrote to question why I call it “BV Engineering.” There are many engineering disciplines, he noted, but is there a degree in “business value engineering”?

I said I thought an MBA was the degree to get for this. Not another regular engineering degree. But I agree with him that for some the name is mis-leading

But this begs the question. Why do I call it “BV Engineering?” Those of you who have taken one of my courses will of course know.

Those of you taking the BV Engineering workshop in Ottawa on Dec 8-9 will also learn (again) why. And more.

But why? Two reasons.

First, Scrum is a framework, and purposefully does not attempt to define the engineering practices that the team should use in building the product. Scrum assumes that these engineering practices are not perfect. And assumes that the imperfections will show up in the Impediments List. And, when an impediment rises to the top, it will be fixed.

So, I want all the stuff around Business Value to be treated the same way. All the ideas, all the people, all the tools, all the process. It needs to be continuously improved. And items need to go on the Impediments List. And then get fixed! So, I want BV Engineering to be amongst the engineering practices we are continuously improving.

Second, I have colleagues that have some wonderful ideas about Business Value. Good, big concepts. Or other ideas.

And I want that to be wedded to rigor (or at least more rigor), discipline, and metrics. Yes, metrics around BV are hard. And? This is the only really important thing we do — deliver business value — so I think we should have some metrics. And be continuously questioning how good the metrics are. This is what they do in physics. And so should we in business.

To me, ‘engineering’ implies rigor, discipline, and metrics.

So, apologies if the phrase otherwise does not work for you.

***
To see other posts about BV Engineering, just click on that label to the right.

Scrum & Kanban

Posted on November 21, 2011 by Joe Little

Jim Coplein today posted a very interesting post on Jeff Sutherland’s Scrum Log. It’s title is: An Alternative to Kanban: One-Piece Continuous Flow.

In the piece Jim discusses the definitions and merits of Scrum and Kanban.

This is a subject about which I too have some feelings. Not feeling as talkative as Jim, I will summarize them. This will allow greater room for mis-interpretation, and therefore for greater learning. (smile)

1. Let’s get more results. I am getting to the point where I don’t care if we use Scrum, XP, Kanban, scotch tape, or Granma Berthe’s Bible. What we use or what we call it means less and less to me.

Show me the smiling faces. Show me how it helped you or your team or your customers. In real life. The results are what matter. The gods who spoke to Jeff and Ken and the scrum community knew this well.

I better add: I still think Scrum is the place to start, and I don’t believe in Scrum-But. But this subject is another 10 blog posts.

2. Lean bias. I look at Scrum and Kanban as parts of Lean. And I like them all.

3. Scrum. I think it is an excellent start. About as much as one team can change in a short period of time. And, yes, while it is simple, it takes years to become a master.

But Scrum is only a framework, and while the team should not subtract from Scrum, stuff must be added to Scrum. Actually quite a lot of stuff, in my opinion.

Scrum’s ‘incompleteness’ is not a defect but a virtue.

4. Kanban. The cards in Lean were stolen from Piggly Wiggly (the grocery store). Which pleases me, since I have been to some of their stores, I like them, and my kids have “I’m Big on the Pig” t-shirts from Piggly Wiggley.

Kanban is one of several tools in Lean. Kanban may be classed with several Lean practices or tools under a group called “Visual Management.”

Kanban in Lean first refers to the sign-cards stolen from Piggly Wiggly. And of course to all the ‘usage’ around that. Kanban has many purposes in Lean manufacturing. Reduce and manage inventory. Set up a pull system. Enable flow. Enable single-piece flow. Provide some indicator of stoppages in flow.

It is important to note that Lean uses many other things in addition to the Kanban cards to attain all the goals mentioned above.

5. “Kanban”. This is becoming an alternative software development ‘framework’.

It has various definitions. And there are of course now many implementations. Many of which would no doubt be called “Kanban-but…” by some of the “Kanban” people.

Many good and smart people like the idea, and so no doubt it does some good.

In Lean manufacturing, the Kanban cards represent things of the same ‘size’. In “Kanban”, the cards represent User Stories, but so far as I can tell, there is not a strong discipline yet to keep the User Stories of the same size. To me, this is a meaningful problem. (Long discussion as to why.)

Related to the size problem, “Kanban” has no metrics. Thus, it is hard to demonstrate this way that it is successful. (Yes, it is true that measuring success is difficult in almost every case.)

So, how much benefit “Kanban” provides compared to and separate from Scrum is hard to say. Objectively.

5. Engagement with Business/Management. It seems pretty clear to me that Kanban tends to be used when engagement with the business side and/or management is not wanted or not possible.

Clearly, to me at least, this lack of engagement is not a good thing. However, if it is not possible (for now), then perhaps it….is not possible for now.

Still, we tend to believe that Scrum, with for example the Sprint Planning Meeting and the Sprint Review (demo), and with Release Planning and Release Plan Refactoring (technically not a part of the core of Scrum)…Scrum with these things tends to build trust between the Business side and the Technology side. Admittedly, often they start in a state of mutual distrust. Sometimes severe. But these practices, if done well, smooth out the distrust and build trust.

6. Our recommendation: Scrum first, then add Kanban.

Some will note that this is similar to ScrumBan.

We think that Scrum is plenty to implement on Day 1. And the Scrum Board, which comes ‘out of the box’ with Scrum, is already a very basic Kanban board.

We recommend that later, after the have Scrum working decently, the team use the ideas from “Kanban” and Lean to modify the Scrum Board into a specific Kanban board that reflects their work. To us, the focus should include:

Minimize WIP (work in process)
Do not over-stress the system (a basic principle that deserves 15 blog posts)
Single-piece flow
Aggressively identify and remove impediments (eg, stoppages in flow)

Kanban or “Kanban” should not be used to reduce contact with the Business or Management or the Customers. Rather the opposite.

Kanban and flow should not become a fetish. (Nor should Scrum purity be a fetish, for that matter.) There are good reasons to “stop” and do a Sprint Planning Meeting and a Sprint Review (demo), for example. And to do a Daily Scrum.

If developers (coders and testers) still evince a preference for “Kanban” after these issues are discussed and explained, management needs to consider carefully the root causes. Humans (developers and managers) are of course complex, and many things could be at play. But our first guess is that management is not aware enough how important it is for the team to have more fun when playing Scrum.

Fun is actually quite key to more creativity. Which, in our kind of work, is key to higher productivity.

Scrum teams and our Mammalian nature

Posted on October 24, 2011 by Joe Little

My experience with people doing Scrum is that we tend to take the “man is rational and isolated” hypothesis to easily. Often it is not a thoughtful choice, just the implicit assumption of the way we are thinking or the way we speak.

Isolated and individualistic are key words. If you believed in them, you would build cube farms for people to work in. For example.

Is there another hypothesis? Turns our there might be several, but one is that humans are fundamentally like all ‘pack’ mammals. We work and have worked, over thousands of years, in small teams, and these teams support the members inside the team. We have a limbic brain or limbic system that supports the huge emotional and ‘social processing’ needs of pack living.

Here is an article on the limbic system.
http://en.wikipedia.org/wiki/Limbic_system
(As you will start to see, the spiritual, physical and thought-memory processing aspects of the brain are quite complex, largely sub-conscious, and quite fascinating. And there is much for us still to learn, IMO.)

How does Scrum inter-operate with this?

Well, first Scrum seems implicitly to recognize the pack or mammalian nature of people, and organizes individuals into teams. (Our mammalian natures may be one of the reasons for this, but certainly not the only reason.)

Scrum implicitly seems to understand that the team starts to be a source of well-being and of motivation for the individual. While the team demands something of the individual, it also supports him (eg. “can I help you with that?”). The team provides this ‘pack’ sense of belonging. That they say we all need. (And I think I believe ‘them’ on this.)

More than a sense of belonging, it gives us a sense of purpose. We want the team (pack) to succeed. And we want to contribute to the team’s success. To the degree that each person identifies with the team, this is a whole set of subconscious associations that each of us tends to make with the team.

Did the designers of Scrum do all of this on purpose? Well, I have worked with Jeff Sutherland a lot, and I have never heard him put things this way. But he has suggested that there is more going on than can be explained.

And now to you….

Assuming that we as humans are largely pre-rational mammals with a need for a ‘pack’, in what specific ways would you use this information to make your Scrum team more successful?

Thanks.

More about distributed Scrum – one example

Posted on October 23, 2011 by Joe Little

There are so many situations and variations on distributed Scrum. So that there then becomes so much to say about it.

So, as one example, imagine you have customers in the US, and your business people are in the US, and the best Product Owner is one of these business people. He is pretty good as a Product Owner.

Imagine that you are doing a major add-on to an existing system. The add-on can be considered a separate product. So, knowledge of the existing system is important. And a quick release of the new product is also important (within 4 months). Assume that your current implementers are collocated in one city in the US (and could be collocated in one team room). And assume that you can get people who are 50% cheaper in cost-per-hour (and by resume just as good) within 3 time zones (eg, in Canada or Argentina). And that the cultural and language issues per se are not an obvious roadblock. And assume for now we are talking about only one Scrum team (about 8 people in total). This is not a huge project.

What should you do?

Well, first, I can say from experience having worked with a couple of situations like this, that this kind of distributed can work. Successfully (although to be fair, we did not do a blind trial to compare to an alternative course that might have been more successful). And your firm does not have to be ‘the best’ at doing distributed Scrum (although it would of course help).

But nor would I assume, from what I have said so far, that distributed is necessarily the best course. Collocated might still be.

Let’s go back a step. How do you decide?

One question is: how do you define success?

Is it ROI? Is it lower cost? Is it productivity per unit of cost? Is it faster time to market? Is it less wear-and-tear on management? Is it reduced risk? Is it more accuracy in hitting just what the customer wants? (And there are many others.)

Note: I find that faster time to market is often more important than many people realize. In this example, I said 4 months. This allows some time, but not too much, for knowledge transfer from the home people to the near-shore people. So, to me, in this example, it is a key issue, but not determinative by itself.

So, first, in your context, define success. At least what you think it would be. (It may turn out to be something different later. Live and learn.) Look to optimize that success.

Then, do your best to look honestly at your situation (there is always the fog of war, or the fog of business or life). What things should you do to make it (collocated or distributed) work better? What specific questions should you ask (of each alternative)?

A couple of suggestions that might be helpful, depending on the situation.

visit the ‘near-shore’ team. Pick specific people.
assuming you could pick 8 home people, when making the distributed comparison, decide who the ‘top 4′ would be. How would these people work with the 4 near-shore people?

Note: I have a strong bias that a distributed team should consist of 4 in team room and 4 in another team room. This minimizes the typical us-them problem, and makes that problem more manageable. The us-them problem (or overcoming it) seems to be the key to real success with distributed. From my experience and from what I hear from others.

of course you will look at skill sets. I have already implied that both sets of people have essentially equal skill sets, but of course this may not be true in your specific situation. In any case, you must look at how the skill sets of the 8 specific people mesh. Sometimes the resumes of the near-shore people are exaggerated. OTOH, sometimes we are surprised to find that the near-shore people are immediately better than our home people on our own systems. (Shocking, but it can be true.)
is your ‘home’ team diverse enough in a useful, knowledge creation way? Will the near-shore people make the ‘home’ guys think more creatively?
will the near-shore folks understand our business and the customers intuitively? (Do they have that tacit knowledge?) If not, how much would it take for them to get it (more)? Would that be a good challenge for the ‘home’ guys, to pass on that knowledge?
will the Product Owner be able to motivate the near-shore people as effectively as the home people? And communicate with them well, so that they quickly get the tacit knowledge of what is needed? And therefore can build it better?
is the PO willing to travel to the near-shore location?
how would the PO get the business value and requirements specifics to the near-shore people?
how would the PO give the near-shore people daily feedback?
to the degree there is a time zone difference (and in this example, we assumed that is relatively small), how will this work out practically? Will one or both sides compromise? eg, on the timing of the daily stand-up?

I hope these questions did not seem strongly in favor of collocated nor strongly in favor of distributed. One should approach the question, I find, with an open mind that is willing to find either answer as being ‘right for this situation, as best we can tell now.’

There are lots and lots of other detailed questions to ask.

Notice that I did not ask questions (yet) about how all the technical supports for distributed would work (although these are important questions, sometimes hugely important). And notice that I asked a lot about how the business information, and specially tacit knowledge around the customers, gets into the heads of the near-shore people. (Not that we can’t also have a problem with that with our home people too.)

I also want to emphasize the knowledge creation dimension of the team. Sometimes the near-shore people can add to that tremendously. Sometimes they can seriously harm the knowledge creation. It depends on the specific people, to a large degree. As best I can figure out.

Enough for now. Hope those ideas stimulated your thinking on the subject.

And hope you see (again) that ‘distributed’ is a very very big subject.

3 Drivers of productivity with Scrum

Posted on October 23, 2011 by Joe Little

One question is: “How important is Scrum anyway? I mean, it is always the team that does the work, whether they use Scrum or not.”

And this is true. But I do think most teams (if not all) that use Scrum give themselves a big advantage. They are more likely to be more successful if they use Scrum. And if they will fail, that failure is more likely to be identified sooner. Which is actually a win!

OK, so what are the 3 drivers of productivity in Scrum?

Well, I want to focus on some not-so-obvious things. Not the explicit dance steps of Scrum, but other things.

1. Creativity. The team can and should be more creative than before. Well, we all can always be more creative. And one thinks that the Scrum team enables more creativity. In every meaningful dimension relevant to their specific situation.

2. Velocity. By removing impediments, the team can increase their velocity, as measured by story points completed per Sprint.

3. “The vital few.” By selecting the very least amount of work (features) to do (that still make up a minimum marketable feature set), we can get it done more quickly, not bore them with features they care little about, and make the system more elegant and easier to maintain and grow. This can lead to much much greater productivity.

It may be easier to talk of these three things as completely separate. But, just as it is amusing to speak of body and soul as separate entities, it is more fun to live them as joint and inseparable entities.

Better distributed Scrum

Posted on October 19, 2011 by Joe Little

I was asked today for my main suggestions for getting better at distributed Scrum.

Advice 1. Make a fair comparison between distributed and collocated in your specific situation.
a. Cost per hour, usually lower.
b. Hours of “distributed” members, usually more.
c. Hours for “local” members, usually more.
d. Net effect on delivery time, usually delayed.
Then, calculate the net net effect. Does it still make sense to be distributed? Often yes, and also often no.

Our opinion is that the main focus for the team should be on creating new knowledge. So, the old idea that we always find the people with the best existing knowledge is flawed. Creating knowledge is best done collocated.

So, here are some more ideas.

First, I find that collocated Scrum is always better. Xebia has an argument that the way they do distributed Scrum is even better than collocated Scrum. Maybe, but I do not think their hypothesis has been given a fair test. (This is a big subject; not the main topic here.)

Second, there are many types of distributed Scrum. Some examples.
a. Distributed in the same city.
b. Distributed in only two team rooms, each in a different city, the cities not more than 2 time zones apart.
c. Dispersed across a continent (eg, the US), no two people in the same building, across 3 time zones.
d. Distributed in only two team rooms, each in a different city, the cities about 6 time zones apart.
e. Distributed in only two team rooms, each in a different city, the cities about 10-12 time zones apart.

There are some similarities across these situations, but they each are pretty different. And might require different key components to the solution.

We have not mentioned yet cultural, language, and accent issues. We have not mentioned organizational issues (eg, different firms, departments or reporting lines).

1. Communication will be harder in many ways.

We know in our business (new product development) successful communication is very hard. And that’s when they are collocated. Any kind of distance makes this worse. So, we do everything we can think of to make it better.

2. The team needs to Form, Storm, Norm and then Perform.

This is harder when they are not collocated.
Often they can get stuck in “high frustration.”

3. The team needs to share information.

This is related to communication, but different. Here we are talking about things like sharing documents, sharing diagrams, sharing code, etc, etc.

Advice 2: get your team to compare your current situation to a collocated situation. What is the worst thing about it, as you all compare? Work on that one big impediment.

There is ALWAYS something more that needs to be improved. And usually that something will be a weakness arising from being distributed.

Ok, now I get to a series of suggestions, not all of which will apply to your specific situation.

Suggestion 1. In the beginning, get the Team collocated as much as possible. Ideally for release planning and the several initial sprints. Many reasons, but probably the main one is they get to really know each other. Very important.

Suggestion 2. Get them together more often than you currently can imagine. If in the same city, one day per week (or more). If in two continents, a week each month (or as often as you can get).

Suggestion 3. Minimize the dispersion. Two team rooms, each with 4 people is best. Try hard to get the 4 to collocate in a team room.

Suggestion 4. Have frequent visits. Have one person from Bangalore visit the US. Then wait a week, and have a person from the US visit Bangalore. Do this more than you can currently imagine.

Suggestion 5. Spend money on really good tooling. This means: Scrum tool, great video conferencing, fancy Polycomm phones, leaving the Polycomm on during the day for impromptu conversations, high bandwidth between locations, fancy tools to emulate white-boarding or common editing of documents, common storage areas (eg, wiki or Sharepoint) that work really well. Plenty of throughput on the servers, plenty of server space.

Some teams may be into virtual presence things. Try them. If they work for your team, use them.

Suggestion 6. One of the key issues is: do they all ‘feel’ as though they are one team? Or is there an us/them feeling? (We want the former, and it seems to be key, almost always.) If not ‘one team’, make that issue visible, acknowledge it as a normal problem, and then work on it. (See some of the other suggestions, but there are also other solutions.)

Suggestion 7. Culture. I find that cultural issues and misunderstanding go down when people start to know each other personally. So, first, do that. (See Suggestion 1.) But, depending on the people, there can still be ‘cultural issues’. Even within the US, for example, but certainly between two countries or two languages or two cultures (eg, east Germans and west Germans). Get everyone some cultural education, courses, etc. Acknowledge that it is a common problem. And take the time to deal with it.

Now some more specific issues…

Issue 1. Where should the PO be? No strong opinion. Where the best PO is. Near the customers and near the team. With one of the two ‘pods’ of 4 people (half the team). It depends on many factors.

Issue 2. Where should the SM be? Again, no strong opinion. Where the best SM is. With one of the two pods. Ideally visiting both (or all) sites with some frequency. Again, it depends on many factors.

Issue 3. When should the Daily Standup be? Usually in the morning of one team, typically the “later” team. If necessary, both teams should compromise some on the timing.

Issue 4. Language, accent issues in the Daily Scrum. This is a fairly common problem. Often the “early” people (if they exist) can write their answers to the three questions and send that to the “late” team. And the discussion is more about clarifying and fixing things, than about the answer per se. Of course, the better solution is to fix the problem at its source: improve the Polycomm or equivalent or send them to a language course.

Many other issues and ideas, but those suggestions should keep you busy for awhile.

Note: We have not yet considered scaling with distributed teams. This can be done. With some success. It is hard, it is ugly, but it can still be successful. We can say that Scrum will enable you to see the ugliest thing today, which does help you fix it.

One reason for "Business Value Engineering" – 2nd pass

Posted on October 14, 2011 by Joe Little

Let’s say some smart people have given you some great ideas about “business value engineering.”

Let’s say those ideas include:

More customer demos
Having the implementors visit the customers as they “do work” or “live” (depending on your product)
A better BV Model
Don’t talk to customers (they don’t know they want an iPad)
Taking BV metrics after each release
Using the Pareto rule more to skinny down how many stories go in a release
Better PMO governance, to assure that problem teams are helped sooner (so that deliveries happen faster)
Improving the creativity of the Product Owners
Better brainstorming by the Business Stakeholders (or whatever you call them…the people that ‘assist’ the Product Owner)
Priority Poker (wide band delphi to estimate business value, using Fibonacci cards)
Agile Specs
Rely less on documentation and more on conversation to assure the Implementors understand the story
Story Boards
User Story Mapping
More wireframes
Focus on “bang for the buck”
A story breakdown structure, to use to manage with senior Business Stakeholders
Completing more projects “early”, eg, when we see that the benefit-cost ratio of the project has deteriorated to below alternate projects (and other criteria are met).
Light use cases
Etc, etc, etc

Note: I personally like some of these ideas a lot. On the other hand, some I tend to shy away from.

First thing to observe (and the above is a short list of all the ideas out there): Too many ideas to implement all at once.

Second: Some of these ideas are contradictory.

Third: “Many seem very good ideas for us, but how do I prioritize?”

Yesterday I explained how we can use “BV process mapping” to enable us to see enough to prioritize the improvements we want to make. (This really includes more than mapping, but let’s over-simplify and call it just “mapping.”)

As a minor benefit, BV mapping enables you to hear talks, and identify which part of the BV engineering process the person is talking about. In other words, you can put others’ ideas in a context that, hopefully, makes the ideas more useful or at least actionable.

One reason for "Business Value Engineering"

Posted on October 14, 2011 by Joe Little

I said recently that “business value engineering” is the place we can improve the most. By which I mean:
(a) identifying the small features that the customer will want the most (once they get them), and
(b) identifying the MMFS (minimum marketable feature set).

Perhaps we should also add to this:
(c) identifying a “business model” that is reasonably attractive to customers and successful for the firm.

By this we mean, all the pricing and servicing and delivery things we put around the product. If these don’t work, the “product” per se may be wonderful, but it will fail.

We need to at least briefly mention the time dimension. For most products, the customer explicitly or intuitively realizes that he is entering into a long-term relationship with you. (At least with all the new products that I deal with.) So, you must also have something like a “product life cycle” approach that is reasonable. If you want to succeed longer-term.

I think that improving velocity (as defined by story points) is important (as suggested by recent posts), and important in many ways. But I think improving business value engineering is, virtually always, the path to more success quicker, for the team.

Almost always, the biggest impediment for a Scrum team is a weak Product Owner (who is responsible for business value engineering). Usually the person per se is very strong (smart, articulate, etc), but largely untrained and ill-equipped to be a fairly good product owner. Much less an excellent one.

***
When I talk about business value engineering, I always want to talk about the full end-to-end “process”.

I think many people have many wonderful ideas about how to improve things.

But, I find that…
(a) no one can implement all of these proposed improvements at one time (usually it would take years to fully implement them)
(b) some of the proposed improvements are contradictory, or at least don’t work well together with certain other things
(c) for a given company in a given industry, given their own current “processes,” Improvement A is often much more useful than Improvement B. While, for another company, Improvement B is more important.

So, as with Lean Value Stream Mapping, one of the key reasons to do a business value engineering map (with hypotheses and assumptions) is to identify the priority of the improvements.

Prioritizing the improvements is very important.
I’d rather make a little progress each month than “lots and lots” of progress that is supposed to arrive in 3 years.

Scrum Team in Waterfall Land! What to do?

Posted on October 13, 2011 by Joe Little

The real question sent to me was: What are some tips for integrating our SCRUM model with non-Scrum groups who will not be adopting the process?

One can go many places with this question, and there could be other questions within this questions.

For now, let me answer two questions.

1. In general the culture and the management systems (eg, metrics) is used to waterfall. With a Scrum team(s), what should we do about this?

The finding is that this will remain a small-ish and firm and increasingly annoying impediment until you fix it.

Fixing it entails, ultimately, changing the whole company culture in a pretty significant way. Which, for a large company, takes a long time. Sometimes, you can select out a major group within the larger company, and just change that culture.

Doing this is hard work and takes time. It must be balanced against fixing more immediate and pressing impediments now.

How to do it?

Gather a small group of change agents. Regularly. Identify the changes you want to put into effect…how you want to go about changing the culture, at least in some ways.

Fearless Change by Manns & Rising and A Sense of Urgency by Kotter are two places to get ideas about how to effect the change.

For metrics, I would initially get the Scrum teams exempted as pilot efforts. Then I would suggest that the basic Scrum metrics (velocity, Sprint burndown, Release burndown, etc, etc) be used in place of the old metrics. You will win some of these discussions and lose others. Typically, this means the team must do “extra” metrics, typically for no good reason except that “they are there.” Make clear the extra cost to the team in doing the extra metrics. Over time, you will likely win more and more of these discussions as people become less afraid of the Scrum teams.

2. A Scrum team must work with other groups that are used to waterfall. What should we do about this?

The main advice is: use common sense and do just barely enough to make it work.

In general, different people will react differently to an agile-scrum team. So, your response will depend in part on how the other people react and perform.

In simple terms, there are two situations:
(a) they provide deliverables to the Scrum team, which affects what we can deliver or complete.
(b) we provide deliverables to them (which affects them and our reputation).

First, prioritize the groups the Scrum team is working with. Put the most ‘work’ in on the team that is most important (obvious as soon as I say it).

Second, are there any personal relationships we can leverage, such as, Team Member John is a friend of George (who is in Dept 1)?

Often, John can visit George, and discuss agile-scrum a bit. (And maybe take the time to discuss Scrum over lunch with George’s manager too.) This reassures George.

Then John should ask George “I know this Scrum stuff sounds a bit weird and is certainly different than what you are used to, but can you help us out?” And often George will do it, especially if we/John make things a bit easier for George. (“I’ll scratch your back, if you scratch mine.”) It’s all part of the unofficial ‘pizza & beer network’ that many of you know well.

Sometimes this is enough.

Third, let’s imagine that George’s boss hears that George is “being easy” on the Scrum team and orders him to “be tough, demand that those guys fill out all the usual waterfall forms each time! And abide strictly by the rules!”. And let’s assume we know that this is a silly bureaucratic waste (mostly).

The next step is to have a high-level “Impediment Removal Team” (IRT) that hears about all the top impediments from all the Scrum teams. Assuming this impediment (George’s boss) is important and we are sure we are right to complain, then the Scrum team sends this impediment to the IRT. A person from the IRT (a senior level person) goes to talk sense to George’s boss. If done right, surprisingly George becomes more cooperative with our Scrum team in a few days.

Sometimes this is enough.

Sometimes the problem is not George’s boss, but only that George has 15 things in the air, and we are not that important to him, so his performance for our team is not reliable. In that case, we can set up a special board (in the team room or virtual team room) and John or someone else in the Scrum team can ‘manage’ George, eg, visit him often, send him ticklers, go to his boss, help George fix his own impediments, etc, etc.

Sometimes George is so key to the Scrum team for a Sprint or two, that we have him come to the Daily Scrum every day to report on his progress. Sometimes we have somewhat formal ‘weekly’ meetings with George.

The main thing is: we add to ‘Scrum’ just enough other stuff to make things work with George and Dept 1. We try to ignore or minimize the stupid stuff as much as possible, and get as much value from Dept 1 with as little effort as possible. Sometimes we just accept some degree of ‘stupid stuff’ from Dept 1 for a while….but only for a while.

Again, each department or group will be different. Some of things we do for Dept 1 might be overkill for Dept 2. So, we adjust our response for each department and each “George”. Based on our team’s need and who they are. So, the way we work with Dept 3 will be different than how we worked with both Dept 1 and Dept 2.

Sometimes a ‘serious’ issue comes up. Be ready to explain Scrum, explain how it is less risky than other approaches, and why it does not need to comply (completely) with the usual BS bureaucratic stuff that we have always been doing. But learn to say this in a nice, non-confrontational way. That sounds (and is) supportive of the main business drivers in your firm (“we have to have faster time to market”, “we must reduce costs”, or others). But be reasonable. Bend ‘em but don’t break ‘em. Remember that changing organizations takes time, and much of it is based on goodwill. So, increase your capital of goodwill and spend it judiciously.

Changing an organization takes time. Keep plugging, but have reasonable expectations. You don’t have to win every battle in the first minute. Be adaptive.