Taking Advantage of BAs Because They Can

There are a lot of BAs who were working (and deserved) low six figure pay before Wall Street idiots did what they did. Most of us worked as consultants because that's where the cash was. Now we're seeing:

• Ridiculous job requirements/software backgrounds in areas other than Health Care, Insurance and Financial- those I can understand- specialized domain knowledge. But database cleaners? Portals? (everyone seems to be moving to SharePoint and this seems to be a real big deal requiring years of experience with the tool- right- you're telling people who can create custom Portals with dozens of interfaces and multiple layers with extensive User Profile functionality doesn't directly relate? Balderdash)l E-Commerce or Basic Business Intelligence? Gimme a break.

• 10+ Years of Experience: Who are these people? There wasn't any such thing as an IT BA in 1999, the concept was just starting to spread with the use of requirements documents (Use Cases). BAs back then were what we tend to call Financial or 'Real' BAs today- the ones who can look at market data and prepare forecasts and other magic stuff accountants and actuaries do. But can they describe how their PC is supposed to connect and how the User is suppose to work the actuary engines?
  

• Demand 6 months or less since the last job: I got a call from a recruiter yesterday- "Scot the job's a perfect fit with your background- what have you been doing since October 2008?" I said, "Looking for work." The recruiter said he was sorry, but the longest gap this company would accept is six months. I laughed, silently (yuh never know if the recruiter might do you some good later). I told him to tell the company I was researching and writing a book: How BAs Fit in the Agile Method. No dice. Well, Dice.com, but not for this job. I figure they lost a tremendous resource. Me.

• Demanding Salary Requirements or Back Salary Levels: I used to make a lot of money- at least as far as most of Chicago's Companies are concerned. They want all the ridiculous requirements and pay $20-$30 per hour. Now, I know I'm going to have to take a salary hit, but these HR people are filtering people out for high pay because they think higher paid people will leave when the economy straightens out. Um, genius, why wouldn't you want a bargain between now and then? If it were me, I'd hire the person, knowing that as long as salaries were low, I was getting a bargain and work the bejesus out of me then shake hands like a mench at the end. Nope- they'll hire a lesser experienced or newly minted BA instead. Is it any wonder some of these companies are in trouble??? I put either $5/year in the field (freakin' developers made the fields number text since my last job search) or leave it blank if I can. Mebbe I can tell them I'd take $45/hour with a smile and a sigh of relief and you'd have a friend for life.

And the silly HR keyword searches, uploading resumes created in Word and the parser screwing every little thing up. I'm sorry the HR people are being inundated- but they are filtering out some great people with superb skills and extensive experience. 350 resumes for a single position? When I was looking for people I would have killed for those numbers so I could get the best person I could.

And the Hiring Managers? Please. Why would you search for a new resource without the gig budgeted and approved? Why are you asking me questions that have absolutely not relevance to what you said the job was all about on the phone? Manhole covers? Why are you wasting your time and mine? I had to pay cash money to come here and talk to you- money I don't have because I make all of $317 a week unemployment.

You can't blame all of this on the economy. A friend and fellow BA twittered this: Why are there so many idiots working and so many really good people looking for work?

The system's broke. We need to fix it.

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