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.