Archives

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.

Share/Bookmark

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.

Share/Bookmark

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?

Share/Bookmark

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.

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

Share/Bookmark

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: fault finding six sigma team

Powered by ScribeFire.

Share/Bookmark

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.

Share/Bookmark

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.

Share/Bookmark

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:

Powered by ScribeFire.

Share/Bookmark

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: Agile, UML BA, business analyst, watefall, iterative

Powered by ScribeFire.

Share/Bookmark