Skip to main content

Tag: Communication

BA-elzebub’s Glossary Three – The ‘A’s

Written by Marcos Ferrer on . Posted in Articles.

My brilliant readers know this piece of fun. Get credit in my next blog by offering “B”s in the comments at bottom.

A, CY: Don’t make me spell it out for you 🙂

AAA: See Alcoholic Analysts Anonymous.

Aardvark: Unlikely boundary to BA-elzebub’s Glossary (see “AAA”).

Absolute Zero: Numeric, one byte datum probably not created by accident, but maybe.

Accuracy: Not the same as precision, nor validity (usefulness or applicability). Don’t make me Google it for you!

Acronym: ASCWTEACOTTIAFWSATD (A short clear way to express a concept or thought that insiders are familiar with, such as this definition).

Adipose: Part of a satisfied stakeholder’s state, as in “Adipose and anti-sad.”(YOU Google for “happy” synonyms)

Aeon: Amount of time it takes to deliver “everything” as asked.

Afferent: A better word to use than “olfactory” when describing a project. Example: “When we started this project it was relevant, but now it is positively afferent!”

Agenda: A personal secret goal, distinct from, and more important than, the purposes of the meeting.

Agile: Quick enough to dodge reading, duck writing, and stick to binary ‘rithmetic.

Agreement: A formal misunderstanding adopted for the common good.

Ahora: Cuando quieren la sistema (See “Ayer”).

Aim: Business activity typically following “Fire, Ready”.

Aimless: See “Aim”.

Airball: A word from basketball. Also, what an ‘airy cat ‘acks up at ‘ome. Why, what were YOU thinking?

Ajar: The only word (Scrabble Dictionary EVIL) beginning with “Aj”.

Akinesia: Motionlessness due to a paralysis (of analysis? – See “Analist”).

Alcoholic Analysts Anonymous: Likely boundary condition on BA-elzebub.

Ambiguous: Examples:

  • Can Can
  • Quality Test
  • Assumed Risks
  • Technology Constraints
  • User Friendly
    Also, one who is able to “take guous or leave it.” Not to be confused with Bi-guous or Bi-guouscurious (The “B’s have begun!). 

Analist: Any list longer than people will actually read.

Analysis: Thought.

Analysis, Business: Somehow different from thought.

Analysis, Business, Monkey (MBA): See “Software Purchased on Golf Courses.”

Analysis, Data: Plural form of “Analysis, Datum”.

Analysis, Enough: Would choke a horse (See the artwork “Body of Work” at top).

Analysis, Strategic (nee Enterprise): “Find what’s broken that can’t be spoken.”

Analysis, Business, System: Fixing golfware at 50X the cost of “Analysis, Business.” Also – definition of “pay me later” in the popular colloquialism.

Analysis, Psycho: For that special “someone” stakeholder.

Analyst, Psycho: “Stake” holder for that special someone.

Analytics: The idea that increasing the amount of “garbage in” will – what exactly?

Aorist: Tense in ancient Greece, indicating a past activity that is done, with no reference to any structure, beginning, middle or end. Example: “The Ionian Peninsula Project (ancient Greece), made me nuts” (Tense – see how it works ). In this “tense” the event is one whole unit, all over and done (perfective). As opposed to “It made me nuts not knowing how the ionian Peninsula project was doing last Julius / Augustus” (imperfective) (You can look it up! Thanks Wikipedia!)

Aorta: The second word starting with “Ao”, including all its variants.

Aoudad: The third word starting with “Ao” (that’s all folks – beat “Aj” by two).

Approach, Solution: With great care, always asking it to “Put the spaghetti down and step away from the door.”

Aqua: Standard windows color, the use of which is almost always over-use (See “MAN!, Aqua, AGAIN?!”

Architecture, Network: Cisco Kid, was a friend of mine (please, no calls, I try).

Architecture, Software: See “Vaporlayer-ware”.

As-Is: A factual state of operations with as many versions as there are stakeholders (See “Az-Iz”).

Askew: Major requirements gap, as in “I’m not goin’ askew”.

At-Last: Project deadline that can always be reached (See “Expectations, Managing Without Getting Caught” for other examples.

Automation: A business solution approach that is worth doing (one that doesn’t move your cheese).

Auto-automation: When computers design and build computer systems.

Auto-auto-automation: When computers design and build self-driving cars.

Auto-auto-auto-automation: When cars design and build self-driving cars.

Auto-auto-auto-auto-auto-automation: When cars design and build self-driving cars for themselves (ba-da-BOOM! cymbal crash – yeah, really, it’s true, deny it if you can in the comments below, AND/OR get credit for defining the successor, which DOES EXIST :))

Autocrashtic: The voice telling you where to turn while you drive, having crossed its fine print when you agreed to the GPS’ license.

Automated: Obsolete, needing improvement.

Automatic: Not as automatic as you think (See “Automated”).

Aver: To state a requirement with plausible credibility –
Example: “Programming in modules will increase reliability.”

Averse: To state a requirement with plausible rhyme-ability –
Example: “Programming in modules will stimulate nodules.”

Avoid: A requirements gap resulting from sponsors cancelling meetings.

Awake, Network: Hypothetical ability of certain energy saving network printers.

Awesome: Last ditch attempt to influence a sponsor. Example: “Aw, some stakeholders are better than none.”

Ax, Can Hurt to: “The BA asked the CEO “why”, and got the ax.”

Ayer: Cuando quieren los requisitos para la sistema.

Az-Iz: A distant product owner with as many aversions as there are stakeholders (see “As-Is”).

Enjoy! And give BA-elzebub (not me!) some “B’s” below should your Brain Burst Bubbling with BA-slanguage Bonanzas of BA-rbarisms 🙂

How about definitions for Baseline? Button? Best Practice? Box? Benchmark?

Don’t forget to leave your comments below.

Good Practice, Best Practice and 1984

Written by Duncan Watts on . Posted in Articles. 1 Comment on Good Practice, Best Practice and 1984

George Orwell got it

Whenever I hear the term “Best Practice” I think of 1984. Not the year, the novel. George Orwell tells of doublespeak, the language of the oppressive state. In doublespeak meanings are reversed: “War is Peace”, “Freedom is Slavery”,” Ignorance is Strength” and so on.

Words are powerful, as Big Brother knew, and repetition can change meaning. So it is with “Best Practice” which now really means “Mediocre Practice”, since it isn’t what “The Best” are doing merely the average.

But that isn’t even what I dislike most about the term. Worse is the implication that the pinnacle has been reached, after all what’s better than the best? So by a combination of repetition and implication mediocrity is now installed as the most desirable state.

IT is still growing up

Information Technology as an industry is in its infancy. It started in earnest fewer than 60 years ago. The reality is we have very little idea how to create and operate efficient, robust and usable software that meets the need of our users.

In another 60 years people will look back at the primitive state of our tools and methods and laugh, just as we now laugh at early attempts at medicine – think leeches! We try to make ourselves look respectable. We copy ideas from mature industries like architecture and engineering. But the reality is that IT projects are still regarded as failures 60-70% of the time.

Calling what we do today “Best Practice” is so wrong it’s not even funny. I know it’s just marketing, but as Orwell knew, words are powerful and what starts as a harmless phrase soon comes to represent truth.

Good Practice

So how do we change this? First we stop using the term “Best Practice”. When you find yourself reaching for this phrase, substitute “Good Practice” instead.

“Good Practice” is always worth striving for, and does not imply that any sort of pinnacle exists. It’s not complacent. It’s open to change and improvement and constructive criticism is welcomed. There is recognition that improvement is always possible. There is always room for something better.

If I’m still working in IT in 60 years, there will still be “Good Practice” – although it won’t look anything like what we do today. Hopefully we’ll also have left the whole idea of “Best Practice” behind us – with the leeches.

Don’t forget to leave your comments below.

Back To The Future: Two Ways To Develop Better Future State Skills

Written by Bruce Harpham on . Posted in Articles. 2 Comments on Back To The Future: Two Ways To Develop Better Future State Skills

A key business analyst skill is describing the future state of a project. After the dust settles, what does the customer get? What will the website do? Articulating answers to these open ended questions is a key ingredient to the project planning process.

Producing a future state document requires creativity and strong relationships with stakeholders. In this article, I will cover both of those areas. By implementing these ideas, you will be able to make a greater contribution to your projects.

Tip: For guidance on how the future state concept fits into business analyst deliverables, read Sergey Korban’s article here, The Structure of Business Analysis Documents.

Improving your ability to develop the future state is a skill that has value beyond any one project. It is a way of training yourself to see opportunities. Rather than simply stating “improve process X by 5%”, you will have the capacity to ask bigger questions. Does it make sense to keep the process in place? There’s no point in improving a process that fails to create value.

Work Out Your Creativity Muscles With These Exercises

“Creativity is a great motivator because it makes people interested in what they are doing. Creativity gives hope that there can be a worthwhile idea. Creativity gives the possibility of some sort of achievement to everyone.

Creativity makes life more fun and more interesting.” – Edward de Bono

When you start a project, the desired future state is often vague. In the early stages, the project vision and project charter may still be under development. That is where your creative approach adds significant value. 

Here are six other ways to improve your creativity skills at work. Practice these ideas and you will soon become the most creative person on your projects.

  1. Ask “Why” three times. Asking multiple times is important because many people provide unhelpful answers at first (e.g. “that’s the way I was trained.”)
  2. Study products and services outside of your industry. Jim Collins and Jerry Porras write about Nordstrom’s legendary customer service in “Built to Last: Successful Habits of Visionary Companies.” Part of Nordstrom’s success is due to training all staff in customer service.

    Industry provincialism – studying only what your immediate competitors do – is a sure-fire way to limit your creativity in coming up with new ideas.

  3. Read “The Ten Faces of Innovation” by Jonathan Littman and Tom Kelley to learn about how industrial design IDEO approaches product development. In reading the book, I found “The Anthropologist” concept the most interesting.

  4. What would the ultimate customer say about this project? When you work on projects, you may think of your customer as another employee of the firm. The ultimate end customer is the person outside the organization who hands over their money to buy products and services. Focusing on the customer is one way to cut through the complexity that plagues projects.
  5. Forget Constraints For A Few Minutes.
    Constraints – limited time and money – are an ever-present reality for business analysts. At times, “excessive realism” hurts more than it helps. What would your project achieve for customers if the CEO handed you a blank cheque? Aim to come up with at least ten ideas!
  6. Pursue Creative Activity Outside of Work.
    When you’re a driven professional, it is easy to fall into the trap of thinking about work constantly. For the sake of your own happiness, you owe it to yourself to periodically explore a creative activity.

If you work with Excel and PowerPoint all day, consider experimenting with painting, drawing or music. In addition to intrinsic benefits, these pursuits help me to relax. That way, I’m able to be refreshed when I return to the office.

Work On Your Interpersonal Skills To Build Better Relationships

“The most important thing in communication is hearing what isn’t said.” -Peter Drucker

As knowledge workers, we communicate for a living. As you work on building a future state or a project vision, it is common practice to seek input from stakeholders. A large project could seek comment from sales, marketing, customer service, legal and other units. Some stakeholders will enthusiastically share their views while others will be taciturn.

As business analysts, we need to tools to work effectively with people. In the early phases of a project, you have the opportunity to build effective relationships. The following five tools and resources will help you work better with your stakeholders.

1. Get Your DISC profile and learn how to use it.

I learned about the DISC ( ) behavioural profile from Manager Tools. This instrument is extremely helpful in understanding your communication behaviours.

2. Take The Dale Carnegie Course.

One of the longest running business skills courses in the world, the Dale Carnegie Course comes highly recommended by Mary Kay Ash, Warren Buffet and Zig Ziglar. The course takes place over a number of weeks and offers ample opportunities to practice communication skills and receive feedback.

3. Talk About The Elephant In The Room.

Some people get nervous when analysts and project managers start talking about projects and the future state. The project can be seen as criticism of the people who run the status quo.

Address this concern openly by focusing the conversation on the future. Resist the urge to get embroiled in fights over the past.

4. Go Slowly.

Relationships with stakeholders are built over time. If you are meeting someone for the first time, they may be wary of you and the change you represent. Fortunately, you can build trust over time by keeping your word and communicating frequently.

Tip: Don’t rely on one mode of communication alone. For example, if you tend to use email, add occasional phone calls to your stakeholders to improve the relationship.

5. Practice Active Listening Behaviors.

Did anybody ever teach you how to listen effectively? It is not a skill that is widely taught despite its importance. Practice the foundations of active listening – maintain eye contact, take notes and periodically confirm your understanding verbally – to signal you are paying attention.

Tip: A classic active listening technique involves saying: “I understand that the invoice process takes up half your day – did I get that right?”

Discussion question: What is your favourite way to build the future state and get your projects started?

Don’t forget to leave your comments below.

Tips for Working with Off-Shore Stakeholders

Written by Robin Schreier Hohman on . Posted in Articles. 1 Comment on Tips for Working with Off-Shore Stakeholders

In this global economy, facilitated by the Internet, Business Analysts are asked more and more to work with stakeholders who are located all over the world. Several issues can be challenging, such as setting up meetings that are convenient for all attendees, working on deadline when stakeholders are several time zones away, and understanding people whose native language is different than yours.

Time/Attendance Barriers

Depending upon the team’s locations, workday hours can be problematic. While sometimes you will be able to wait a day to get a response to an e-mail or a document review request, occasionally you will have to work after-hours to accommodate a time zone difference.

Tight deadlines call for more creative measures. On a recent project, I worked with technical and QA teams in Manila, which is 14 hours ahead of New Jersey. Working with the QA team was particularly challenging when I was asked to be the test lead for User Acceptance Tests (UATs), and the turnaround for defects was three hours.
Since I was on-call 24×7 for the tests, I worked from home so I could sleep between defect calls. This enabled me to facilitate solutions within the short turnaround. If I hadn’t done that, there would have been a one-day delay between issues and solutions, and even easily fixed items would have been dragged out. Working this way enabled us to get the work done on time, and the project met the go-live deadline.

Language Barriers

The global workforce is often made up of people who speak English as a second language. Sometimes, the on-shore workforce also speaks English as a second language. If you’re a native English speaker, this could present some challenges to understanding each other. Even native English speakers sometimes have trouble understanding each other; for example, I have a hard time understanding Australian slang.

Most of your interaction with the offshore team will be on the phone, sometimes on conference calls. It’s hard enough to figure out who’s speaking and what people are saying on calls with a large group of attendees; it’s more difficult when there are language barriers.

There are several actions you can take to get around the problem. For example, if you’re chairing a requirements meeting, try to use visual aids where possible.

Make sure to send an agenda and accompanying documents out with the meeting invitation if at all possible.

Sending artifacts two minutes before the meeting ensures everyone will be reading them, not paying attention to you speaking.

Make it clear that you are open to answering questions during any presentations or while working the agenda. If people are hesitant about interrupting you, key information will be missed.

A good rule for getting the most out of a conference call, regardless of language, is to make sure you ask follow-up questions about anything you’re not completely sure of.

If there are language barriers, a gentle, “I’m sorry, I’m not sure I understood you, could you please repeat that,” goes a long way to resolving issues. Don’t be afraid to ask people to slow down, or to repeat what they said.
it’s effective to repeat back to someone what they said. That way you will both know if you are grasping the concepts and details, or if you (or the stakeholder) missed something.

There are applications that can facilitate conference calls, such as Cisco WebEx and Citrix GoToMeeting. They both offer HD video, and enable attendees to view each other’s computer screens, which allows you to give PowerPoint presentations without boring everyone to tears. You can also share other documents, questions, and strategies.

I also use WebEx for presenting and discussing applications that are partially built or in beta. It gives people on the phone a better idea of the functionality than documentation and screenshots can, and it also gives people real-time experience with the app. Nothing beats working with an app for understand the user interface and functionality.

After a conference call, it is particularly important to follow-up with a clarification e-mail to ensure no information was lost in translation. You should always send a follow-up e-mail with key points and dates anyway. Write simply, “This is what I understand from the meeting,” followed by a bulleted list. If you know you missed some answers, repeat the questions in the e-mail. Don’t assume or guess.

Also, when writing for a global audience, remember that English, like any language, is filled with slang and idiomatic expressions, words that means something different when put together than they do individually.
Just state the facts, and, as always, strive for the clearest language possible. For example, instead of saying, “we have a tight deadline so we’re going to jump in feet first,” say, “we have a tight deadline, so we’re going to have to learn quickly.” If you use idioms, you will spend time explaining what you mean, or people will simply gloss over the words and miss important ideas. Remember, business analysis is all about getting the right information from the right people. Your job is to facilitate that process.

Don’t forget to leave your comments below.

3 Amigos in Agile Teams

Written by Robert Galen on . Posted in Articles.

I think it was George Dinwiddie that first coined the term “3 Amigos” in agile development around 2009. The analogy was akin to the movie from the mid 90’s by the same name. The Amigos in the agile sense are functional roles:

  1. Developer(s);
  2. Tester(s);
  3. and the Business Analyst or the Product Owner.

It could literally mean more than three as well. The point was, balanced collaboration in agile teams across these roles. George was alluding to these roles from an Acceptance Test Driven Development (ATDD) perspective. He wanted these three constituencies to be heavily collaborative (conversations) around the Acceptance Tests or Acceptance Criteria for each user story.

In my classes, I literally explain this as an “extension” of agile team pairing—in that I’d prefer the pairs to be converted to “Triads” around each story. Believe it or not, Ken Pugh leveraged the term Triad in his book on the same “ATDD-ish” driven topic (see the references).

3 Amigos Meeting

Recently I’ve heard of teams scheduling 3 Amigo style meetings as a part of grooming their backlogs. The idea is to create a checkbox for each user story where it has to be “3 amigo-ized” before it’s deemed ready for sprint execution.

I explored this notion of readiness in a previous blog post.

While I like this idea, and I certainly think making it a part of “Ready” is quite creative, I’m slightly troubled by the practice. I personally think the 3 Amigo’s analogy is less of a meeting and more of a collaborative mind-set.

So when do the “Amigos” meet?

Certainly they meet as part of Product Backlog development and grooming. I think that’s a given. But, I’d like to say continuously as well, for example:

  • Collaborating in the Sprint Planning meeting around how the stories fit into the Sprint and what the Sprint Review will look like from a cohesion perspective.
  • Chatting when each story is “first picked up” within the Sprint to ensure the team understands the nuance of the story and how to effectively design and test it.
  • During story development, the Amigos periodically check in together to ensure the story is on-track. Usually demo’s of partially completed code drive the discussions;
  • Once the story is complete, the Amigo’s gather around it and execute it. Going over acceptance criteria and other attributes, until the Product Owner is satisfied and “signs off on” the story;
  • But their role isn’t quite over. The Amigo’s play a strong part in demonstrating the story in the Review, gathering feedback, and digesting whether the story is truly complete. If so…they move onto the next, and the next, and…

What it’s not…

At the risk of “picking on” Jon Kruger (see references), I want to use part of his description to make a point:

Outcomes

The primary outcome of the three amigos are acceptance tests written in Given/When/Then format. Actually writing these out can take a little time, so we don’t do that with everyone sitting in a room. Typically a developer or a tester will work on it outside of the meeting, and once they have the scenarios all written out, then we do a quick review with everyone else that was involved in the original three amigos meeting to make sure that we all agree with what was produced.

I beg to differ with Jon. His description is much more focused on the 3 Amigo’s as:

  • Implying a meeting with specific, process-driven activity;
  • Implying exhaustive scenarios, written in advance;
  • Implying a prescriptive format of Given-When-Then;
  • Implying sign-off on acceptance tests, prior to the story entering the sprint.

What he, and many others seem to miss is the mind-set part of the Amigo’s that is continuously happening around the team. Please don’t loose that focus in your thinking.

Wrapping up

George, Ken and many others have struck on the collaborative power of these three roles within agile teams and their work. Don’t get caught up on it implying a meeting or any other ceremony, although those things may be outcomes of it.

Instead, consider it a role-based reminder of who needs to collaborate around the work that agile teams are producing continuously. Also think of it as a pairing surrounding sprint activity (the work) rather than a meeting-based activity (talking about the work). I think that was always the primary intent.

But please, do talk about “Amigos collaboration” early and often within your teams. The real point is that you’ll build better, more valuable, and more relevant software as a result. Now isn’t that something worth hollering about?

Stay agile my friends,
Bob.

References