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.

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.

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

So What Do You Do For a Living?

I've been getting this question a lot recently- from friends, high school buddies and my mother. It comes in various forms:

• What is it you do again?
• I'm not sure what you do but it sounds really dull.
• I thought you were a radio news guy.
• I thought you were a Folk Music D.J. who hated Bluegrass Music.

Well, yeah, I was the last two things, but I haven't earned any money from either for about 15 years now.

Now I'm a Business Analyst.

Originally, Business Analysts analyzed economic trends, corporate maneuvers- bottom line sorta stuff with the bean counters in Finance.

About 20 years ago, computer people started realizing that all the cool stuff they were making either wasn't being used, was costing too much or didn't do what the business people thought the computer people told them it was going to do.

Think about the first time you moved from your first word processor to a new one. Remember how painful that was? Now think of that pain in terms of gobs of cash...yeah...that's what BAs were supposed to prevent.

So the first thing BAs do is make sure the computer people know what the business people said. And make sure the business people know what the computer people meant.

I usually say it this way: I make sure the propeller heads know what the suits said and vice-versa.

A close friend tells me potential employers may see this, so I'm not going to explain it the way I usually do.

Then a couple of guys said, "Let there be Requirements in the form of Use Cases and Business Rules."

And Project Managers saw it was good.

Use Cases and Business Rules are a way the business folks and the technical people can agree that this is what the thing is going to do, who's going to do it and how the heck do you figure out the Canadian Sales Taxes? Short simple sentences in active voice and a lot of step-action tables that nobody reads. Everybody looks at the color VISIO charts and ignores the data maps, development tests and other stuff that make everything work.

But the Project Managers didn't want to write them because they were way too busy trying to figure out this new Microsoft Project Server deal and why it won't show them dependencies (Scot has to do A before he can do B) in the color Gannt Charts?

So the BAs write them.

So, what we got now is translation duties and ownership of the documentation (at least all the docs now spell you're and it's correctly).

Then, ten other guys met on a mountain top somewhere East of Eden and came down with the Agile Manifesto (sounds like the Cold War started up again and the ten guys should have beards and be smoking Cuban cigars, doesn't it?).

The Manifesto says no documentation unless it's really, really, really necessary- Thou were filling up mine network shares with Word Documents no one read except for the embedded VISIO charts. So we BAs lost the documentation thing in favor of having developers actually talk to end users and stake holders. Clients or Subject Matter Experts or Stakeholders will write 2-3 sentence 'User Stories' and talk to the developer as the developer creates real code. Un-hunh. You ten cigar smokers think this is really going to happen, doncha?

Whoa, thar, big boy. You want a young person just out of C++ and/or Java School to talk to the senior managers and end-users about features? Without blood?

The high level lead and architects can and should be doing this...but what does a 23 year old know finding out how a 55 year veteran of the company does his job...with the knowledge that the new computer system will automate and thereby eliminate his job?

Scot? Can you grab those requirements for me?

And since the Manifesto says we do test-driven development and the client's way too busy, can you write up the technical specifications and the tests for us?

Oh, I forgot, since I'm only here two days a week for this project, can you prioritize the issues and features for me? We can plan a proposed list for the client next week.....

Add Alpha/Beta testing, setting up User Acceptance Testing (writing scripts for a lot of users to bang away on the system to find flaws), collating the results, mentoring junior BAs, helping Information Architects....you getting the picture?

That's why it's kind of hard to explain what I do.

I love doing it. I'm good at doing it. But nobody's been willing to pay me to do it since last October. Some company's going to get a bargain and I'm going to love them for it.

business analyst, requirements, agile