Pathfinder Blog
Author Archive: Scot Witt

You CAN Develop with Loosely Defined Requirements, Sort Of.

Scot Witt, Tuesday, June 24, 2008 @ 2:43 pm

We just opened up a beta site at www.plantcollections.org.

I'm the Business Analyst on the project. Wonderful idea, connect all the Plant Kingdom databases into a single repository and let anyone who wants it, access the data.

The initial requirements were, essentially, let me export the data I want based on any field in any view and allow me to download it in an Excel spreadsheet where I'll manipulate it to get what I really want. And I need this yesterday.
Continue reading »

Topics: , ,

agile ajax Agile Ajax

FireFox Release Candidate 1: Enjoy

Scot Witt, Monday, May 19, 2008 @ 11:01 am

Colleagues here at PFD demanded I add this blog after sending it out as an e-mail.

I'm the fellow that translates what the developers say into English for the business people. I then translate the spreadsheets into quasi-code on the reverse communication flow. I'm a Business Analyst. I gather requirements for software projects, hold the developers to the requirements, assist (sometimes do) testing, training, pathway mapping and pretty much anything that anyone on the team tells me to do.

With the caveat that I did NOT do a scientific or even methodological test of the new browser, I present my results:

I installed FireFox 3 Release Candidate 1 on my Windows XP SP3 machine and have been running it through a few of its pace and thought you might be interested in my anecdotal testing:

  1. I usually keep 7-10 tabs open when working, in addition to a
    Word/VISIO or Excel Session. I keep Thunderbird (e-mail client) open
    and usually stream audio on WinAmp from www.folkalley.com. With two monitors running, I'm usually down to 1100 Mb of free RAM on FireFox 2 (which usually pulls between 65 and 80Mb of system memory with all the stuff our project team pushes to my browserthe BB DevTeam puts on its pages. I'm running a typical workday session now and FireFox 3 is only using 45MB, reason enough for me to use it.
  2. The Bookmark manager is sooooo much easier to use than FireFox 1 or 2.
  3. <ctrl><+> and <ctrl><-> magnifiesdoes the entire page, not just the text. Trey kewl.
  4. You don't have to go into about:config to monkey around with your MIME associations- there's a new Applications
    icon in Tools that not only allows you to select previously associated applications-file types, but to assign whatever you want to open files.
  5. It IS faster- noticeably so on opening sites. Mozilla's DevTeam also integrated the security inside the browser so there are a few new
    twists- for example there's a robot icon to the immediate left of the address field, mouse over and it will tell you if there's any real
    identification for the site (the sites have to enbale the ID through Firefox, so it's TBD [to be determined], I guess, but a nice feature).
  6. The release notes show a couple of extremely minor issues- easily handled. And like R2.0, the Add-Ons Manager makes certain your add-ons
    will work in the new browser.
  7. Add-Ins- quite a few showed as incompatible with the new version. Colleagues here at PFD World Headquarters reminded me of an add-in called Nightly Tester Tools. I used it back in the FireFox 0.9 days but got so frustrated with it that I abandoned it within minutes. The latest version works like a dream. Install it, on FireFox reboot, override all the incompatible add-ins. Most seem to work. Like any other Add-In issue, you may need to return here and disable them one at a time if you have issues.

These add-ons were incompatible in my version:

  • AVG Safe Search
  • Bandwidth Meter and Diagnostics
  • Dummy Lipsum
  • FEBE
  • FireBug
  • Forecastfix
  • Google Browser Synch
  • InFormEnter
  • LinkedIn Companion
  • MIME Edit
  • PicLens
  • Selenimum IDE
  • ThinkVantage Password Manager

FireFox3 will continue hunting for your FF2 addons and letcha know when a compatible version is released.

Topics:

tech development Tech Development

Testing

Scot Witt, Thursday, May 15, 2008 @ 4:22 pm

Let's have a little more compassion for the QA Team, eh?

Well, actually, the Design Team disguised as the QA Team.

The little frustrations, system and function failures result in a lot of dog-kicking, huge antacid and alcohol intake and a lot of whining. I begin to understand how little-person tossing may have started down under a few years ago. Obviously QA Teams at the pub got this trend started.

The academics have broken testing up into five or six TLAs (Three Letter Abbreviations designed by Consultants so they can charge more and use more buzzwords than normal people). You got your UAT (User Acceptance Test), your Unit Test, your Sanity Check, your boundary test, your Automated Regressive and Non-automated Regressive series (this means high school kids who click and chew gum while re-Ghosting machines) and on and on.

These labels are obviously created by people who don't do testing.

Us testers use language you shouldn't put on a blog.

This blog started because I had to do a complicated test three times today before I got the dang thing right.

I wrote the test script, had to change it four times because it wasn't really testing what I wanted it to test when I was writing it yesterday. Funny thing. I had the developer who created the function look it over for me. He said it was fine.

But each of those rewrites was one to three new database entries.

When I had it right and came to the end of the second phase of the three part test... the application didn't do what I wanted it to do. Totally unrelated to the test. ARGH!

I know.

You've been there, done that and have the tee-shirt.

Come to think about it, Our PM owes me a tee-shirt. 3XL, Ron, I've lost 45 pounds since 4/4.

Before I threw my laptop at the wall, I calmed myself by repeating the Tester's Mantra: If I didn't find it, the Client would.

The thing is, I don't mind writing Test Cases or even test scripts. I find writing them an interesting challenge. I also find doing them drudgery, akin to the constitutional prohibition against cruel and unusual punishment.

I wish I could get into the spirit of a real QA guy who thinks about these tests creatively and with wild abandon. You know, the fellow or gal who can think like a crazed end user ready to pounce on my poor application with abandon and relish.

Such folks are a treasure.

But with a small team, the lack budget for QA resources and the need to test major functionalities of a complex application, we Business Analysts, Information Architects, Project Managers and Receptionists will continue to click, type, spell check and screen capture.

And moan, groan and whine.

But it's gotta get done.

Oh, for the days when the BA and QA Lead managed the process and others did the work...

Topics: , , ,

tech development Tech Development

Another Way to Pair Program: Generating Requirements

Scot Witt, Tuesday, May 6, 2008 @ 12:13 pm

The CTO (Chief Technical Officer) tells the BA (Business Analyst- me) and the IA (Information Architect) to pair program.

He's our boss' boss.

He's our Agile ubermensch (mensch is a Yiddish-Middle German word meaning, in this context, expert, coach, guide, all around super star; I don't know if it is in Modern German, but our CTO will tell me, he's fluent in German. I took Latin and Spanish).

We gotta do what he says.

I whine that I write faster than the IA.

The IA complains I can't do wireframes as fast as he does (true, VISIO isn't as easy as it looks, kids).

We are despondent and snarl at each other. Pitiful.

An idea.

How about we split the requirements in half. I pull the ones I wanna do, the IA grabs the more visually oriented ones. We write 'em up, do the wireframes and then have the other edit and comment on the other's work while we collaborate on the items we need to.

It allowed me to spit out the bug repairs like a machine gun and freed our IA into drafting wireframes and workflows he needed to do without slowing me down. While we edit the other fellow's stuff, we find small errors, ask some questions and significantly improve the requirements without turning them into novels.

The benefit was to the Developers who had very spiffy, concrete, succinct and directed requirements before the iteration started. They had time to read them, ask questions and begin their design work. The client was able to read them and sign off early making the sprint kick-off run smoothly.

The CTO gave his blessing.

And yeah, I started numbering the dang Business Rules to help the Developers, even though everything I ever learned about writing tells me non-hierarchal/unrelated lists should be bulleted. But it helps the developers refer to specific rules and my sense of technical writing dos and don'ts can suffer this arrow of outrageous fortune.

The Developers were not impressed. They like numbers. Especially ones with decimal points.

Turns out the PM (Project Manager) even likes the IBM-concentric deep diving numbering schemes of the 1970s. There's no accounting for taste, is there?

But I don't have to like it, do I?

Topics: , , ,

tech development Tech Development

One Way to Organize the Documentation for Wikis and Trackers in Agile

Scot Witt, Wednesday, March 5, 2008 @ 5:14 pm

One of the most difficult things I've had to get my arms around has been how you put user stories up on a wiki.&nbsp;

The books tell you to put 'em on cards with a number associated to the title. The idea being the developer and BA use the card to open conversation about a feature or function to draw out the requirements. And then, when the iteration is over, you throw the cards away.

Well, Blinkey, it doesn't appear to work when your client is 800 miles away. You have limited access to the Subject Matter Experts. The client wants docs for the business team. We've got nothing to show them but the specifications we're supposed to throw out. Don't make no sense, no how.

The Agilites (pretty good, eh?) usually say the BA comes in to run JAD sessions at the beginning of a project and the team never sees them again. Then the books suggest you bring the IA in with a designer 'when needed.'

PFD joins development with User Experience Design.

That means the IA and I (the BA) are permanently assigned to the team. So we do the documentation, run interference for the Dev and Business Teams and help everyone talk to everyone else.

Nice. But. The teams that have an active business team member empowered to make decisions are very lucky. We have built in delays on Q and A. And unless we politely remind the Business Team to concentrate on what's in the current&nbsp; iteration, we can lose a great deal of productivity.

So. We've pulled some detail from fellow PFD'er Alice Toth and Agile Coach Dietrich Kappe and discussed between our Dev and Design Teams (the Design Team is me and the IA, marketing, it's all about marketing).

At the top level of the Wiki is the Release Master page. It contains the Iterations for that Release and links to each of the Iteration Pages.

The Iteration Pages have a live link to the Tracker application. Each item is linked. The items include the Tracking Issue (we use JIRA) and the Specification (User Story, work flow, business rules, wireframes and tests) for each Tracking Issue. Each Issue includes a cross reference link to the Specification and vice versa.

Pretty kewl, eh?

I sort of mashed the old specification form with Alice's User Story form (thanks again, Alice!).

  • The Wiki Page Title is the User Story Title.
  • Under the first header is the User Story. We've kept them to six sentences or less.
  • Under the second header is workflow (task-flow for my UxD brothers and sisters).
  • The third header is for Business Rules. If this goes over five, we start looking at splitting it up.
  • The fourth header is the Wireframes. More than three and we start thinking about splitting the doc.
  • The fifth is Tests. Two columns- one for action and one for expected result.

If we pour more than one User Story into the document, I'll place the test for each user story right under the User Story.

Advantages of this new system:

  1. The docs are getting much closer to 'just enough' documentation.
  2. The cross references are making it a lot easier for the developers since they're creating their technical documentation as they code and cross referencing everything in their browsers. In other words, it's easier for the developers.
  3. Clearing out the crap lets the Design Team work ahead so we can have the developers read and research each Specification before the Iteration kickoff- we get better estimates and know when we have to go back to the client for more detail.
  4. We know when the scope creeps- immediately.
  5. The client has to approve before an item will be included in an iteration.

Disadvantages:

  • Client confidence- for some reason the client wants the docs to dig a little deeper and be closer to Use Cases and complete functional specifications. So far, education seems to be mitigating this need.
  • We made the shift in mid-iteration, so we still use a few old formatted specifications and the process isn't totally integrated yet- but this would be true of any change.

The key is the tests.

We hadn't included them until a month ago.

The Developers like them, as does the Design Team since it helps us all catch mistakes quickly and easily... if the design team missed specifying something, we revise before the specification ever leaves our browser.

And of course, Agile Development is test-directed development, we're getting closer and closer to that standard as well.

All in all, some fine changes.

tech development Tech Development

Fingerpointing

Scot Witt, Friday, January 11, 2008 @ 10:13 am

My index finger is about to explode.

Some clients  cling to the 'us versus them' mentality of old school
development. You know:

Them: "It says here in your very own document that when I click <Massage> the back panel of my chair would start vibrating, and it doesn't! Fix it!"

Us: "But the master document clearly states you need to install a Yamahoochi 45697 Vibrating Chair Back for this to operation correctly"

Them: "Where?"

Us: "Master Document 123, Section 56, Hardware Requirements, Sub 876, Chair Backs, sentence two."

Them: "What page was that again?"

Hoisted by his own petard indeed.

I was reminded of this recently when I asked a client why
his team was doing the fourth review of a specification about which we
just ended an hour long conversation. Her comment was, the
specification didn't accurately represent field which
they wanted set to read only. Originally they wanted to be able to change it.

My fault. The specification was written 9 weeks before, the client never reviewed it (nor did the development team). The changes were minor and the conversation had nothing to do with the field.

So the client initiated another full blown review of the specification, four days before we're supposed to start prototyping it.

I missed two areas I should have changed. The other four, I changed.

I am reminded getting everyone on the same team with the same dedication to assisting
everyone else appears to be an never ending
goal.

In a former life, I was a Senior Technical Writer on the Cause Team for a chemical gases company that had some fabulous tools for determining root causes.

Very good idea.

Very kewl explosions.

It turns out that checking to see if an LP cylinder is empty with your cigarette lighter is not a really smart thing to do.

And it's a really bad idea to lay blame and be done with it.

On an Agile Team, when fault occurs, no one's happy. The better idea is to ignore the person and deal with the fault.

1. Find the fault (what happened?)
2. Figure out the cause (why did it happen?)
3. Repair the fault (repair how it happened)
4. Make sure the fault cannot occur again.

My Six Sigma Green Belt is pulsating contentedly. Not so strange. The idea behind Six Sigma was Motorola's desire to reduce manufacturing faults to three per one million units produced. The mathematician/Speakers of Greek tell me that's what Six Sigma means. I just took a seminar, filled out a 34 page application and took a test- I dread the thought of getting a Black Belt.

When a team is developing something brand new, we're in a creative thinking space, Much of the time, some of the holes of the new pieces don't match up on the machine. Or the client remembers or sees something else that absolutely positively has to be included. Or we can make the end user's job easier and make them more productive in user testing .

So the Development Team rarely points fingers. In fact, most of the time I've seen the developer whose work is brought into question turn bright red and pressures him or herself to get a fix as quickly as possible. Everyone on the team looks for answers. And everybody learns as well. That's one of the reasons Agile Methodology for medium and small projects works best with highly motivated and senior level folks.

Which means I'm gonna keep my mouth shut, fix the specification and get back to the other stuff I have to do.

You'll have to excuse me for a little while, though.

I'm gonna go find an Ace bandage, soak it with water and apply it to my index finger so it doesn't explode.

Technorati Tags:

Powered by ScribeFire.

tech development Tech Development

Agilize Your Project Just Before the First Release- for Fun and Profit!

Scot Witt, Friday, December 21, 2007 @ 5:35 pm

You're a full year into a multi-year multi=million dollar  project but the first actual release is seen o the horizon.

What does everyone do naturally?

PANIC, of course.

This time there was reason:

  • Your deliverables have been fine to date and the architecture is rock solid (just as you promised)

  • The Business Team is killing the Client Sponsor because the business team has exceedingly high expectations that should have been managed better.

  • Your Client Sponsor is getting angrier and angrier because his reports people can't do parallel testing on the old and new versions yet because your application still has issues. He originally planned for six months of such testing and might get two weeks under the existing schedule.

  • Your Client Sponsor's boss is demanding more functionality than your team can provide in a month of Sundays as it prepares for the first beta release and code freeze.

  • Your DevTeam is pointing fingers at you and the PM because they suspect (rightly) the client will want features build through load and performance testing.

Well, what could have been a major disaster with a lot of egg running off a lot of people was avoided with a lot of team assistance and a lot of hard work. No wonder I like working on teams so much:

1. Analyze the Problem and Causes

We're in the first code freeze of my first Agile Project. It took a lot of doing.

The problem was:

  1. Exceedingly poor communication
  2. Lack of planning
  3. Lack of managing expectations (on both sides)
  4. Not using a more Agile approach sooner in the project than we did.

2. Experience Counts- Listen to It

Here's what our CTO (Chief Technical Officer) hammered into our heads:

  • Practical Agile Methods
  • The BA promotes communication between the Business and Technical Teams and acts as a day-to-day Project Manager for the Technical Team (high level- Technical Lead runs the team).
  • BA needs to meet and talk with the Client at least once a day (preferably with the IA (Information Architect).
  • BA runs the requirements gathering, documentation (just enough documentation), the non-SCRUM Meetings and handles the project calendar for the PM.
  • The IA is the interface and usability Czar/Czarina.
  • The Client controls the features/bug lists. But the feature/fix doesn't get on the list until the BA/IA translates the into documents the Developer can develop from.

Our PM is also the firm's Sales Director. He revised his role to be umbers cruncher/support for the BA/IA and Lead Developer instead of intermediary between the customer and DevTeam/BA/IA. Instead, the PM and the BA will buffer the Client together.

3. Take Concrete, Understandable Steps

Here's what I (the BA- Deputy Associate Assistant Project Manager In Waiting):

Defined terms for both sides in their own contexts. I originally started a Glossary of terms, but someone from UxD pulled it. It was never used, never updated ad never referred to. Never again.

  • The business side didn't know a checkbox from a checkbook.
  • The DevTeam had no idea what 'parallel testing' meant nor how deep it went (down to the field level for hundreds of transactions).

It got worse, then got a little better when we formalized the process and touch points. Now every feel confident in asking "what does that mean?" Oh, how my first radio news director would smile!

Explained, demonstrated and awarded control of the Agile-based process to the business team four or five times and adjusted it to make them feel comfortable in their Word, PowerPoint and Excel World.

I gave up on the business side using any of the new tools except the bug tracker. The wiki is an active tool for the DevTeam and a simple resource for the Business Side.

If they're more comfortable in Office, fine, the BA and IA will translate i the wiki.

Told the DevTeam categorically it had but two 'controls' on the process- agreeing/disagreeing to a list of iteration features/issue repairs and providing the Client options and potential results/mitigation strategies.

A Developer can ask why a feature is needed/wanted, but the developer can't say no to a feature. If there's violet disagreement, offer options, but when the client makes an informed decision, that's it.

Got both sides into two actual Iteration Planning Meetings to get an identified list of develop-able items together for the upcoming iteration. What a concept! Things began settling down with the first freeze/performance-load test iteration plan and eased significantly with the list for the first 'go live' release that follows immediately.

Despite my best efforts, the DevTeam wasted the two days I set aside for research and questions between the first and second planned iterations with little stuff like speeding up the transaction times on the servers.

Got the Client to think out loud. ow we have the rudiments of a road map. Another planning tool!

Early Results:

The respect meter is consistently rising on both the Business and the DevTeam sides since we moved to a more standard.

Now don't get me wrong.

When we started, only our highly experienced Architect was Agile proficient and he was moving us to this sort of practice. We needed a lot more leeway to get the base functions designed, win client support and rapport as well as train the team. But as usual, communication is always the first casualty in any engagement we needed planning and giving the features over to the Client badly. Hence the major change a bit earlier than expected.

Things are a lot calmer, the client is more satisfied now that he knows where items he wants may be developed (we're Agile- these plans and iteration lists are like vaporware- useful only to make everyone realize that any change means a push for the item originally planned for.)

I'll letcha know what happens as we continue down this path, but it looks really good and will allow us to get automated testing implemented along with regression ad unit testing fairly easily from my perspective...making us test-based developers a lot sooner than I thought.

Powered by ScribeFire.

tech development Tech Development

The BA’s Role on the Agile Team

Scot Witt, Wednesday, November 14, 2007 @ 6:11 pm

Wow!

We just changed the model for our current big project, and it's no wonder I thought the BA Role was undefined.

I had been acting as an assistant-deputy-associate project manager, technical writer and QA Manager. Whatever the project needed, by gosh, was OK by me, and still is.

The side benefit is it makes it seem like I'm multi-talented, a very good thing come review time.

But now (drum roll please) there's a defined role for the BA.

Go figure.

In order to get the the base functionality up and working, the pragmatic approach worked very well.

But now, the client needs and wants control of the features, enhancements and repairs for the system to meet the business needs. Right up our alley.

We're moving from month-long sprints into two week sprints.

Sooooo, the first week into the current sprint, the IA and I discuss the requirements with the client for those items likely to be included in the next Sprint. We write 'em up and we frame the wires and get verbal client sign off that first week.

If it's a biggie, I'll slap a functional spec together with the IA's wire frames and work flow requirements.

If it's small, I set it in the issue tracker as an improvement with th details in the description field (I always wondered what that field was used for).

If the developers need more detail or discussions with users, I act as a liaison to get that happening without the client getting barraged by hundreds of IMs and e-mails.

I think I'm going to wish I was issued a stick.

But I gotta make that happen for the DevTeam, otherwise we can't produce what the customer wants.

The second week, I run the requirements by the DevTeam Lead for a sanity test. I'll probably flunk, but better to revise and have items really ready for the Planning Session on the second Friday.

I post the client's wish list in the wiki (can't get away from that dang tool, can I?) by Wednesday of the week before the sprint start.

It says here in The Handy Dandy Agile Methodology Handbook for the Perplexed that the developers have to read them!

In the SPrint Planning/Negotiating/Teeth-Gnashing Meeting on the Friday before the next sprint starts, the Customer ranks the items s/he wants in the sprint.

The DevTeam then huddles, makes interesting noises and then sets team estimates  (kinda like liar's poker when you watch it) and commits to a list it can handle.

Me and the PM then negotiate with the Customer to come up with a final list.

We break for coffee and a smoke and then go through a Post Mortum of the sprint just ended.

Here, everyone has to talk and discuss process (not people or finger pointing- as much fun as that might be)- including the customer and his/her team. Fair's fair, right?

If an item's actionable, the PM and I will meet with the appropriate lead and figure out some mitigation strategies or process change.

Then we're off to the races for the next round.

So, the BA's role in an Agile Project isn't all that different from other methodologies.

While 'control' of the project is now in the customer's hands, defining requirements and disseminating them differs only in that we're doing 'just enough' rather than 'kill hundreds of acres of trees with Word.'

Since the developers and the customers aren't running everything through the BA or IA (typical waterfall), we loose the 'translator effect' that intrudes every time technicalese is translated to rich bidness language and vice versa.

Even so, the BA is there to help both sides meet and mesh an understanding both sides can live with and understand.

The complexity is increased with an IA on board, but that complexity is more than offset by the IA handling project foundation work like 'task flow' (work flow to us BA-types) and they can whip up wire frames faster and prettier than I can. Those benefits combined with actual design to make the end user's job easier and more intuitive is well worth the the minor complexity issue.

With that big stick, I think I want a regulation Referee's Shirt as well.

<ding> <ding>

Next Round

Powered by ScribeFire.

Topics:

tech development Tech Development

Project Flow

Scot Witt, Monday, October 22, 2007 @ 12:53 pm

There are a lot of nice things about Agile Development from a BA perspective.

The one I like most is one of the corollaries that stem from the Agile Manifesto's decree that Agile Teams are self organizing.

Since I'm a consultant, I need to create a TLA (Three Letter Abbreviation) of a sexy, ridiculous (can you say 'mashup'?) or metaphoric term, send it to the marketing department and add 2-6% more to your bill because of my creativity. The Agiprop (Agile +Propaganda as opposed to the original Aggitation + Propaganda from the second red scare of the 1940s, get it?) I endow this new TLA as:

MEW
(c) 2007, Pathfinder Associates, LLC)
MEW is short for Make Everything Work. And you can say it out loud. Don't. You'll sound ridiculous. I was making a satirical point here.

Anyway, we decided prototypical use cases took too long, nobody reads 'em and we have to move fast.

User stories? Don't have a customer team member empowered to make decisions, much less write 'em. I'll write 'em with my best guesses and incorporate them in overlying functional specifications.

Well, said our SCRUM Coach, let's take a design meeting.

Monday: sketch, discuss, argue for an hour or two to model and generate agreement on each 'major' feature.

Monday through Wednesday:

  • BA (Business Analyst) guy heads off to create a functional specification and post to the wiki- leaving pointers for wireframes.
  • IA (Information Architect) goes off to create a wireframe.
  • BA and IA discuss informally when IA doesn't read what BA wrote or BA doesn't properly integrate wireframe intention.
  • Developers code base functionality.

By Friday, the functional spec cum wireframe is  on the wiki for the team to read, comment upon and prepare for final revision run through on the second Monday of the sprint.

Guess what?

Nobody read it until they started coding.

So Mondays now include a Review session, when the developer(s) assigned meet with the BA, IA and Architect to make sure we have everything covered- usually takes a half or or so before or after a design session.

Developers roll into the code with a vengeance and have a prototype ready to demonstrate to the customer on Tuesday or Thursday. BA takes notes, adds to the specification or to the backlog (as appropriate). This turns out to be our major interaction with an end user.

Typically, two demos are done for each simple feature- a 'rough draft' and, with user notes, a 'final draft' and we move on to the next feature.

The Team gets anywhere from three to eight major features rolled into each four week sprint with this routine.

We're about ready for the first code freeze for deployment of the beta, have 95% of the base functionality ready for a fairly complex web application and we're pushing down the bug list daily.

Not bad for a first shot at Agile for this BA. Of course a team of three exceptional Developers, a highly experienced architect and a wonderful IA made this team work well... with very few late nights or 'crunch' sprints.

I'm getting to like this while thing.

Next up: Are BAs necessary for the typical Agile Team? (Guess what the answer is)

Powered by ScribeFire.

tech development Tech Development

One BA’s Shifted Paradiagm: How I Became a BA

Scot Witt, Friday, September 28, 2007 @ 11:42 am

I've been a professional writer for more than 25 years- heck, I was stringing for the local newspaper when I was in high school. I spent the first 25 or so years post high school in the wunnerful world of Radio News. Then I figured it was a. time to get out of a dying industry and b. make enough scratch to help the kids through college.

So I spent 18 months on a help desk. Ugh. I have all the respect in the world for those special people than have the patience. I realized I don't. Anyone that 'names' their 'hard drive' Freddie seems a bit off to me.

So I took my minimalist technical skills (I am an amateur radio operator and had been playing with 'puters since the first TRS-80 came out- was the first on my block to have a Radio Shack Color Computer, connected to a black and white portable I traded for a 30-30 rifle I knew I'd never use) and my writing skills and declared myself to be a Technical Writer.

Wasn't hard. Except for Word. The organizational abilities and putting one word after another is pretty much the same.

Instead of story telling, I was writing incredibly difficult to understand Step Action Tables with Slot B and Post 34 merging into Compressor Cylinder 2 output going into the PDF to create an audit trail for  the Content Manager component of the  WinNT4.0 Server Security Accounts Manager.

There's a reason technical writers are a dime a dozen. In my experience, many can't write their way out of a paper bag. Many of the really good ones reinvent themselves. I always stayed with the really good ones. And I watched, read and asked for help when I didn't need it but wanted another point of view.

So I was consulting as a 'Content Manager' (read: Metadata Classifier), which was about 10 bucks more an hour than a tech writer gig. Momma didn't raise no dummy.

At a couple of application design sessions I noticed a couple of people who called themselves Business Analysts. They were very well dressed. Had nice shoes. I asked around. They made $20-$50 more per hour than I did. And they weren't bored.

I'm in.

  • I read about UML. Process. Modeling. Seems pretty straight forward- that's what writers and tech writers do.
  • I wrote a few cost-benefit analysis papers. Templates. They work!
  • Use Cases- hmmm. Need another book.
  • Action Diagrams- VISIO is a wonderful application.
  • Iteration. Yeah, makes sense. If at first you don't succeed...

Kewl. Now I Are a BA.

Some observations as a BA on a few projects:

  • SMEs (Subject Matter Experts) don't seem to think their company spending 34 gazillion dollars (that's a real place holder- a 1 followed by a jillion zeros) for an application is really that important to them. Which means I don't get all the requirements- no matter how many questions I ask, how I ask them or search the company's archives.
  • Nobody seems to think my Use Cases and fancy schmancy VISIO diagrams are important. So they ignore them. I don't get sign off.
  • Um, why, oh why, does the manager in  charge of part of the project keep coming up with new stuff she wants? Who is she talking to and how do I find a ninja when I need one?
  • Hey! Mebbe you forgot to tell me you needed an interface to the U.S. Department of Heavy Handed Security, but the week before deployment is not the right time to tell me!
  • Am I the only one who thinks four months planning the first phase of the project is, I dunno, excessive? Do we really need to dot all these i's? As long as we identify traceability to the requirements, isn't that enough?
  • If the customer has the domain knowledge. And the Development Team has the technical knowledge. And if both sides want the application to work and work well, why is everybody pointing fingers at the requirements documents and the Statement of Work? They all signed off on them, didn't they? See second bullet.

Well, Bunky, some smart guys realized that and didn't tell me about it until I got my current job.  No, it's not a panacea. But it works a lot better for medium and smaller applications.

And no one points fingers.

Because we're all on the same team.

It's called Agile.

Next up, coaching a UML-guy into Agile.

Technorati Tags: , , , ,

Powered by ScribeFire.

tech development Tech Development

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

Scot Witt, Friday, September 28, 2007 @ 11:41 am

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.

Hmmm.

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!

Cool.

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...

Excellent.

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.

Topics:

tech development Tech Development

Word Begone: A Brand New Way to Document Requirements

Scot Witt, Tuesday, September 25, 2007 @ 8:54 am

So I grab my project notebook and amble into my first Agile Modeling session. I think me and my templates are ready. I read a coupla web pages on Agile and this should be a snap

What was that word? Hubris, yeah.

I had spent months getting those Word, Excel and PowerPoint templates ready- from the ones I stole (er, um, ah 'folk processed' as we folk music aficionados call it) to the ones I had to create myself.

Even today, I have my security blanket templates on my laptop and safely archived at home:

  • Four versions of Vision/Charter documents
  • Two Cost Benefit Analysis Finding templates
  • Six Use Case Templates of varying color and table divider thicknesses
  • Four Business Rule documenter boilerplates
  • Three Excel Project Trackers
  • Five model Project files
  • Three Business Rule/Use Case Catalog blanks
  • A wide variety of VISIO stencil items
  • Two Decomp templates (on for PowerPoint and another in Word)
  • Functional Requirements boiler (To Be and As Is States- a secret- you can use the same template for both!)
  • A couple of horrendous templates that include one each of the above in monstrous detail.

As I sat in my first Agile session and discussion with our new Agile Coach, every instinct, every pat answer and smart alecky comment I usually make were absolutely, positively wrong:

On an Agile Team:

  1. The weeks long process of generating a mound of paper or lots of files on a network share are over, Amigo. Both the Business and the Dev side only want 'just enough' documentation. Napkin diagrams, digital pictures of the white boards are fine. ('Horrors, developers actually writing stuff?' I thought to myself.)
  2. The BA doesn't 'own' anything- it's sort of like Developer Socialism- everybody has a piece of the action and my not-yet-written documents. ('So, like, what the heck do I do?' I whined to myself)
  3. There ain't no catalog of use cases- you can do the same thing with three line User Stories. 'User Stories? Yuh mean the customer actually does something other than yell at us?')
  4. The developer actually talks to the end user! No translator (me, BA, out of job, must find waterfall/UML gig, soonest)

And none of those kewl templates and fancy-schmancy colorized customer-eye-popping stuff will ever be used.

Because we're putting all of this stuff on a wiki, the Coach told me.

I said, God Bless You.

I didn't sneeze, sez he.

That's what worries me, I responded.

Next Up: I use Word for the last time professionally.

Powered by ScribeFire.

tech development Tech Development

X: Consider Information Mapping

Scot Witt, Monday, September 3, 2007 @ 12:24 pm

Ah, Information Mapping.

When I lost a job interview because i didn't have it, I got to wondering.

It's a 'method' for technical writing. Allegedly it allows even non-writers to generate spiffy new documents within a proprietary template.

Well. Not really. What they're selling, really, is research for presentation and a simple method for organizing the stuff you need to plop down on the page.

I think anyone who can write a college-level expository theme or research paper and got a B or higher already knows much of this stuff. I went through a couple of modified-for-the-company-I-was-consulting-at mini-courses. I was bored. But, then, I've been a professional writer since I was 18 ($5/story for the local newspaper).

For the non-writer, this might be valuable.

The most helpful part of Information Mapping is the very functional way the coursework helps you organize your material. Pros and English Teachers call this 'organization' or 'outlining.'

Information Mapping calls it 'chunking,' a valuable technique for the frightened word smith.

The idea is to organize like with like elements until you reach a magic number (7). If you go over the magic number, you 're-chunk' (reorganize) into smaller, bite sized pieces.

This is the meat of the course, and probably worth it if you are afraid of writing.

The problem is the templating. The organization spend dozens of dollars (OK, that was a joke) to 'discover' what the rest of us already knew:

  • Labels and sub-headers: good
  • Dense text: bad
  • White space: good

But. The sub headers do not need to be 6.764536 inches from the left margin, nor do summary boxes have to be flush right. Yes, their templates are pleasing to the eye. But any designer or technical writer can design pleasing and easy to use templates in a half hour or so. And I'm sorry, I do not believe readers will tolerate incomplete sentences nor Washington Irving-style single paragraph sentences.

And any technical writer know two ignored rules of requirements gathering when executives will be part of the audience:

  1. If you find a color printer anywhere within 50 miles, use it.
  2. There has to be a pie chart in the requirement somewhere. It need not mean anything. I just has to be there.

Another great thing about Information Mapping is the realization that requirement documents have multiple audiences. Information Mapping explains how headers and sub-headers, labels, tables and formatting help your audiences navigate and skim your work. Nothing a good technical writer doesn't already know:

  • Make your labels mean something and actually describe what it's labeling.
  • Don't add a graphic just to add a graphic- make sure you can explain why the graphic had to be there.
  • Please, please, please, please use boldface, italic and underlining to an absolute minimum. It looses impact when every other line has some text enhancement.
  • Limit yourself to two fonts in each document. Otherwise you look silly. One serif font, one san serif font. Use one of them for headers, captions, table data and labels. Use the other for body text.
  • Consider us older folk and those with poor eye-sight. Them little serifs screw us up. Keep the body text to sans serif, please.
  • Summaries- executive and section are always a great idea.

The courses get you up to speed fast and are of good quality. But your local community college is another option and a lot cheaper. All offer writing and many offer technical writing courses.

Powered by ScribeFire.

tech development Tech Development

IX: Writeth As Thous Speaketh, Else Pomposity Resulteth

Scot Witt, Monday, September 3, 2007 @ 11:50 am

OK, I'm going to start this one with a question:

What is a lyric?

Wrong.

Dictionary.com defines it as: Of or relating to a category of poetry that expresses subjective thoughts and feelings.

Don't feel bad, I got it wrong, too. And I took four literature courses in college.

The point here, is what you think you're saying ain't necessarily what your reader  picks up.

Are you a David Letterman fan? Me, too. But every album -- sorry- showing my age-- CD, book or movie he's plugging for someone is 'entitled' xxxxxxxx. Sorry, Dave. That's why you were a C student at Ball State and endowed a scholarship for average students. The CD, book or movie is titled, it's not entitled to a dang thing.

And, Dave, it makes you sound pompous- but a delightfully ignorant pompous.

That's why I used to read my stuff out loud. I learned if I wrote the way I spoke (talking is pretty much writing without the thought, organization and presentation tips), I'd be pretty close in terms of vocabulary, active voice (it's pretty hard to speak in passive voice unless you're talking to a cop or a lawyer) and audience understanding.

Leave the three-plus syllable words to the academics, Scrabble (tm) and your crossword puzzles. Real people have to read and understand your stuff.

  • Orient is a three syllable word. Orientate means the same thing. Guess which one is pompous?
  • Initiate is a really cool word. Start is simpler.
  • Yes, Inflammable means the same thing as Flammable. But is your 87-year old neighbor going to understand that in a crisis? Use Flammable.
  • Utilize. I still don't understand why this dollar word is useful. Use 'use.'
  • Integrate makes you sound extraordinarily superior. But unless you're a software BA, add or include are simpler and mean the same thing, depending on the context.

There are four or five gazillion more examples. Edwin Newman's book, Strictly Speaking, got me looking at word use back in high school. Most of the time I smile to myself when I see and read them. Others are like finger nails on a chalkboard.

So I'll end this one with a question:

Why would you want to be considered an under-educated writer or a pompous you-know-what?

The Last Commandment: Chunkin' to the oldies.

Powered by ScribeFire.

tech development Tech Development

Commandment VIII: Suffer Not Tables, Bullets and Numbered Lists, For they are as Lillies- They Spoil Easily

Scot Witt, Monday, September 3, 2007 @ 11:25 am

Ever see a bulleted list with one sub-step?

My teeth gnash. Literally. This is almost as bad as your boss writing 'your' when s/he means you're. ARGH!

Here are the rules. I've never had to break these, except for wikis:

  • Use a numbered list to show sequence or order.
  • If you use a numbered list, fer gosh sakes, pick a consistent numbering system for sub-items. Wikis exempted, of course since most wiki numbering systems pretty much suck. I should amend that. The ones I've used suck.
  • Use a bulleted list for any list of two or more. This shows an association between the items in your list.
  • I know. You have 45 levels of information you have  to have displayed in relation. Wrong. Good technical writers will tell you if you go below two levels you pretty much lost your reader... sometimes you simply have to use three, but never ever more than that. Split your content up if you need additional layers. Combine the layers. But do not go over three levels, ever. Even in your Table of Contents. No one reads past two or three anyway.
  • Never, ever place a 'widowed' list sub-item- stick it with its parent either by using a conjunction (and, but, or; if you're writing for executives, however) or using a period and adding the outlier as a separate sentence. Setting an outlier as a sub-item, all by itself, is for the unschooled.
  • Consider using a table for more than three (3) items.
  • Always use a table for five (5) or more items. Yeah, yeah, I know. If you graduated from Information Mapping 101, the magic number is seven (7). That's fine, but have a limit in your head so the rest of us can read what you wrote.

The whole idea is to organize and display the information so your reader can easily spot it, read it and digest it.

Lists and tables help a great deal on the other end of the communication process. The reader may not know it, but you've shown sequence, order, association or massive detail just by properly organizing it.

Like my wife, a cheap date.

Did I say that out loud?

Next up: Pomposity and You.

Powered by ScribeFire.

tech development Tech Development

About Pathfinder

  • We design and build extraordinary applications for companies looking to make the next great idea a reality.
  • learn more

Topics