Wiki? I Don't Need No Stinkin' Wiki!

So my first project here at PathFinder Development is to move an existing application from .NET 1.0 to 2.0. Seemed simple.

I started the usual As-Is Decomposition modeling while looking at the existing application.

It turned out to be a prototype that didn't type.


OK, abandon As-Is and concentrate on To Be.

The Functional Requirements template worked just fine in Word. Everybody loved it. Everybody thought it was real snazzy. Of course it was. I'm the English Major Alice referred to in her fine blog on Design.

Everybody, that is, except our Technical Architect.

"I want you to put this on our wiki," he said calmly.


"And we'll all be able to edit it."


I'm the document master on this project, Mister. I determine what the developers see and how they see it. I create the catalogs, baby. I talk to the customer, dude- keep the developers behind that curtain- they might pull out a slide rule when the suits are around. I'm the technical to business and business to technical translator, fella. I run the JAD sessions and the interviews, pal.

Well. I've only been here a coupla weeks. And they're payin' me real good. And they seem pretty smart...

So as I was groaning and moaning learning the new tool, and doing it over to the technical guy's satisfaction (who ever allowed a developer or Technical Architect to have an opinion on formatting and word use? You ever try to read one of their documents?).

And then did it again to satisfy the slave driver.

The he rubbed salt into the wound by telling me to add <previous> and <next> links at the bottom of each page.

I tricked him.

I looked at the mark-up language for our instance and found some cool tags that generated them automatically. Hah!

If I post this, I thought, and anybody on the team can edit it, what the heck do they need me for? Mebbe it's time to get the old resume revised, even though I've only been here a few weeks.

"You'll write the Functional Specifications and we'll all edit them as we develop the feature," My team-mate turned Agile Coach told me.

Oh. I'll add the use cases, data maps and controls to these 'Specifications.' Yeah, I can see how that'd work.

"No, we don't long use cases that no one will read- plop in some activity diagrams, we'll list the use cases as 'scenarios' and you read up on User Stories."


"Agile is 'just enough' documentation," he said patiently, "Read up on that, too."


My hesitant, but analytical hold on the world started caving in.

None of my closely held writing, analysis or PM skills were being used, much less valued, in this Agile stuff. 

It was akin to moving from the world of daily journalism into a help desk- all the moves and instincts I used in news were, at one fell swoop, totally and absolutely wrong.

  • I know UML I cried out.
  • I can split a 45 page Use Case into 13 different documents and set them all at different levels!
  • I can create To-Be and As-Is Decompositions PowerPoints that make people cry!
  • My Vision and Charter documents are so clean there no one sues anyone else, I declaimed.
  • My VISIO charts are animated art works fer gosh sakes with drop shading and colored boxes so the executives has something in color to look at.

Then I started to read. I like getting paid regular.

I started with the Manifest for Agile Software Development.

  • People oriented. Hmmm.
  • Working Code? Never been on a project that actually worked the first time to the customer's satisfaction.
  • Actually listen to the people who use it? I've been demanding that since I started this BA stuff.

Not bad.

Went to the links.

  • Iterative- excellent- works best that way.
  • Feature driven with add ons as able- just the way I've designed in the past.
  • Self-organizing? Only high level folks? WOW!


Got me some books.

  • Good for small to medium sized projects- coordination and traceability issues otherwise, makes sense
  • Scrum? Who invented that word? Oh. Rugby. Nasty game. Ah, everyday status/obstacles/plan- good idea.
  • Prototyping with actual code? Great Idea.
  • User Stories? Hmmm. makes a lot of sense- after all, we're not gonna use this...


But no mention of the need, want or value added to the Agile Team by a Business Analyst or User Experience except for some upfront JAD or interview work in Iteration Zero.

"That's because they had customer buy-in at the start with dedicated, empowered customer buy-in," The suddenly wise and no longer job threatening Agile Coach explained, "You're gonna do much of that with interaction with Subject Matter Experts and our User Experience team member as we implement this feature."

Um, How do we handle Scope Creep?

"We only deal with the feature we did last week (bug fixing), what we're working on now (design, specification and code) and what we're going to do next week," My Agile Coach explained, "And we let the visionary blog, add to the wiki in a Blue Sky section to his/her heart's content, but we only deal with that stuff as we begin designing that feature."

Mark Twain was right, your father seems like the biggest dope in the world when you're 18 and you become amazed athow smart he became in 7 years when you're 15. This turn around only took a month or so.

Ah. Thank you Sensei.

Next Up: My First Agile Project's Process Flow

Powered by ScribeFire.