Home | Login | Recent Changes | Search | All Pages | Help

HudsonsBayStart

This discussion was happening in IterativePlanning, and has been moved to it's own page.

For more background see A Hudson's Bay Start, by Eileen Strider.

We take a trivial problem - really trivial like putting HELLO WORLD on a single screen, and run it through the entire development process - tools, people, documents, test plans, testing, or whatever they're planning to use. It's amazing the things that shake out in an hour or two. What's even more amazing is how many clients are reluctant to do this - "It's a waste of time; we've got an ambitious five-year project and we can't spare a half day on an exercise." - JerryWeinberg 2003.04.10

I've used exactly that approach, even down to HELLO WORLD. I'm not clear if you're talking about a simulation or actually doing the work, Jerry. In my experience, doing it for real takes longer than an afternoon if the project has been stuck for a while.

A lot of the time I have seen non-cooperation at the bottom of some stuck-ness. The network folks just plain refuse to deploy the machines for development, for example. And everybody's habituated to not talking about it. The "Hudson's bay start" flushes this stuff out, but for me at least it takes a while. "We can't do the build because we never got the machines from networking." "OK, Mr. Networking guy, when can I have my machines? A week. Good. So Monday we start pushing HELLO WORLD through and see what breaks." By Monday, I've got an actual fact to go work with.

As for "Amazing" Jerry, they're reluctant because they already know what's holding things up and would prefer to continue not dealing with it.

This tangent is making me wonder whether the motivation for "big bang" development isn't sometimes simply to be able to force something to happen when people aren't cooperating. Doesn't that speak volumes. -- JimBullock, 2003.04.11

We choose a HELLO WORLD project and see if they agree that they should be able to do it in a few hours. That agreement is important.

Then we start and see what snags we run into. I've done HBS where it stopped two minutes in. If it's a total show-stopper, we stop - and get the organization to fix the problem. Then we do another HBS when they believe it's fixed. Since the HBS is only supposed to take an hour or two, rescheduling should not be difficult.

If we can, we try to find a simulated workaround for the showstopper, so we can reach the next showstopper (which might take another two minutes). Then we iterate the process. Eventually, they work through HELLO WORLD, correcting stoppers along the way - which is frustrating but far, far less frustrating and costly than doing in in the full project. Sometimes, they realize that the project has been scheduled five times too fast for reality, and actually change something in response. Those are the best results. - JerryWeinberg 2003.04.11

Perhaps, though "big bang" may have more to do with adopting "hope" as a strategy.

I suspect that the degree of organizational enmeshment correlates to the need for a strong executive sponsor. The greater the enmeshment, the greater the need for someone high up the food chain who can to wield a big stick. The projects that I've seen succeed without a sponser were in organizations that were young, and hadn't yet developed any internal roadblocks. --DaveSmith 2003.04.11

some stuck-ness...The "Hudson's bay start" flushes this stuff out...

This sounds like a lot of the success stories that Robert Martin (using XP) and Mike Beedle (using Scrum) tell, where they get a stuck project restarted (often one in "analysis" or "design" for a year), and delivering working software within two weeks or a month.

KeithRay 2003.04.12

Of course. Same principles at work. "Back in the day" we just called it "getting serious" or "getting this thing straightened out." Short iterations do have lots of good effects by themselves without all the practices of SCRUM, or the other 11 in XP being in place yet.

I am curious about working with an existing organization without practices in place per se. Where do you start? How do you start? I've started with iterations sometimes, to good effect, with additional good practices to follow. Feedback is kind of magical that way. -- JimBullock, 2003.04.12

Let me clarify. We do a Hudson's Bay Start at the beginning of a project,

I am just now realizing that this is the "externalizing tacit knowledge game", again. When there's some project contemplated with great enthusiasm the "naysayers" - so called - are often running a simulation in their heads of what's going to happen. Sometimes they've got different information about how things work, something we call "experience." But, when they present only conclusions the rest of the gang doesn't know how they got there or perhaps doesn't want to hear it.

With the "agreement" the rest of the gang is committed in a small way to actually assessing whether this thing will work, and how. Otherwise, they're possibly still sitting around feeling good about the wonderful future they're going to have, never mind how. Whoever suggests that things may not work out quite so well is just bad and evil, not helpful and prudent. With the "agreement" that changes.

And of course it is almost impossible to decline to invest only a couple hours in a risk mitigation activity like a Hudson's Bay start. (Declining is it's own indicator as well, isn't it?) This is especially true for a project as big and important as this one, which promises such a wonderful future. Doing the simulation, we can even continue to bask in the glow of our future success for a couple hours more (because it's all going to work just fine.)

Very interesting. You're tricky - er - subtle. But I knew that. --JimBullock, 2003.04.12

I have a story which seems to complement Jerry's Hudson Bay start story but is not about such a small iteration.

Years ago I realized that the handoff between developers and QA was problematic. Part of the problem was that it was never clear what a deadline meant. Did it mean that the developers finished checking in code by that date? Did it mean the developer handed QA the testable code on that date? What time on that date was the code due? By start of business? Sometime that day (which usually translated to 4PM)? Usually QA believed the finished code will be delivered by start of business but developers believed they had all day to work on it.

My idea was to automate the build process (via tinderbox) and then set a rule that the deadline means that the object code should be ready for QA by start of business on the day it is due. Now developers can work as late as they want, the night before and there is none of this business where different developers claim "now they are done" and the "official build" is started and stopped several times during the day as the developers change their mind. Since the developers are out of the build loop the process becomes objective.

I have had no luck in getting this simple idea to work. Managers seem to believe that they will go faster if they allow developers to "work till the

last minute". All this ensures is that the developers are disorganized and that QA is never sure when to expect testable code.

KenEstes 2003.04.12

Some managers, Ken. Not me, for example. I need to think a bit about some of the mechanics of how to make what you suggest work, because I think that goes off under "iterations" or perhaps under another "having a real software engineering environment" page.

Properly conducted, I speculate that a HudsonsBayStart could flush out exactly the situation you refer to, provided that all the correct players were allowed in the room. I more than suspect that Jerry is quite adept at getting the right players in the room, any of several ways. Of course if they _won't_ let QA in the room, that's good information as well. -- JimBullock, 2003.04.12

Jerry,

Can you please give us an idea about how much detail is in your Hudson Bay Start simulation. I suspect part of the Art in getting this to work is to have enough detail so that it simulates the real development process at the company but not too much unnecessary detail.

Here is how I interpret the flow of events for an iteration zero. I assume this is a large company which makes shrink wrapped software. Please explain to me how this differs from the simulations that your run.

1) Jerry sends an email message to the product group asking for a program which prints the message "Hello World. Product: asdfjkl". The random string is given in the message to allow simulations of "different code". This simulates upper management creating a new product. If developers hear about the product in the hallway they will probably get the details wrong, most likely give a program which returns the string "hello world" which is not what was asked for.

2) The product group writes up the spec and passes it to the developers the way they always do such things. The spec is only about a sentence or two but here the important thing is to use the normal communication means.

3) The developers code it and pass the code to QA. Here we are faced with Version Control issues. Where does this new code live in VC? Is it a new product a branch of an existing product? How does QA receive the finished code?

4) QA checks the code against the spec, which means verifying that the code prints the desired string. QA then gives the official approval that the code meets the written spec.

4.1/2) Perhaps there is a simulation of a feature change here. We could have the product group change the random string and this would give us an opportunity to test our bug tracking system.

5) Gold CD's are cut and put in an envelope addressed to the duplication company, the envelope is handed to Jerry. So Jerry gets a finished product. He holds a real object at the end with certain properties.

I find it amazing that with all the talk in the workplace about "team building" there is no effort to try and improve the basic skills that a team

should have.

KenEstes 2003.04.14

Reporters are good, and are a way to get higher management involved, but we do want everyone to see for themselves what happens. Many process improvement possibilities can be seen on the spot, but you have to exercise restraint about trying to implement them on the spot, unless you're willing to start over. Then the HBS becomes an HBS for process improvements - and do they ever learn a lot about "let's just change this one thing."

It's an art form, surely, and uses all the principles of experiential learning. It's just that instead of being at the abstract end of the spectrum, like verseworks, it's as concrete as you can make it - this is the way we actually do things.

One of the benefits that hasn't, I think, been mentioned, is that people get to see (as we did in verseworks) that the other person's job is not as trivial as they thought. It's amazing what happens when, for example, developers get to stand and watch the testers trying to test their HELLO WORLD example. - JerryWeinberg 2003.04.16

I am also impressed by the idea of this exercise as a way to learn about process improvment. I am chuckling about what you said. I often fall into the over enthusiastic 'I want to fix everything' camp, so I bet I would learn much about the art of restraint.

KenEstes 2003.04.17

Re: Years ago I realized that the handoff between developers and QA was problematic.

OK. I've got a couple variations now. The problem ("a" problem?) with the approach you describe, Ken, has to do with misplaced authority. You can't make a policy for people who don't work for you, nor follow it whether they work for you or not, unless you're doing the development. So some alternatives are:

• "We'll take whatever builds at h-hour."
• "At h-hour, we'll take whatever last built clean."
• "We'll take the baseline from the repository at h-hour, and our first test will be a build from source."
• "We'll gladly start testing, the first business day after you tell us you've got a baseline you want us to test. We're very proud that we can be that flexible in our availability."

Any of these moves puts the responsibility back where it belongs, with developers who aren't done if they're not done, and with their management if management decides "one more thing" and to keep QA waiting around.

-- JimBullock, 2003.04.22

I am think we agree. I wanted to create a painless process. I thought I had some tools too do that, however it is a process first and a tool second. As a process it needs management agreement and continuing support.

KenEstes 2003.04.22

Exactly.

So the moves that will have leverage are the ones that will generate some management agreement and continuing support. The tools that will help with that are people, process, and understanding kinds of tools. MBTI is one. The congruence model is another. Various communication tools form a whole toolbox.

One organizational kind of tool that's not so explicitly modeled is owning you problems but not someone else's. Getting QA something they can test is actually engineering's job. So if they don't have something shipped . . . go home.

JimBullock, 2003.04.22