Reduce Sneaky Scope
Reduce Sneaky Scope"Sneaky" scope is the result of BigDesignUpFront. A lot of effort has gone into reformulating (and usually mangling) the customer's expressed desires as a "requirements document". This is passed on to the programmers as "what must be implemented". There might also be a "technical specification" which is supposedly a detailed answer to "how we will implement what is described in the requirements document", adding one more level of separation between the customer and the programmers.
When the customer starts using the product (after the EraOfSilence), a common complaint is "but why doesn't the system do X?". Or, even sneakier, "bug" reports start pouring in, which really are indications that the customer is finding a "requirement" that never found its way into the "requirements document". (But "it's obvious that it should work that way, not the way you implemented it!".) Programmers are strong-armed into implementing the "real" requirements (i.e. adding or modifying functionality). The project ships late, or never ships at all.
I'm calling this "sneaky" scope because it's in principle a case of the customer not honoring their contract - after all, they agreed to take delivery of the "requirements document" as a deliverable, they signed off on that document, and they should understand that what they get after the EraOfSilence is an implementation of the "requirements document" and nothing but, with anything that was left unspecified being completely up to the programmers. Sometimes we might even be able to get the customer to believe that, and have them buy their way out of the problem.
Of course, this interpretation doesn't make sense. In XP, the customer has rights; such as the right to change their mind, the right to specify things vaguely initially and provide more detail later. The less BigDesignUpFront we do, and the more we incrementally implement UserStories and have the customer's immediate feedback as to whether the stories meet their actual requirements, the less opportunity for "sneaky" scope to creep in.
Case studies
The project involved a ContentManagementSystem. The requirements were that, given a detailed specification of the (relatively few) "categories" of content supported by the system, we should provide a non-technical way of publishing new content of the given category to the site, and guarantee consistency of the "look and feel" of each content category. E.g. (simplifying somewhat) we'd have an "article" category, with title, date, author, and paragraphs of text; this would always appear on the site with (e.g.) the title in followed by a hrule, then the paragraphs separated by <br>eaks, then the author's name in italics.
BigDesignUpFront resulted in the "content specs" not being delivered for several weeks, during which time not a single line of code was written. When the specs arrived, they were slightly more complicated than had originally been anticipated - new fields such as "keywords", "author's email", etc. had crept in. Well, email links weren't too much of a problem, but "keywords" sounded an alarm bell. Q. "Does that mean, by any chance, that the content database should be searchable?" A. "You mean it's not?" We cleared up these little misunderstandings (by decreeing that such "advanced features" would belong in a "version 2" of the system), and the EraOfSilence began.
We spent a while coding. We were using XML/XSL as our underlying technology; after a while, we had a fairly neat framework for a "content database" and a number of XSL stylesheets implementing most of the content "specifications" we had been given. When we felt ready to start beta testing, we asked the "content" team - our customer, basically - for some sample content.
A sample of the dialogue that ensued...
''How can anyone, customer included, not find this incredibly ridiculous? I compare it to ordering a pizza. I call the pizza place and say I'd like a pizza with pepperoni and mushrooms. When they arrive I say, "Where's the olives?!" They say, "Well, you never asked for olives." At which point, if I'm sane, I say, "Oh, you're right. I'll remember to ask for them next time."
Pizzas, alas, typically do not cost tens or hundreds of thousands of dollars. Also - most pizza users understand them thoroughly.
I found this example amusing and painful given that I've just been on a project which was practically identical. I felt part of the problem was not SneakyScope? but a failure in the initial design to EmbraceChange. We had problems similar to the 'author' one above, because at intermediate stages the data was unpacked into Oracle tables - missing required fields meant the data wouldn't unpack and it was stuck in limbo. Crap data into strict types does not go. The Better Mousetrap was to keep the data as XML all the time, and use the SQL DB to index the data only (instead of seeing the SQL as the 'source' of the data for downstream work). This removed many 'bad data' problems at a stroke, by converting the consequence of failure from 'data doesn't fit into the system at all' to 'data flagged for intervention', a kind of problem we already dealt with when deciding whether the data was publishable.
A second parallel is how late in the day you asked for their data. This is a killer and would have shown up straight away the problems in the requirements. In our case we had an excuse, as we repeatedly asked to do a prototyping phase to try reading their data, but the customer's project manager was a firm believer in the WaterfallModel. On a related note, you've also shown up that you implemented your framework (a design artifact) prior to implementing readers for their data (a business requirement). We made this mistake too. I've never seen this come up as a rule of thumb for development before, but it seems to me that you should /always/ write some level of systems integration code - ie into the customer's business - first, prior to writing a single line of anything that could be labelled a 'framework'. Systems and data interfaces can be UnitTest ed and give you a leg up in making sure the rest of the system is working properly - you can feed it with live data from day 1. -- BrianEwins
I'm not sure how you mean "how late in the day you asked for their data"... We did ask for real, representative samples of the content that was going to be published fairly early on, along with the "specs". We kept asking afterwards. But a fairly simple problem intruded - namely, how could the content people provide real live content when they had a) no idea what the applicable constraints were, b) no idea what the site would look like when it was time to publish content and c) to few people on board to write any content yet. By the time we could work with real data, it was too late. It wasn't as if we could just cross our arms and insist that we weren't writing a line of code until some actual content was available.
On another, similar project I was more recently involved in, similar things happened. Vague requirements were filled out gradually, almost invisibly, and handled by the team without much regard for "change control". We did have a lot of data up front - far too much, in fact. None of it in a format directly usable; none of it produced by actual business processes of our customer. We learned, again way too late in the game, what those processes were and what the real requirements were.
I do not plead not guilty to what happened. But the moral of the story, for me, isn't that in such situations there must be a prototype phase, or that the customer must provide representative data up front, etc. Rather, it is that open, direct, and lucid collaboration with the customer (or the lack thereof), is a crucial factor in a project's success or demise. This collaboration, when it happens - and I've seen it happen, but almost always too late - is a process of mutual education, and the only way to gain insight into the actual issues.
In the "traditional" mode of managing software projects, there is one person mediating between the customer and the team; this person has a strong, immediate temptation to sweep little delays and changes "under the rug". Individuals on the teams have the same temptation - I don't know those folks well, let's do them a favor - they are our customer, after all. The temptation exists because the communication, when it exists, is one-way only - the customer is implicitly allowed to short-circuit the project manager and engage team members directly; the reverse isn't true. The project manager "translates" what the customer wants into terms that development can "understand". Etc, etc.
It's almost as if the "traditional" setup was designed to make projects fail by lousing up lines of communication. At least, that's how I see things today, with a little more perspective and, to be perfectly honest, as a result of buying into the XP philosophy wholeheartedly. -- LaurentBossavit
Example project:
1. Customer says "I want you to implement this filing system in the computer."
The filing system was a simple keyword-based system the customer had dreamed up and implemented over a number of years, to hold ideas, documents, and just about anything that came across his desk: It had a special form, with 4 spaces for keywords at the top. If you put more than one keyword on the form, they'd make a copy for each additional keyword, and file the copy under that word. The original would be filed under the first keyword. Thus, to find a document, you lookup a keyword, and if you find a copy, go lookup the first keyword on the copy.
OK, system written and delivered.
2. Customer says, "but now that it's on the computer, shouldn't it be better?" and "I always expected the computerized version to be better than the manual system." Customer goes on to say that "NASA uses a seven-deep hierarchy to identify all the parts needed in a space mission; I want to do it like that."
OK, after some requirements gathering, and rewriting of code that really made a mess of the system, we get to...
3. Customer says, "whaddya mean I have to come up with different 'levels' of categories? When I file something under 'parts.cam.xp45', how do you expect me to know in the future that it's under 'parts.cams'?!?!? I just want to search for 'xp45'! Who came up with all this crazy hierarchy stuff anyway?!?!?"
So we go through another rewrite that essentially gives him "N" keywords instead of 4, and is very inefficient an not scalable.
Everyone walks away unhappy.
Moral of the story is... Most customers don't really know what they want until they can try out something like it. So, use IterativeDevelopment. -- JeffGrigg
What is called SneakyScope? here I have heard being called SemanticGap elsewhere. Or did I misunderstood what was meant? -- GunnarZarncke
EditText of this page
(last edited June 9, 2005)
or FindPage with title or text search