CBAP and Me: Why I'll Have to be Dragged Kicking and Screaming to Study for that Test

It must be me. Companies are all piling on and requiring CBAP (Certified Business Analyst Professional), offered by the IIBA (International Institute of Business Analysis). Check this out: IIBA CBAP Stuff.

Excellent work (I surmise it's from the IIBA BOK or Body of Knowledge) and an interesting summary of requirements gathering.

See, this is why I didn't take the PMI (Project Management Institute) test for PMP (Project Management Professional) . After going through the boot camp and finding out what that test was really all about, I didn't say no, I said Hell No.

That test is a measure of how much you can memorize about processes and procedures you wouldn't use on a project in a million years. Yes, having a methodology is a good thing since it can be the backbone of projects you come into cold. But more often, the PMs I see using the PMBOK (Project Management Body of Knowledge) are much more concerned about keeping their Microsoft project plan nice and neat and pretty much leaves the real work to the project team.

Obviously there are exceptions and there are some really dynamic PMs around.

So I looked over the CBAP requirements.

Modeled on PMI. It takes about three days just to finish the application.

So I really have to wonder if memorizing really tells your client or your end user that you are an effective and ethical BA. Wouldn't previous folks with which I've worked be a better read on how well I do my job?

Is this CBAP stuff going to help me create a gaps analysis? Vision Statement, Statement of Work, Status Report?

Will it certify I can help a developer on a spike/sprite and research quickly and efficiently?

And what will a CBAP certificate on my desk (we don't have walls or cubes) certify I can write an acceptance criteria on a User Story? Identify controls with the UxD expert? Model Workflows? Group the workflows into scenarios with the designer? Setting up a a one to one mapping of my Actors to her Personnas?
And, oh yeah, I'm hearing these certificates are now good for Agile methods.

I think mentoring folks who want to become BAs is a better idea. Have them, I dunno, research and write some use cases? Listen to how they question end users and stakeholders- create questionaires- create a risk or a couple of communications plans. During the project are they quickly and efficiently revising the artifacts?  Are they doing sanity checks against the end user and business requirements?

So instead of memorizing, I'll learn what my client needs, how the end users will use the software, run JAD (Joint Application Design) meetings and work with the UxD expert to figure out how we're going to meet the stakeholder's requirements in the best way for end users.

In Agile, everyone on the team can and do help out where ever they can. I'll do that and help let the Devs develop.

I think that kind of study time is well spent.

Agile in a Regulated Environment

Now, I don't know what happened when the Initiation phase was done a year ago this month, but I know what I've been doing since October on this project for a healthcare hardware maker.

It's been a while since I was exposed to FDA and HealthCanada and European Common Market regulation- and even then, it was a glancing blow- for medical gases- pretty straight forward.

With testing equipment, the load's a lot different.

The Agile Principal:

"The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation."

Is pretty much thrown out the window. Like Waterfall, paper seems to be king.

So we adapted. We put all the User Stories, comments, hazard analysis and developer notes on database changeson our wiki. A junior team member goes up to the wiki, picks a User Story, then uses  a <ctrl><a> and <ctrl><c> to save it in the clipboard then<,ctrl><v> to push it to a  Word template, clean it up and then go back for all those nice pictures the devs and managers like (because they never read the tests- sorry- Acceptance Criteria; actually, we have one dev who really reads the stories- shocked the bejesus out of me). Curse me for making Work Flow Diagrams!

Then, we add the title to a spreadsheet template with 6 to 12 bazillion acceptance signatures. Seriously. Signatures. And we get 'em, too! Then save 'em, batch print them to annoy non-project staff.

Add a test case result sheet from the QA guys (who are the only others who actually read the stories- sorry, this a class project; there's someone else who actually reads the stories, we have an actual tech writer stealing hours from my time card), a paper clip and then it gets scanned into some other application that actually freezes the User Story's state and requires an Act of Congress for a change.

This also scares me. I don't spell that well, my grammar's off sometimes when I forget 7th grade sentence parceing and I forget stuff when I'm getting whipsawed while writing a story-editing the one from last month the to which the QA team got (how's that fer grammar, eh?)-seeing my product owner making the mistake of walking by so I can grab him for just a few questions- redoing what the QA wanted me to do because he called me on a quick change instead a comlete job- and a dev asking me questions about a story written a month ago.

So, you're likely to see a few numbering, um, issues and a single word from a previous requirement I forgot to delete. My editor, who happens to be the Risk Analyst and the fellow that wrote the original version of this software, just caught two more of my , er, issues.

So the big changes the team had to make are:

• Realize we have throwback to the Waterfall/Iterative demand that 'Documentation is King.'  We created a process that isn't too heinous, but keeps the stories short, to the point and on the wiki as the primary story keeper while meeting our customer's documentation requirements.
• Sign-offs are not a simple head nod in this environment. In fact, sign-offs are worse than Waterfall.
• When you do the sign-offs after implementation (and after the head nod), it becomes a paperwork process you can hand off to a junior level team member so it doesn't get in the way.
• HIPPA, Good Manufacturing Practice. The Regulatory Guy (Gal) is the king after you meet the business needs.
• Scot needs a remedial English Course. You don't gotta know how to spell in radio.
  

Down and Dirty Baseline

Management wants As-Is documentation for its existing application. It handles billions of dollars each month. And the developers have already started working on the Manufacturer side of the application and want a lot of code and reporting re-use. I'm with the Dealer side.

Coding starts in mid August.

How to get this done was the first meeting I attended after my company laptop was issued and I found my cube int he farm.

I suggested a light weight requirements process- a description of current functionality, a screen capture, a process flow activity diagram and functional descriptions we can infer from playing with the application. Once these "use cases" are complete, we'll walk SMEs through them to correct errors, add stuff we had no clue about and the like.

We will have the required baseline done in a very short period. Enough to do a Gaps Analysis of Version 1 compared to plans for Version 2.

So far we've created a "use case" number and title for each major major page and cross referenced to menus.

It seems to be working- at least the boss is very happy check marks in the tracker are increasing in quantity and the 'now published' announcement e-mails are coming a lot faster. The BA team has access to the QA/Development environment. I got the Create User doc done in about a day and a half. The current system, as you'd expect, has had several changes over the years and is, um, complicated.

Abstraction is a wonderful thing.

Since Create User is the first major design issue, I'm already talking about Version 2.0 with the IA/Designer as I delve deeper into this really cool piece of work that has combined two or three legacy applications and several upgrade security tools. This archeological stuff is interesting. The boss is a SME and quite amazing himself. So this isn't going to be the cluster ***k it could have been.

I'll letcha know. This Agile stuff works great. But of course, you and I already knew that.

Double Jeopardy with Cheese

I'm back in the networking business again- out where a friend is a friend of a friend of a friend.

Told you I was into folk music! I just folk processed Gene Autry's theme song right in front of you. Folkies call it the folk process. Everybody else calls it stealing (if Arlo Guthrie didn't say that, he certainly inspired me to write it).

Disclosure/CYA: There isn't just one company that does this, I've found, but McDonalds is is notorious for it.

Yeah, I'm hunting for work again.

Reminds of something I didn't complain about before: Disqualifying candidates who are submitted twice to one job.

Here in Chicagoland, we host a lot of large corporations. Most of them use consultants because we're throw away when the executive decisions come down or that particular area can't hire anyone more (they call a job 'head count,' which makes people who use that phrase without smirking, head cases, I think).

These larger organizations pick about a half dozen body shops, sorry, consulting or recruiting firms and, after proper computer connections for hiring and payroll and time logging (yes, payroll and time cards are separate things when you're a consultant- at one place, I had to enter and track my time in three different systems) these body shops are designated as 'preferred.'

Now the 'preferred' body shop....er consulting firm is the only type of firm with which the large corporation will deal. For the company, this reduces payroll and recruiting costs because the body shop... er recruiters are already vetted and on the systems required.

The consulting firm is then placed on an unofficial, off-line discount system, like Captain Kirk's Price Line. Smaller firms go through these preferred firms, discount a few dollars an hour off the contractor's overhead.

This can increases the cost of the contract or reduce the amount the contractor receives.

Guess which one usually happens?

Then, the large firm starts recruiting for itself, knowing that each hire/contract will cost it less than using a recruiting firm.

It also means us job hunters see job...er...'requirement' adds on the job boards with slightly different titles- some radically different- but the exact same requirements. We'll see adds from three sources:

• The company- since it saves even more dough if it hires you.
• Several preferred body shops. These recruiters make sure we know it and it's supposed to mean something to the contractor- trust me, very few of these 'preferred' firms will ever find you the next job. No matter what the recruiter told you when you were considering it. It;s sort of like military recruiting, I guess.
• The independent small or individual firm which funnels candidates through the preferred companies.
• The companies that employee green card holders well before the card holder should be speaking on the phone, much less trying to recruit you.
  

Great deal for the company. Really screws up us job hunters.

Now, to add to this circus, the large company disqualifies candidates who have more than one application for the contract.

Oh yeah, they often open multiple BA slots at the same time. They don't tell you what each opening is for which area-department-building-manager. Many times the job descriptions...sorry...requirements are boilerplate, templated copies.

Nice, hunh?

Now, we learn fast and we can describe your As-Is processes pretty well in a few hours. To-Be may take a while, but by the time those two models are working, we pretty much know your business.

So, why on earth, when some large corporation knows there are a gazillion ads for its one position, would they disqualify a candidate for two or more submissions or the lack of domain (industry) experience?

Industry knowledge can be helpful, but a. most businesses run pretty much the same- scaled, but the basics are all there no matter the company b. the BA is supposed to find requirements, processes, pain points, potential business opportunities and junk and c. It takes us only a few hours to learn and abstract the company's As-Is state...so the designing can get underway.

Seems to me, such HR "experts" would sort of want to pass such a candidate's resume on to the hiring manager. The candidate has been vetted by more than one firm. More than one person thinks the candidate is qualified.

This proves, at least to me, what we've all been thinking about for years:

Human Resources main purpose in the hiring process is to eliminate as many candidates as it can rather than find the most qualified candidate.

Oh yeah, one other thing...your HR software sucks, companies and recruiters-especially you recruiters. I continue to get recruited for: Java Developer, .Net Developer, Project Manager, Compliance Analyst, Help Desk Agent, QA Analyst. The software uses keywords and buzz phrases. Stop It. Or get analytical software with some basic understandings of keywords, searching and finding information. I worked in this area- and your stuff sucks.

Sort of like the way many IT folks use the word 'Agile' as "the next great thing." But that's another rant.

Stay tuned.

Big and Small

Well, it's been about a month.

I'm reminded constantly that I'm working at a big....large...um...HUGE company and the stuff I learned at the fast-agile firms in recent times ain't gonna cut it.

The saving grace is that I have the time to anticipate, to talk, to work things out with the really smart people I work with. And that's not a bad trade off.

Yeah, it sucks having your laptop locked down. It's worse using Internet Explorer 6 and Office 2003. But I'm beginning to understand why.

This company has about a gajillion (that's 1x10+3 higher than a bazillion) laptops and PCs out in the offices. I remember one agent's kid putting a Golf on his Agency PC. The kid didn't install it correctly and Dad's PC was toast. Of course, it was the IT department's fault.

So, a little sweet talk, a few sentences about how technical my gig is and a superb boss, I got local admin rights to the laptop, M/S Project, IE 8 and Snag It installed. OK. They gave me Snag IT Release 8 and Techsmith just released version 10- but 8 still has that great little image editor- which means I don't have to ask for PhotoShop.

I've been relying on the "people skills" I learned as a Parachuting Business Analyst (drop in for a few weeks and off to the next project). Yes, I should have learned these skills years ago- but a radio news guy is supposed to be a curmudgeon.

So, I've been listening carefully, holding off riffing with my strange, yet obscure sense of humor; until I know you very well- and even then I'm careful about my jokes. It's hard, but it beats getting fired. And it seems to be working pretty well.

I'm also trying really, really hard not to interrupt someone when they're speaking. Then I went to a status meeting of the Enterprise Architects. There wasn't a topic that didn't result in at least one interruption- except when the Director spoke. Hmmm. Kinda funny, no?

I'm using the extra time to extrapolate requirements and high level designs for what could be a terrific Capture/Store/Disseminate system based on existing, every day tools with a little bit of extra horsepower. If this goes the way I'm thinking it will, the only real issues we're going to have are cultural. But we're on top of that, too.

I'll ask the boss what's proprietary and what I can talk about as we go through the process. I'll letcha know.

I really like this gig- and I've been there for about a month.

Enterprise Architecture: Lincoln Logs for IT Folks

It's been a couple of weeks and everything seems to be going well.

I'm working with an Enterprise Architect. As a sort of junior architect. The boss calls me a Knowledge Management Specialist since we're working on cool stuff like search engines, wikis, knowledge capture and knowledge dissemination. The gig's pretty high in the food chain, but I haven't stepped on my di....um....made a major mistake yet. 

Relax. I didn't know what Enterprise Architecture was, either. And no, you don't get to design and build large companies in an artistic way.

It turns out, Enterprise Architects are like BAs, but on steroids.

They ask the questions when someone in a large organization wants to add, improve, replace or remove something. The architect makes sure the IT organization's standards are imposed on new projects at conception. The architect thinks and plans how new technologies will or will not fit and how to scale applications into usable tools. The architect makes sure the data is sourced and accurate (Oracle and SAP anyone?). And that everything is properly licensed, copyrighted and implemented.

The architects shepard projects through the minefield of IT Governance (that's big time talk for who's in charge of the 'puters).  After the Architects get the major questions answered, they 'architect' the project. How does it fit into the mix of applications? Where should the database go? What kind of data base should the application use? How do we get the data from point A to point B. Document it. You get the idea.

There are Data Architects, Information Architects, Application Architects and Content Architects. There are probably other Architectural Types I haven't met yet.

The big difference between an Enterprise Architect and a Business Analyst is that as a BA, I was only worried about my project and how my team got its stuff done. This is as it should be.

But suppose the organization has 60-100 project going at any one time and a third of the BAs are like me? You know, Pragmatic and Focused so my boss looks good. Everyone would be pushing his or her project or portfolio. A mess. A chocolate mess (to those younger than Boomer age, that's how M and M Mars used to advertise M&M candy).

On this side of the Project Management Office, we're looking at how these projects support IT plans, objectives and how they fit into the mix of stuff already available. We got that information from the business. Because the business pays our salaries. And we like our salaries. The words 'align' and 'alignment' are used a lot. Align means do it the way the business needs it done to impact the bottom line, not the way you think it should be done.

So the boss wound up the key sticking out of my back (you know, where the recruiter and HR knives went in?) and set me onto five projects. Knowledge Management Projects (I feel like Bill Murray's character in Stripes when the General asks him what kind of training his platoon completed). Short leash (heck, it's only been a couple of weeks) but fun as all get out.

I'm drawing diagrams in VISIO, I'm writing up Business Rules. I'm creating project plans in Excel (having taken the Project course this spring, I'm sticking with Excel until I have to turn out a plan in Project- there's so much crap in that program you never use, it's results are counter intuitive and you can't adjust the defaults- and don't get me started on task numbering!) and having a lot of fun talking to Subject Matter Experts and Stakeholders.

See, I did a lot of KM back in the day. Much of that stuff had to be created custom in the 90s because, at best, folks were collaborating on NetMeeting. Word Docs and Spreadsheets floats around the world. We didn't know from WebEx, GoogleTools, Open Office, Instant Messaging, Twitter, Tweeting, Twisting or Twining.

That's changed. And it's an exciting change. And that's what we're gonna see: How Scot adapts to the Enterprise View and Knowledge Management 2010.

Tune in again, friends. Same Bat Channel. Same Bat time! (for the younger than Boomers out there- that's how the TV Series, Batman, used to sign off on ABC. Jeez, doesn't it suck to have a joke explained?)

Job Hunting Lessons Learned

OK, last job search rant-- I start a new gig on Monday, Finally.

Here's what I learned:

• I need to be comfortable with my resume. Changing job titles or 'punching up' qualifications is dishonest. Screw the recruiter who wants this done.

• Recruiting 'experts' tell you your resume should be one page, no more than two pages, well, you can go to three if you're really qualified but you really need the last ten years. Screw that. I'm a consultant. I do different stuff on different projects. Even edited to the bone my resume takes five pages. My vitae is around 30. Could I edit it? Well, sure. But these HR software programs are looking for keywords and no one knows what those key words are. New resume for each job. Yeah, right.
  

• Each recruiter has the same wind-up and pitch. The good ones are laughing while they do it. There are very few good ones.

• I have never, ever, gotten a job from a downtown Chicago recruiter. Every time they demand I show up, I've wasted gas or train fare and/or parking money- around $40. And you are never reimbursed for it. When you're getting all of $314 per week for unemployment compensation, that takes a lot of nerve. From now on, I'm going to invoice them for my time and cost of travel next time.

• If the hiring manager pauses slightly after you ask about next steps and says "Our process is a little cumbersome...." Hang Up. Immediately.

• Don't get old in a job that pays more than $75K/year- Ageism, it's real.

• Don't be real good in the job you had that paid more than $75K. It means no one will consider you for a lesser gig...anyone see a Catch 22 here?

• A lot of HR people are flakes. Seriously. I think most of them are Psychology Majors.
  

• A lot of hiring managers are worse than their HR staff (see above). I think these people are at the other end of the spectrum: Dilbert.
  

• Does anyone else see the logical flaws in these massive meetings of 'networkers?' Why would I network with people who don't have a job? And am I the only one who feels silly about 'power networking?'
  

I've been told its because they may know something I don't.

Whaaaa?

You're telling me an electrical engineer is going to know when a software development firm is going to hire a BA?

Right.

I'm only going to network with people I really know.

One guy who tracked me down on LinkedIn aid he wanted my input on something and then spent an hour and a half on the phone with me. In boring detail, he told me how to get a job. It was such a good system that he had not only been out of work longer than me, he refused to introduce me to one of his contacts when I actually tried it.

Networking is phony, counterproductive, a waste of time> Worse, it gives you the illusion of actually doing something. Stick with people you actually know.

• The job boards are pretty much populated by body shops. 
• Be careful of what you put on your Dice, Monster or LinkedIn profiles. The bodyshops, like HR software, have no ability discern nuance. I get a lot of matches for an IBM network tool called Tivoli. When I was with OCE-USA, we used a help desk software package called Expert Support. IBM bought the company that made it and put it into the Tivoli product line. Yes, my resume says Tivoli Expert Support.

They also can't read. I still get 'requirements' (when did a job become a requirement? When I became a number instead of a person?) for San Diego, New Jersey, Texas, etc. They want a BA for $25/hour for four years. When I reply and ask them to remove me from their listss, they started getting snippy in the last couple of months. "Well, your resume is on Monster,' or 'But your profile on Dice says...' Yes. It is. It also says I won't relocate...much less do it for $15/hour for a two month contract. What were you thinking?

 Do you know how many times I was called by the same firm for the same job from the same LinkedIn, Monster or Dice Profile? One job resulted in 57 phone calls over two days. Of those, 12 were repeats from four different recruiting forms. And I was already in their systems but they never looked. Can you imagine how much unused horsepower is in those databases? And I actually got into the finals for the gig. And I was into it until the hiring manager told me she wasn't sure if he'd promote from within or take somebody from the outside. And the job is a technical support role, not what I advertised(for a BA). I'm till waiting to hear from her. Not.

• There's a new business model out there- job sites are getting 'exclusive' listings and want cash money to let you see them. Some of them have free 'memberships' with 'basic' responses (JobFox, Ladders) and have unusually bad interfaces (JobFox- if the site has identified more than a couple of jobs for you, you're gonna be on line for a looooong time. And why is it I found more roles searching on aggregators than on the 'profile' on JobFox?).

• And what's the deal with the date resets, Dice? CareerBuilder? When you reset dates, a lot of us think there are new listings, when in fact, you're wasting our time. Stop it.

• Monster- didja have to go to flash? Taking a screen shot with EverNote is now impossible. And the log in i a pain in the neck. Stop it.
  

• The only good way I see of hiring anyone is to get a prospect vetted by an upper level whatever (BA, PM, Developer, Architect, etc.) and then either test the candidate or let me demonstrate what I can do for you. No one did that. I've had phone screens with development leads, Project Managers, Chief Information Officers, Chief Technology Officers, president, HR generalists and 'other team members.' I'm sorry. Once or twice I had a BA interview.
  

The answers are:

Hidden Requirements you never seem to be able to track down. Someone in Detroit has all of them neatly typewritten and three days before you're off the project he says, "oh, didja want that?'(Question: What's the hardest thing facing a BA?)

A simple abstraction of the process- in a step action table, it includes at least one identified Actor (human or system) with a quantifiable goal. The title should be Verb-Predicate with a unique number from a consistent naming convention. Oh yeah- success and failure states would be nice with an overview and context explanation. You also need at least one color graphic for the managers). NOTE:  Nobody ever reads it. (Question: What' a Use Case)

A quantifiable , 3-4 sentence abstract feature description with tests to determine if the feature is complete and is used to start the discussion between the developer and the end user. Can be placed on a 4x6 Card (Note: seems the Agile Book Authors have asked the Commissioner and 4 x 6 is the official card size) or on a wiki page. (Question: What is a User Story?)

An unidentified, highly educated and emotional visionary whose ideas kept coming and coming and coming. I shunted the visionary into a wiki Blog to capture the ideas and put them in the backlog and explained the process and why we had to concentrate on this small part of the project now so the business requirements would be met (Who was your worse client and how did you handle it?)

So how did I get my new job? I didn't. A close friend had a major project dumped on her at the right time, which allowed her to hire me for the third time. Not really kismet- someone who knows me, knows what I can do for her and her company (actually, my client company, now) on what I expect to be a major enterprise project.

Can't wait.

OK, let's get back to work and Analyzing Business! 

Ubuntu Test Drives

Well, I've had more than week to play with Ubuntu 10.04 and I think it's great. There are a few rocks out there, but overall, it's rock stable, feature rich and totally customizable.

Here's the good:

• Ubuntu, the Open Source Community and a few business have pretty much every application you want. For free. With source code. With the ability to contact developers easily to suggest improvements and features. In other words, Screw the Ribbon. Open Office has everything you need, fer free, there's one exception which I'll discuss in the Disadvantages list.
• It doesn't slow down.
  
• You can blow off PhotoShop. The Open Source Gimp photo 'manipulator' and Open Office's Draw Program pretty much have all the features of PhotoShop and Correl Draw for vector and raster graphics files.
• I've only seen one blue screen and it was my fault.
  
• Much as I love Winamp, Rhythmbox pretty much beats it in every feature.
• I can do without the Outlook replacement Evolution (fingers crossed) because, while it does everything Outlook does. I'm used to and like Thunderbird and its Lightning Add-In, I don't like the way Evolution' calendar works and I like having separated InBoxes for my e-mail accounts. This is obviously a matter of preference.
• There are so few of us using it right now (comparatively speaking) that the evil forces of Virii and Malware pretty much don't care about us. Hence- while you should still run an Anti-Virus Program and software firewall (both free, of course), there's not much out there to hurt your 'puter.
  
• You don't need Snag It. There are a couple of screen grabbers (free) that work very well.
• Ubuntu comes with Open Source versions of Disk Burners, E-mail client. IM client (that will handle all of your IM accounts in a single screeen), FireFox (Linux Version- slightly different), a video editor, video viewer, print manager... yuddah, yuddah. In short, you can get started right after the installation is complete with new, free tools that work as well, if not better than Windows tools and applications.
  
• It doesn't crash.
• There are three ways to download and install software. Two are very easy. One isn't. So use the Ubuntu Software Center or Synetics Package Manager to handle this for you.
• It doesn't crash.
  
• Wireless not only worked right of the box, the client actually knew what security my system has and just asked for the password.
• It doesn't crash.
• If you have a smarphone, the makers of Ubuntu have a new service called Ubuntu One (actually it came out with release 9.04, but I had no idea what it was).... a combination Boxnet.net (i.e. secure cloud file space) and activesynch (for Windows Mobile) on Mozilla's Thunderbird. If you use the built-in email client called Evolution which synchs right out of the box. I don't like its calendar since I'm used to Lightning o the $10 a month for the synch service and 50 Gb of free cloud space is a good deal. You get 2 Gb for free.
• It doesn't crash.
• It will integrate all your social media- including Instant Messaging, Web Services and e-mail in a superb user interface.
• Ir doesn't crash

Now there are some minor issues, nits, really:

• Once I paid my first ten bucks to Ubuntu One, they took down the synch to Windows Mobile option. Arrrrgh.
• While I can install Microsoft VISIO using the WINE application, and it will launch. It craps out very easily and consistently. Yes, I have a certified copy. I couldn't open a 2003 VISIO document and had to make due with creating a bunch of boxes in Draw. It worked, but was a pain. I use VISIO a lot, so I guess my next employer is going to have to gimme a laptop with Windows on it.
• Do NOT put your media files on an external drive and have that drive unavailable when you launch Rhythmbox. It indexes media files on initiation and  it has to re-index when you get your external drive up. You're supposed to be able to put media files up on your Ubuntu Cloud share, but I haven't had time to check that out yet.
• The documentation (web-based) is fine for very unsophisticated users and walk them through simple processes and procedures. You really gotta dig for answers on the community wiki or other websites if you have something more complicated than installing a software package from Ubuntu Software Center. I spent a half hour finding out what to do with a *.bin file containing a program I wanted. It was a simple answer (you right click on it, change the properties by adding 'execute' permission and taking out 'read only' permission and then double click it or right click again and select EXECUTE).

Would I install it on my mother's machine? I'm actually thinking about it. She gets so much adware and malware on her machine it's not funny. I'm thinking not because you do have to be a little technical.

For my wife? Yew betcha. But she's a developer using Visual Studio, so that' out.

The kids? Like a shot. Fast, malware and spyware resistant, FREE software and IT DOESN'T CRASH. Yeah, I'm thinking about doing a demo for them.

Oh Yeah---did I mention it doesn't CRASH?

Back To Work

I go back to work, this time as a Project Manager for a nationally known retail operation based in Hoffman Estates, IL. I'll probably start on Wednesday or Thursday, but fully expect the the start date to push to next Monday. Hiring managers at this place have a lot to do to bring in a new contractor. This will be my third go round and this may be the charm.

With an unprecedented positive recommendation from a previous IT manager, the new boss was pretty well convinced he'd hired me before I came in for the face to face interview. That's what the recruiter said. This time he was right.

That was amazing. Thanks Nancy!

As usual, it took less than a day to get confirmation for the contract. Every job I've ever gotten resulted in the offer or confirmation taking hours instead of days. Once or twice it took as long as two days- but never any longer. In the latest round of interviews and waiting for the rejection phone call, e-mail or letter, I think offers were extended to other people (when I made it that far) and I was the 'back-up.' Of course, I may think too much of myself.It just might be I'm too old, made too much money or a combination of the three.

The new contract's supposed to run 4-6 months. In the interview, my new boss listed the projects his team will have to handle in the next 12-24 months. I believe he was telling me there's a perm gig in it for me, if I don't step on my....er....keep my nose clean. The recruiter thinks the same.

I had no idea Loyalty Programs could keep that many folks employed for that many projects over that length of time.

Thank Goodness for Marketing. Yeah, you heard me.

The journalist in me cringes when I say that because I've seen marketing and PR communications bombarding the newsrooms I managed.

Since then, I've worked three or four marketing projects and as visionary, pie in the sky and wishful thinking as these folks tend to be, the checks don't bounce and I learned the application isn't mine. It's theirs.

I'm an IT Project Manager now, pretty cool, hunh?

I gotta keep studying for my Microsoft Project and PMI PMP credentials or I'll lose access to the on-line question bank. I've found that pretty good for study.

It'll take a little while to get used to getting up at a reasonable hour more than once a week. So, I'm thinking I'll read and test in the evenings and maybe 8-10 hours a day on the weekend until I'm ready. I hope the new place will give me time off to take the tests. If I was smarter, i would have done all of this over the last 3-4 weeks.But I'm not and job hunting was a much higher priority.

As one Blog Commenter told me, Good. Maybe now you'll quick all that whining.

Probably. But if you've been looking for work over the last two years and know your elbow from your foot, you know I didn't exaggerate anything. And writing this blog with all the rants helped keep me sane. That and the Wellbutrin, Xanex and my wife.

But that's over, hopefully for a while- worst case for 4-6 months.

I hope to have some non-proprietary detail on how small teams in a huge IT arena handle development, project management and some generic info on Loyalty Programs. I've dome them on the BA side, so the PM side ought to be very interesting.

Thanks for sticking with me on this drive to be productive and back to work!

User Centric Redux

A former colleague and current friend (well, until she reads this), Alice Toth, just published a fine blog on User Centric Design. She outlines the process very well (as I would expect) and she slyly doesn't tell you how its done (hey, we all gotta eat).

Alice was the assigned Information Architect on one of those 'projects from hell.' I was the Lead BA. Before I get started, I have always respected Alice's ability, genius and grace. Its too bad she didn't spend much time on our little venture into the third ring of Hell because she is always an asset. Pathfinder recognized this and promoted her to the second ring of Hell- she became a Project Manager while we of the third ring fried and sputtered.

Alice is a fabulous Information Architect (IA). After several discussions, She and I decided that BAs gather requirements and organize them in words, tables and diagrams, while IAs do the same using visual tools. A significant part of being an IA is to show up any wireframe I create in VISIO and they do freehand on a Mac. IAs are schooled in HMI (Human-Machine Interface) and the psycho-sociological uses of web browsers. Both do As-Is and To-Be workflow models (IAs call them scenarios). All in all, the two functions have many commonalities.

Alice was a superb resource when I had to create Best Practices and dovetail Agile Development with User Experience Design. And she can code. And it doesn't hurt that she's a genius without all that stepping on eggshells stuff one has to do around such folks. Very real and down to earth and a great friend.

So, it is with great reluctance that I take her to task for this statement on her latest Blog:

Personas also bring the human element into software development. Rather than using a vague term such as actor or user, terms that can easily be dismissed, we now have Myrna from Accounting, a numbers guru who is the primary user of the new software.

Hunh?

BAs define actors as a person, system or sub-system that needs to do something (a defined goal) using or connecting to the application. While Alice and I were aligning the processes of a BA and an IA, we decided a Persona was usually a class of Actors (i.e. usually more than one person). A Personas usually brings more than one goal to a session on the 'puter. In the Iterative and Waterfall Worlds, these have to be broken down into discrete sets of actions and reactions...and they called them Use Cases. And the PMO say that it was good.

But only for a while.

That there web thingie screwed everything up. Instead of a defined, step by step defined workflow, users can now do pretty much what they wanted (within constraint) as they damn well wanted to and watch video, listen to audio and talk back, through their browsers! Actually, it's much more important to folks like Alice and me that the browser can transmit Credit Card Numbers and PayPal Account detail....but that's another blog.

All this stuff caused Use Case Hyper-inflation and forced the Fed to impose Agility.

OK, I lied- there were a LOT of reasons Agile methods were created. Do you really think the sudden appearance of Web 2.0 and Software as a Service (SAAAAAAAS)- [hyperbole and sarcasm intended] and simultaneous popularization of Agile is a coindence? I don't think so. I can see the guy in the sailor suit with pocket protector up there on the virtual grassy knoll right now.

So we BAs create a series of User Stories that supports the creation of the new or revised workflow we designed and got sign off for at the beginning of the project. We make sure the DevTeam can create each User Story within a sprint, or we break the User Story down some more. Repeat until feature is complete and end user is happy. We use the Actors to identify who does what in the smaller chunks of User Stories. Sorry, its a habit. And it works. And it's not inhumane- I have always worked in a shop certified by the Anti-Cruelty to Actors Society.

'Actor' isn't vague- I always identify them in a separate chapter of the high level requirements and then in thre User Story or Use Case or Specification, I re-identify them. And Alice know damn well I never, ever let the DevTeam dismiss my Actors.

What's that you say? You read the Agile for the Waterfall Lover book and it states categorically the business team member or end user is supposed to write the User Story? Dream on, dude. They don't have the time or inclination to do that unless its in a JAD (Joint Application Design) session and the boss pays for brownies and lunch. The BA or IA write them and verifies them with the appropriate authority (stakeholder, Subject Matter Expert and/or end user). Then the developer who gets the task can go to the person who approved it and start the discussions. Or ask the BA or IA (since they are the only end user advocates on the DevTeam) or the BA/IA can facilitate the discussion. See what I mean? Nuthin's easy.

I have two problems with Alice's declaration of war in the allegedly inappropriate use of Actor and User:

1. The use of the terms Actor and Usder are purposely vague. The whole idea of what a BA does is to abstract the entire work flow in order to define the function(s). This allows the Bidness Team and the DevTeam to read the dame stuff and envision the same thing. That's why they call it Functional Analysis.
2. The UxD (User Experience Design) folks can and do carry this Persona thing way, way too far. I almost worked on a project that had about a half dozen personas identified. The UxD Team (not ours, thank goodness) not only had names- they captured pictures of each persona, knew her husband and her kids, where she lived, what car she drove and what got her drunk the Saturday night before. While the UxD Team goes off on those tangents... DevTeam Members are looking at each other and wondering what the hell is going on. I understand what the UxD Team is trying to do, and it does help define workflows, users and actors. I feel silly and unprofessional when I invoke a Persona. I feel like I'm talking about a dead guy or at a seance. And let's face it folks, the word persona is defined as: a character in a play or novel; A person's mask or facade; or someone's perceived but not actual personality.

If personas help the UxD Team- great. Just don't impose them on everyone. I will not write:

Carrie Ann Johnson, the one from Freemont High School, not the one that graduated College third in her class, clicks <Search>

1. Browser sends search parameters to Search Engine. 2. Search Engine performs search and returns matches. 3. Content Manager and Web Server send results page to the browser.

This Blog brought to you by that little old troublemaker....me (remember those TV wine commercials?).

Powered by ScribeFire.

Why You Need a BA (Me) On Your Team

In my Do Business Analysts Need Computer Programmer Skills? blog, some comments seemed to reveal that many project managers, developers and business folks never had a Business Analyst on the team. Interesting. I think the Agile Teams who have never had a BA on a Team should be considering such folks (me! Me! ME!) for several important reasons.

Since they didn't have BAs, I have to assume the Project Manager and Lead Developers usually handled BA duties...with the top developers getting the requirements (User Stories) and helping define the tests. But only high level developers can really handle this interfacing and talking to 'real' users. The purposes, skill sets, orientation- even language are very different in both worlds. Am I saying developers shouldn't talk to users? Absolutely not- that discussion should positively take place- but there has to be a coordinator, translator and secretary to perform all these duties:

• Learn the business- its processes and needs to develop the very best product under the constraints imposed.
• Create the As-Is and To-Be documentation to begin modeling the project and processes.
  
• Create the high level functional requirements to explain the project, the reason for the project and what technologies may be used in the project.
  
• Act as the stakeholder and end users' advocate.
  
• Gather the business requirements and business rules.
• Design and help model the application with the business team and the DevTeam.
• Plan and coordinate iterations or sprints and road maps with the business team and the Project Manager.
• Translate techno-jargon to biz-speak and vice versa throughout the project.
• Test each build to avoid glaring error and/or to prepare the business for skeletal interfaces and features.
• Create, document and communicate temporary workarounds for identified issues.
  
• Create UAT scripts, run the sessions, compile the issues and comments and create a suggested priority of repair/change list.
  
• Reproduce, manage and test issue repairs (and explained to stakeholders and end users why a repair is delayed or may not be repaired.
• Create User Stories (yeah, yeah, I know, the business is supposed to do this- of course, when was the last time you saw this happen unless you were in a JAD session?), specifications (essentially all the stuff that would have been in a Use Case), wireframes, project documents and business cases.
• Handle or coordinate Change Management (them applications you guys are creating are typically going to raise hackles all over the business because you're changing things and people are change resistant.
• Perform or coordinate knowledge transfer from the DevTeam to the Help Desk and/or Admin and or DBA team(s).
• Write user training manuals, help files and doing 'train the trainer' session for large applications when required.
• Keep Scrum/Stand-up Meeting Minutes and disseminated them to the team.
• Help coordinate and communicate implementation schedules and requirements with the business and IS folks.
• Assist in creating and implementing the Risk Management Plan.
  
• Manage the Issues Tracker, the wiki (making certain business questions and comments were promptly and appropriately handled)
• Provide/create and transmit frequent status reports.

Well somebody has to do all this stuff. And those of you without BAs are probably doing a hit or miss job and know it- your time, resources and costs are cut to the bone, or you are working 10-16 hour days- which is nuts. You know this sort of assistance would reduce risk, improve team productivity and improve the communication with the business- thereby reducing the chance of rejected features/functions.

We do the things the Project Manager doesn't have time for and free up Developers to do much more productive things in terms of skill set and interest. And really good reasons why a BA is still an essential role on an Agile Team. You can also use an Information Architect (IA) for this stuff and you'd get better designed wireframes, screen themes and controls but not as much written detail (which isn't necessarily a bad thing for an Agile Project- depending in the business expectations). IAs do pretty much the same thing BAs do, but they do it visually and usually aren't as technical as a BA. But, we both get the job done for the team.

That's pretty much why I think most projects need a BA and why the BA is typically the Deputy, Associate Assistant Project Manager.

Powered by ScribeFire.

Gamesmanship

One of the dirty little secrets they don't tell you about in school is about the recruiter. Yes, 97-99% of them are professional, work hard and are ethical.

But that one to three percent are real pieces of work.

They call you and ask the basic questions to qualify you for the 'requirement.' 'Requirement.' It's a job listing, job ad or job order. It includes a list of requirements. Arrgh!

Anyway, the Level One Recruiter (like the Level One Help Desk Analyst whom we all hate) then tosses your resume over to the "Account Manager." This is a sales job, not a management gig. Like the fact that everyone who works in a gas station or movie theater is an Assistant Manager.

This Account Manager thinks s/he knows exactly what the client (i.e. the company and people for which you might be working) wants. Usually wrong, but OK, they have the contact or prime vendor account and I don't.

Every once in a while, s/he wants you to 'tweak" your resume.

I'm all for writing to your audience (second rule of writing) but a few times in the last several weeks, these "tweaks" included:

• Changing 'Senior Business Analyst' to "Senior Business Architect." Now, I did it because I figured this was HR title inflation. I sent the resume back and the Account Manager immediately responded- "Can I turn Technical Writer into Business Architect/Technical Writer?" I said, "Hell yes." I thought the person who designed and build a business was the owner or the sales manager. I've never heard of a Business Architect. The 'requirement' read exactly like a Senior Business Analyst's role. I thought he was kidding. Even though I was a good boy and was biting my tongue through the entire process, didn't even get a phone screen.
  
• Bringing out the fact that I've managed people. Which I have and expect to do again. In radio news, my highest number of reports was 35 (all news radio station), but I've always been on small teams full of really smart people. Anyone familiar with software development will tell you the BA typically acts as the Deputy, Associate, Assistant Project Manager. How do you bring that one out in a resume without it turning into a Vitae (a book length listing of every time you walked your boss's dog, the number of Cleanest Cubicle awards you've received and junk like that)? I've been a professional writer in a wide variety of media and I have no clue. Didn't get a phone interview for that one either.
• Lying. One person was very careful to mention the job needed programming skills. My programming skills are, uh, nil. The last time I coded, there were still line numbers and you used crappy editors like Edlin. And, if it didn't work the first time, I quit doing that program. It should work the first time. I once did a program in C+ that converted dates into base 64. The only thing I remember about that program was the fact it had a bazillion recursive If-Then loops and if it didn't work the first time I ran it, I was going to quit my job. I didn't do it. I once had a really great job for three weeks. They had six, count 'em six interviews where I told them I was a tech writer and knowledge manager, not a programmer...although I suppose if you put a gun to my head I could probably figure something out within 6-10 weeks. You know what my first (and only) assignment was? You guessed it. They wanted me to convert web content into Lotus Notes databases. I was flabergasted. A. Didn't you listen to me the six times I said I wasn't a programmer? B. There's a programming language for Lotus Notes? Then why doesn't it ever work the way you want it to? C. Lotus Notes? Why the hell aren't you on Exchange or Zindus Server?
  
• Fill in the gap. You see, I haven't worked since October 2008. I'm in a protected class (those 40 and above, which sucks) and I used to make way too much money according to the large corporations here in Chicago. As soon as the bottom dropped out of the economy, these bastards started pushing down BA, Information Architect and Project Manager salaries and hourly contract rates. It's going to boomerang and hit them in the ass in a couple of years. Anyway.  There's a gap in my resume. Him: What have you been doing, Scot? Me: I've been looking for work more than full time ever since my last project crashed. Him: We need something else, to show you were doing something. Me: I just told you what I was doing Him: Nope, need something better. Me: Tell them I was researching a book about how a Business Analyst fits into an Agile Project as well as a few domestic engineering jobs. Him: That'll work.

And none of them, not one of them (except for three or four astute, personable and caring recruiting companies) tell you anything unless the client company wants a phone interview or you hound them with e-mails. And then they're your very best friend... until the process craps out on you.
 
I dunno. Maybe I should have stayed in radio news. I could easily be making $37,000/year in one of the three or four news jobs left in the industry. Or I could be a disc jockey...saying the same thing over and over and over and over and over...

Powered by ScribeFire.

Discovery Zone

I interviewed with an attorney this week. Her company dumped what might turn out to be a major IT project in her hands. She talked to one of my best friends who recommended she talk to me.

The first phone call was frantic... for the attorney and for me. As is typical, her mind was down at the field and controls level and I had to a. figure out what she was saying and b. make it look like I knew what I was talking about.

After about a half dozen questions, I realized where she's at and why she's in trouble.

This company gets sued a lot, I guess, there are a lot of in-house attorneys and, to use her words, "...hundreds of Outside Counsel."

Legal Discovery

Unfortunately, the legal profession uses the same word we IT folks use when we start a project: Discovery. Seems that in a civil lawsuit, Discovery occurs when someone sues someone else. Both sides have to give copies of relevant data (documents, spreadsheets, e-mail, etc.) to the other side. Turns out my new friend's company does this manually. In this day and age!

Thankfully, the company is throwing some resources her way and we may be able to solve her problem.

The company is adding some enterprise tools- but these tools aren't connected to anything in the current plans. Yep. No data store, no way to search, no history of use, no ability to browse using a taxonomy and no way to create and send a digital package of documents/data to opposing counsel, much less e-mail confirmations and an audit trail.

So the poor lady has two problems: where do we put all the nicely tagged and redacted data items and once they're there, what happens?

She has 3 Terabytes now. How do we get disparate databases connected (including non-company hosted systems) and then once all that stuff is properly stored in a data center somewhere- how do the other attorneys find and use the documents.

She was mostly concerned about the data store and what she kept calling "the index." She's right. The search engine needs to be able to pull records based on a lot of metadata. At least the metadata tagging will be automated!

Her IT Department has no resources to help her. Its been ravaged by lost and unfilled positions caused by the economy and several company reorganizations.

No wonder she was going nuts. Heck, if I was facing that and didn't know anything about content management, data mapping, batch ETL (Export/Transform and Load. No? It means connect all the databases and make them work nicely together) and the ways and means of attacking and solving the problem (project management and business analysis) and designing a solution (at the abstract and the wireframe levels, certainly), I would have been much more upset than she was. Hey, I can't write a brief or represent someone in court for money...why would her company expect her to be able to do what I do? I don't.


IT Discovery

Here's what the Project Discovery Phase looks like from my perspective- the Business Analyst:

The goal of this phase is to find the new system's boundaries (this will help define the Scope of the project), gather and organize functional requirements and settle on technology and architecture. Once the deliverables (the stuff I hand the client when that part of a project is completed) are in, the customer/company/client then has enough information to intelligently deal with how it wishes to proceed.

I advise and suggest while the company does everything except figure out how to pay for it and decide whether its going to do it. I guess they think that stuff is proprietary and private. OK by me.

I'm a sort of combination resource-subject matter expert-adviser. The Project Manager (if we have one) and I are what's called 'client-facing.' This is a silly term for: we talk to the client/customer.

I usually go in with a Project Manager (if we have one) but much more importantly-- a really smart technical architect or Lead Developer. We grab as many Word Docs, Excel Spreadsheets and paper, passwords, user ids and network paths as we can.

Then we sift and read. I then draw what the company is doing now (called an As-Is Decomposition)  and a proposal for automating one or more processes (called a To-Be Decomposition). The architect and I are beginning to design a possible solution. I start setting up interviews or meetings so I can ask questions and define the high level requirements. The architect is doing a parallel study for the technology (development languages and basic coding standards) and architecture (identifying the likely service layers and a beginning of the database table design).  We constantly confirm and reconfirm the validity of the existing process and what the stakeholders tell us the business needs (business rules).

I write my functional (functional - that means a description of what it does, not how it does it) requirements, a few fancy pictures (remember I told you Technical Writers to always have one graphic in color in anything you write that's more than two pages? The company folks you're working with need as many diagrams and pictures as possible top help them sell the project- preferably in color).  I usually add a couple of 'artist concept' wireframes of a basic interface and a lot of diagrams. 

The architect is writing up his/her technical document. If it's going to be written in .Net, there's a lot of cutting and pasting from the Microsoft Development Network website onto our wiki- I never watched where the J2EE architects steal, sorry, borrow their documentation from but I assume its on the Sun site somewhere or maybe at SourceForge.net.

I then edit the technical document because I have yet to see a developer, even at Microsoft, who knows how to write. I'll also help here with any diagrams or flow charts the architect wants (which I 'suggest' forcefully, see the parenthesis two paragraphs up).

From these two documents (and maybe a Business Case), the company can count function points, bid the project or put everything on hold. Hopefully, the last option doesn't occur because I usually....no...always need the work.

For some unknown and mystical reason, my company gets the contract for the Functional Requirement Document I just wrote. every time. How do you like that? Amazing streak of good luck, no?

My new friend wanted a proposal in plain English. This sparked friendship. I hate lousy writing. But she wanted complete explanations. So I spent most of yesterday evening and this morning writing it. It was seven pages long. I thought I went overboard. But my original friend said I didn't so we'll see what happens.

I think the two color flowcharts and the lovely Activity Diagram will help, as will the seven PowerPoint slides with animation and reuse of the graphics.

I ain't no dummy.

Stay tuned. Let's see if the winning streak continues.

Powered by ScribeFire.

BAs in Transition

I feel like singing an old Bee Gees Song, I Started A Joke (which I can sorta do on my guitar). I wrote a blog about this sudden need for BAs to write Code. Before writing that Blog, I used to think requirements gathering and coding needed a Business Systems Analyst or Systems Analyst to do, and and far as I was concerned, those folks were worth the extra 10-20K a year.

I didn't realize this would raise so much thought in the LinkedIn Agile Alliance Discussion board (the link won't work unless you're a LinkedIn Member and are in the Agile Alliance- which is full of really good and really smart people).

The discussion is great because it raises my visibility (and visibility may = potential job) and good for you who comment (same reason, but you can scratch and bite and kick and scream, but I have to be gentlemanly and kind. It hurts.). It may also elevate the state of the art, which is never bad.

But the drift I'm catching is one that's bugged me for three or four years: What does the BA do in an Agile Project? I think I started to answer that question in a Blog earlier this week titled BAs, in an Agile Project?

And there are two ancillary issue floating around the Agile Ether and I name them here:

• The reason the BA role was created still applies. Even in Agile: translating jargon/goals and managing  expectations by identifying, documenting and testing requirements and business rules.

• There are two BA 'tracks' in IT- the Developer who wants the big bucks and become a Project/Product Manager (not realizing how little your actual hourly rate will be) and the Technical Writer Track- Writers who watched kiddie BAs grab fists of money. We said to ourselves, "I could do that." We read the Use Case Books, learned RUP/UML (artifact? gimme a break, how old do you really think I am?) and then read the XP, RAD and Agile books and talked amongst ourselves. Rhode Island isn't really a road and certainly isn't an Island (say Rhode Island out loud- it's an audio joke).
  

I don't think either BA background is better than the other- the Developer BA is more technically inclined and can handle Objects, Services and Web Applications better than the Tech Writer BAs. But the Tech Writer BAs have better business acumen (dunno why, but I think 'acumen' is a cool word), change management, client-facing and documentation skills. Both can abstract, both can write User Stories/Use Cases and other project documents (but the TW's documents will be more coherent, grammatical and prettier) and both can fill project voids as the SDLC runs its course.

The comments show that some folks have never had a BA on their team. That's a real shame because somebody still has to do all the things a BA does. Which usually means the Project Manager/Scrum Master (that ridiculous title- almost as stupid as my Six Sigma 'Green Belt-' these metaphors are sooooo silly) and or the Lead Developer have to do them. Which means a project is a Sprint rather than a Marathon and something is going to get short shrift. Kinda like my first bullet point? Some shops have come full circle.

I love Michael Duncan's comment that a waitress doesn't have to know how to cook- spot on Michael with a great analogy!

Powered by ScribeFire.

Do Business Analysts Need Computer Programmer Skills?

I've been reading the How Do you Get Business Analysts Domain Experience blog series from IT Career Coach since it started. The first one was cogent, intelligent and pretty much in line with my own thoughts about being without work for so long.

The latest and final blog, Do Business Analysts Need Computer Programmer Skills? is almost on the money. IT Career Coach argues the IT Analyst does need to have programming skills because a. that's what the market is demanding and b. the BA role has "evolved" to include programming.

Balderdash. Ptoooi. Wrong.

In a properly run project, the BA and the Developer are going to be needing every second performing their respective roles. Otherwise, dear reader, the sprints will extend, the iteration will be late and the implementation team (probably composed of the developers and the BA and the PM and the Infrastructure Team....) will get the code late.

These ads IT Career Coach is referring to are a bid by companies to 1. lower development costs by lowering salaries, 2. adding as many domain and application requirements as possible so their HR scanners don't have to work so hard and 3. forcing us to guess what the real job requirements are.

Do I think the blog's thrust is wrong? No.

An IT BA needs to know programming logic to write abstract use cases, user stories and specifications, which often contain pseudo code. In other words, to talk to the developers, the BA needs to be able use and understand phrases like 'loop,' 'data layer,' 'IDE' and 'COM.'

The IT BA needs to keep up on .Net, J2EE, SAP, J.D. Edwards, Ruby on Rails, Ajax and other technologies' capabilities for design, specification and testing. In other words, the BA needs to know, at the abstract level, what the technology can do, other the BA can't design or specify, much less set up a functional description of what should happen.

By the same token, how many of your developers can talk to the business side without a. raising expectations, b. creating misunderstandings or c. not understanding that business pushes the project, not elegance or the 'gee whiz' factor?

That's why Agile projects demand high level, experienced folks in key positions...like Developer, BA, Project Manager, etc. In a small to medium sized project, this isn't an issue. But in larger or off shored projects, Agile isn't known for scaling. It can be done... but a few Waterfall and Iterative practices needs to be added to the Project's Governance and Process- with Agile's means of revising things that don't work into things that do.

I'm thinking of getting a couple of SAP certifications. Then I might be able to find a job.

programming, business analyst, IT, process

Powered by ScribeFire.

BAs, in an Agile Project?

Books, websites and consultants are telling us to move to some form of Agile- and, once the consultants get a hold of it, it's going to morph- which it has. Since when is Scrum a method? It's a meeting and project management tool. ARGH!

Now, the Agile Manifesto says two things that I've never seen:

1. Business People and Developers must work together daily throughout the project.
   
2. Face-to-face discussion is the best communication tool we have.

I've not seen this happen- have you?

• Item: Business people seem to have overflowing plates and are too busy to allocate a fraction of time to a development project every day.
• Item: We're lucky if we get a user to a demo or five minute play session in the sandbox environment much less regular face-to face meetings.
• Item: When was the last time you saw a member of the business team actually write a User Story? A Specification? Comment on an existing Story or Spec? Thought so. The only good thing about a Waterfall Shop is the Stakeholder actually reads the Stories and Specifications. Badly, inaccurately, but they read 'em.
• Item: And who's had the business team member actually empowered to make real decisions? Not in a consultant-client governance project and certainly not in an organization that is, necessarily, a waterfall shop moving to Agile.

Enter the Business Analyst:

...the guy or gal the Agile Book Writers either ignored, blew off on a simple process flow diagram or forgot existed. Bad move, Scrum Master/Project Manager/Team Lead.

If you really have top developers who can pull requirements from users, you still need the BA to introduce them, set up the meeting, attend the meeting to translate the jargon on both sides and provide a written record of what happened to eliminate the finger pointing later.

If you don't have top developers and are heading smaller teams with your best and brightest, who's getting your requirements? You're wasting time and resources if you grab the requirements in a demonstration or from comments/issues generated from your sandbox environment. Oh yeah- the stakeholders and the end users loose faith in your DevTeam because they didn't get it right the first time (Agile takes a while to settle into everyone's mind). Once you've lost faith, you've lost the project.

Scrum or Stand Up Meetings

I learned this system at Pathfinder Development under the tuteladge of CTO Dietrich Kappe.

We're assuming a two week sprint schedule here. The BA is working one sprint or iteration ahead of the current development work.

Each day, the team meets in a Scrum or Stand-up meeting. Only the DevTeam and Design Team participate. The Business Team provides support and listens for status changes. Each DevTeam member answers these three questions:

• What did you do yesterday?
• What problems did you face?
• What are you going to do today?

The BA records the answers. The Project Manager and (to a lesser extent) the BA prepare an obstacles list and begin removing those obstacles.

Requirements Gathering

The first couple of days, the BA generates a proposed list of Features and Issues (Fixes) for a sprint. The BA gets preliminary approval from the business team, architect or lead developer and the project manager.

The BA then meets with Subject Matter Experts, end users and stakeholders to gather enough detail to write preliminary User Stories for the list. After they're written, the BA returns to make sure the stories and tests are accurate. Once the BA has preliminary approval, the BA writes a more detailed specification. It may include data maps, wireframes, interfaces, flow charts, step action tables- in short, everything the Developer should need to code the item.

The BA then presents the stories and specifications to the Stakeholder (to verify accuracy and need) and to the Architect/Lead Developer. This check helps the BA and the DevTeam Lead to:

1. Make certain each item is technically do-able.
2. Make a preliminary judgment on whether the item can be done within a single sprint or needs to be split into components.
3. Confirm dependencies.

Testing, Reading and Reviewing

The current sprint ends. The Agile Manifesto says Agile Projects are test-driven. The developer does the usual boundry and smash tests. Guess who does the Alpha testing? Me. I use the minimal tests in the User Stories to create scenario-driven Test Cases (and usually test scripts since 99 times out of 100 I'm going to add the script to User Acceptance Testing later). This is sort of the reason I usually handle issues management. We don't want the client/customer to see really ugly stuff.

One- three days are scheduled to allow the Developers to read the new User Stories and Specifications, ask questions and begin deciding how complex each item may be. The BA either answers the questions or properly routes them to the Business Team.

The entire team meets for a review session of the most recently completed sprint. The BA records Best Practices, Suggestions and Proposals for Change.

The Kick-Off Meeting

The new sprint starts with a Kick-Off Meeting. Each proposed Feature or Issue is brought to the table and the DevTeam can ask the Business Team or the BA questions. The DevTeam then assigns a complexity rating on each item. Ballpark hourly estimates are awarded to each complexity level and then everyone can see if all the items can be done in the time allocated. If it can, great, the developers start coding and the BA starts the next sprint's proposed list.

If not, the BA and the Project Manager negotiate with the Business Team about additions and deletions to the list. A proposed list is given to the DevTeam. If accepted,  great, we're off. If rejected, we re-negotiate.

Change Management and Scope Creep

Any changes made or requested during the sprint has to go through this process, at least informally, because the DevTeam is responsible for each item on the list. Idf the business team wants something new, something old has to go off the list. If the DevTeam is having a problem with an item, after root cause determination and proposed mitigation planning, the Business Team needs to make a decision on continuing or stopping development on that item.

Demonstrations and Communication

I've worked mostly 'distributed' Agile projects. I was with the DevTeam in our offices and the client/customer was somewhere else with the Project Manager. This sort of made me Assistant-Associate-Deputy-Vice Project Manager, doing what the PM needed done.

Typically, if we had a test environment, I create an e-mail list of all appropriate folks to tell them a. what's been changed and b. what the user should expect.

If there was no test environment (usually very early in the project), one of the developers will run a demonstration and let the demo meeting attendees play with the software.

I got all the issues, suggestions and complaints. I loved this part since Agile allows us requirement gatherers to ignore the bane of all BAs, IAs and Project Managers: Hidden Requirements. There are non by definition since the end user is playing with the actual product. That means we can change on a dime and make UAT Test Cases and Scripting easy.

Governance

1. The project needs to support the business. Gee-Whiz Stuff can either be pushed into the backlog or eliminated.
2. The business controls the functionality, prioritization and resource allocation.
3. The DevTeam designs, adapts or creates new business processes, researches technology and presents code to the business.
4. The DevTeam Leadership describes expected or potential outcomes from a decision as well as providing the business with options and a recommendation. The business is responsible for the decision (see #2).
5. Like any other project type, software development is controlled by time, resources and scope. If anything changes within a sprint, a release or an implementation, the business makes the decision.

Powered by ScribeFire.

Using a Wiki for Agile User Stories

User Story: 2-3 line base definition of a feature with test(s) to tell the developer when the feature is complete. Each User Story has a unique number and is assigned to a sprint or iteration after the business-development team negotiation for a Kick-Off.

The Agile Books will tell you to put the User Stories on 4" x 6" cards with the tests on the back. This allows the developers and business team member to easily identify dependencies, move cards around for planning, carry the cards when a developer talks to an end user or stake holder and to throw them out when the sprint is complete.

• This will work fine a small project for an organization that has some experience with Agile Development.
• It will fail with a large project and an organization that is moving to Agile methods.

Then came wikis. You've used them (Wikipedia is the most famous example). The idea is to allow any one with access to edit or comment on anything in the wiki. And we had to figure out a way to put User Stories (written by the B.A. or Information Architect, not the Business Team Member assigned to the project) up on the wiki. And allow as much flexibility as using 4" x 6" index cards.

We used Confluence because it dovetailed so nicely with the issues tracker/project management application Jira.to As a consultant, I've dealt with more of the latter than the former.  As per usual- someone said, 'Scot, take care of this.'

I don't know about other wikis, but I have to believe they're pretty much the same. Confluence allows administrators to create templates. Once created, wiki users can then simply bring up a new page and apply the template. Here;s what I included after looking at a brilliant Information Architect's (Alice Toth at Pathfinder Development) first draft, here's what I included in the template:

• Project Abbreviation/User Story Number- if it's an issue, we added the Jira Link to this section.
  
• User Story: (who does what and what happens as a result in 2-4 sentences
• Workflow- as required, quickly documents where in an end user's work flow this occurs and simple error handling.
• Business Rules- as required-rules the business imposes or needs for the User Story to work properly
• Wireframe(s)- low to medium resolution wireframe as required
  
• Test: Two column table- first column labeled Action, second column labeled Expect Result with 10 or so rows (can be added to or deleted from the table as required.
  

As for the flexibility for moving cards around? That's what the Sprint Page is for!




Next up: The Problems of Agile Adoption

Powered by ScribeFire.

Coordinating a Sprint using a Wiki in an Agile Project

Confluence is a wiki. It has rich text creation tools and a very simple html-like editor. It has rudimentary content management tools, allows RSS feeds and works very well in as an Agile Project Document creator, distributor and workflow handler. Atlassian also makes Jira, an issues tracker, project management tool that integrates with pretty much anything but works especially well with Confluence (obviously). Each has add-ins for customization (free and paid). And you get the source code. There may be other tools as good or better, but I've used these to great advantage.

This time we look at Confluence from a conventional BA's point of view.

You just lost control of all the documentation, my friend, the one thing you thought you should never do. This was the hardest thing for me to let go when I was learning the Agile mindset. Heavy with Waterfall and Iterative (RUP/UML) methods, the idea of other people actually laying hands on my stuff (it is a wiki, you know) was horrifying.

I should have relaxed. The original is always there and you can set the wiki to allow the author to approve or reject changes. And remember: Agile and its various offshoots recognize something. The application has to support the business and mounds of paper do not support the business. Instead, killing trees does three things: 1. Makes the discovery and requirements gathering phases way, way, way too long, 2. Allows higher-up muckety mucks to point fingers at each other at UAT, Implementation or Hand-Over time to ruin your project and 3. Pretty much waste time and energy because Use Case creation always misses the hidden requirements.

Hopefully, you'll have admin rights in Confluence. You'll set up two tracks for your project in Confluence- Technical and Functional. The Architect and Lead Developer start the Technical side with architecture, coding and developer standards. Later, Open Source Application docs, control packages, parsers, database schemas, web services, objects and other things are added by Developers.

You (and the Information Architect and the web master if you're lucky enough to have the help) use the Functional Side, creating the master Functional Requirements, Non Functional Requirements, User Stories (anyone really have an end user or stake holder actually write a story and associated test(s)? I thought not.) specifications (the other stuff User Stories left out that used to be in Use Cases but the Developers want more detail as they code). Here's whatcha do:

Create a single Sprint page for each Sprint. Include the following:

At the top:

• Sprint Number
• Date Started
• Date Ending

Create a six column table (I used the cool Confluence status-style table with clickable status changes because a. I know the wiki code and b. I'm lazy so I just added columns to the auto-table maker) with these headings:

1. Feature Name or Issue ID Number as a link to the Confluence-held User Story or Issue Tracker source page
2. Description- VERY short description of the issue or feature
3. Documentation: Links to specifications and/or associated issues or technical/architecture pages
   
4. Assigned- this is whom the development team assigns to the work
5. Status- I used the two Confluence statuses which were basically Complete and Not Started. I know there's a way to use the Jira Status field to trip this but never had a chance to play with it and make it work. Since we were doing all the time estimates and Statuses (Jeez, between the two PMs on one project and the Visionary Client, did WE have statuses).
6. Trace- trace features to the Functional Requirements or Technical Architecture Documents you wrote or helped write during the Discovery Phase.

Add a predominant link to the burn chart (if you have one) either as a spreadsheet or one of the Confluence/Jira Add-In features.

Fill in the table with your proposed Sprint list of work and your team has instant access to the documentation they need to ask questions, determine if there's enough detail to work the feature/issue or if the BA/IA needs to better develop the documentation (and find out which questions the Developer needs answers), make preliminary complexity estimates and prepare for the kick-off with the client. Do the same with the client. Allow comments but no changes on these pages.

After the kick-off and the sprint work list negotiation, adjust the wiki list appropriately (and do NOT be offended if the DevTeam recreates it on large chart paper and hangs it up in your war room- it helps in focus and people love to cross stuff off a list). You'll probably end up keeping the Status column up to date, but it only takes a few seconds.

Now you have a single source for your DevTeam, the Business Team and the Design Team (You and whomever is is helping you) to access any documentation on the current sprint. And you can drop issues and features the client wants onto your next Sprint Page because you create that one now since you're a sprint ahead of the DevTeam, aren't you?

Next I'll talk about creating User Stories and Specifications in the wiki.

agile, user stories, wiki, sprint planning

Thursdays in Unemployment Land

Well, folks, Thursdays are a lot like Fridays here at the Unemployment Dude Ranch.

Yes, there are a few new listings on Dice and CareerBuilders and I found several gigs in the Job Search Universe (highly recommended- it aggregates job postings from other sites and let's you slice and dice any way you want to see them.

Those of us who have used Dice.com for more than twenty minutes realizes all the jobs listed seem to magically renew themselves making 'View By Date' pretty much useless. Job Search Universe tracks all the Dice openings you're looking for and tells you how long it's been on Dice. Some of them have been up there for months.

If you're in a tabbed browser- the Job Search Universe seems to be the way to go. I go there right after I check the LinkedIn ( aggregation provided by SimplyHired) and Craig's List (yeah, but I found two cool jobs there- One at Pathfinder Associates and the other here in Naperville that was put on hold because of the economy.

Once that's done the only phone calls I get are from bill collectors and family. I'm thinking HR and Hiring Managers don't do anything except on Tuesdays and Wednesdays. Methinks recruiters are pretty much 24/7 and take classes so you can't talk to them over the phone.

job, search, business analyst, employment

A Couple of Things That Stink on the Job Boards

OK, I admit it. I'm on LinkedIn and yes, the Web Search function through Simply/Hired aggregation engine is helpful. Not as helpful as fresho.com or Google, but helpful.

What is not helpful is this silly little widget on the right side of my LinkedIn homepage that sucks me in every time:


I click it every damn time and get this:



Now, this could be helpful since Monster and Dice are about as forthcoming about search hits and who looked over your profile detail as LinkedIn. These services want you to pay cash for this detail. Anyone in IT will tell you that the audit trails on these searches cost about nothing. Which is pretty much what a guy like me, who hasn't worked in none months, can afford for this singular detail. What can I do with it?

• Figure out how well my resume is doing since I already know which companies to which I've applied.
• Figure out how well my generic cover letter is doing (stop. before you say it: Do you have any idea how many supposedly great companies are using boiler-plated job ads? At least my letter is truthful and an accurate representation of what I can do). 
• Anticipate a potential call from a recruiter.

JobFox provides this for free, along with e-mails telling you what the company won't- the job went to someone else or was removed from active consideration. I know- I was able to anticipate two calls that almost resulted in jobs...but JobFox' interface, data transfer speed and security need major upgrades to be useful to job hunters.

So Dice, Monster and LinkedIn-Simply/Hired force me into a guessing game (see my first post- I'm pretty good).

• The Ex Libris is one or two of the people I used to work with at Crosscap Media- great people and they're probably checking up on me to see if I landed yet.
• Someone in Government Relations in Sacramento, CA? This is probably some cube rat that works for Arnold and came this close to being nailed for surfing porn sites.
• Recruiter at RusellPhillips? No clue. Don't know anyone there....and maybe I want to know someone there.
• Someone in the Computer Industry? Gimme a break. It was a close friend who's also looking for work and we copy each other's best stuff for our own.
• Someone in Executive Recruiting at Addison Search. This is a head scratcher. Addison had me up for a contract gig. They were nice smart and kind enough to tell me three days later the client was going with someone else (trust me most recruiters won't do this in some sort of oddball way of 'holding' you'). So why they're still looking at my profile is beyond me...but at least someone's looking

Is this worth $20-$60 to me? I don't even bite on those Classmates.com flags. But for some reason...these three sites are able to get me to click through everytime even though I know I'm not going to like it.

What was that old saw about repeating a failed behavior?

finding a job, job boards, click through, search hits