Greatness Comes from Showing Pictures

As far as I’m concerned there are three skills a BA must learn to be great.

  1. How to ask questions
  2. How to explain concepts graphically
  3. How to tell stories

Everything else, and there is a lot to the everything else, takes second place to these three things. The first item is vital because it’s how you learn. The second two are vital because it’s how you should share what you have learned.

We deal in complex ideas. They are not simple. I regularly quote from Rich Hickey’s presentation to StrangeLoop 2011, Simple Made Easy. Rich discusses how difficult it is for us to really grasp multiple, interrelated concepts at the same time. As Business Analysts, this is exactly our job; to communicate multiple, difficult, interrelated concepts (MDIC).

And communicating MDIC needs more than just another document. It’s not that we don’t write a lot of documents, we do. (Yes, story cards are a document.) More important than the document is the understanding. And understanding MDIC doesn’t come best or easiest via the written word. If you want to build understanding, then you need to communicate based on how your audience will best understand. Being human, the best ways to get through to your audience is by pictures and stories.

With pictures (graphics) I see and understand relationships, order, hierarchy, proportion, and all kinds of other things. If the picture is good, I can do this is less than 10% of the time it would take me to read words describing the same thing. If it’s really good, I can do this in less than 5% of the time.

Now, it sometimes takes me 10-20 times longer to develop the right picture, so there are tradeoffs depending on the role and size of your audience, but never underestimate the importance of a good image. If you work with MDIC, you probably need a picture, or twenty.

 

If you are ready to improve your skills in this area, I suggest looking at the following resources:

  1. Visual Models for Software Requirements. Much of what I know about requirements gathering I learned while working with authors, Joy Beatty and Anthony Chen.* Find excerpts here and here.
  2. The Back of the Napkin: Solving Problems and Selling Ideas with Pictures and Unfolding the Napkin: The Hands-On Method for Solving Complex Problems with Simple Pictures, by Dan Roam. His first book was an instant hit because it was provided thought-provoking concepts about why to use drawings and how determine what type you need.  I have not read his follow-up book, but some reviewers like even more.
  3. Anything by Edward Tufte. Seriously, I love all his work. I hesitate going to his website because I can easily loose a day there.
  4. More infographics than explanatory, but I also like Show Me the Numbers: Designing Tables and Graphs to Enlighten by Stephen Few.
  5. Visual.ly. Hundreds of great infographic examples. A good resource when you need a leaping off point for your idea.

* Author’s Note: I heartily recommend their book even though I do not yet own a copy. One, I have that much faith in them. Two, I am waiting to get a signed copy of the book.  

 

What books and resources would you add to my list? Please let me know below!

Is Agile Just for Developers?

Are you a scrum master, coordinating with another team? You might be told, “Why isn’t that done? It should be ready by now.” 

Are you a business analyst, talking about a change that doesn’t impact today’s stories? You might be told, “Don’t mention it during the stand-up meeting.” 

Are you QA, trying to determine if this is a bug or not? You might be told, “Don’t you see the developers are busy? Why did you interrupt them while they were coding?”

And so on.

It’s an epidemic. Agile developers treat their non-dev teammates as part of their personal fiefdom, there to serve. Preferably quietly, so you don’t interrupt their thinking while they are developing. And woe unto those who are not present when called upon.

Developers are the gravitational center of the team. Everyone and everything revolves around them. For the last 5 years I’ve been saying, “Agile is methodology by developers, for developers.” I’ve been watching this behavior for years. It’s irritated me for years. But is it wrong? Should developers be the center of a team’s universe?

Picture of Andromeda Galaxy taken by Hubble Telescope

 

Where’s the value? 

First, we need to agree on a basic metric. The only time software is valuable is after it has been delivered to the users. Software sitting in on personal workstation doesn’t add value to a business or consumer. Software waiting for the next release cycle isn’t providing anyone any value. It might be “done,” but it’s not giving anyone any benefits until it’s used.

I’m a business analyst. It’s incredibly important to understand the business goals when you’re building software. A good scope document doesn’t add value. Detailed specifications don’t add value. Designs and tests and servers do not add value, either. Only working software—working in the hands of users—has a chance to deliver value.

 

Theory of Constraints (link)

If working software is the primary measure of how we add value (See Agile Manifesto Principles), then we need to organize the software development process to get more software out the door. How do we do that?

Eliyahu Goldratt, a physicist who became a management guru, noticed manufacturing lines were organized to maximize the use of all the machines. This was making accountants happy, but it caused problems with extra work, waste, and a growing warehouse full of partially completed products. Goldratt determined manufacturers can make more money by organizing their production lines for consistent throughput around the bottlenecks (constraints).

The same problems, and solution, affect software development. Agile provides a set of tools for software projects, optimizing for the bottleneck, developers. Keeping developers focused leads to a more productive team. Optimizing for developer throughput (for example, having BAs and QAs nearby to answer their questions) means working software is delivered sooner. Optimizing for developers means you increase the chance real value will be delivered. Because the real value of software comes only after it’s delivered, it makes sense to be organized around developers.

 

What about other bottlenecks? 

The truth is, processes have more than one bottleneck. After you optimize for the first bottleneck, you need to be ready to discover the next one. It takes diligent focus to watch the process and work on the next bottleneck. You cannot stop at the first one; bottlenecks are everywhere and you need to continue to watch and optimize.

Developers, because of their role, have a huge number of bottlenecks. They need the right level of requirements, properly configured workstations, the right tools, a good environment for checking in their code, time to understand the technology stack, available test systems and data bases, automated tests, and so on. If you are on a project long enough, you may find this list whittled down. I have never seen it eradicated, but I have seen it get pretty small.

 

What’s right?

Unfortunately, and I think this was part of my ongoing frustration, teams are not good at optimizing for other parts of the process. I’ve been parts of teams where the biggest bottleneck isn’t with supporting the developers, it’s with the testing or requirements supporting development. It’s not that teams cannot say, “I see you need help over there.” Rather, they seem to acknowledge the problem and then think it will go away.

Agile is right. Organizing your team for consistent throughput of working software provides the most value to customers. Supporting developers leads to better software, quicker. It’s the teams that are failing the process. When your team has a problem, discuss it. Work on it. Eliminate it.

Agile isn’t just for developers, but it will be if you don’t pay attention.

 

Do you agree, is this the right way to develop software?
Do you think it’s a problem? Why? Please leave your comment below.

Measuring Requirements May Reinforce Bad Behavior

Have you ever heard this phrase?

“What gets measured, gets done.”

It contains huge truths about human nature, or at least my nature. I pay more attention to something when someone else is paying attention to it. I didn’t have to study the Hawthorne Effect to know this. Looking at my own life, there are lots of examples where if the boss was looking, I did my stuff. Where they didn’t care to look, I soon learned it was safe to ignore this area. And I often did.

More relevant to being a Business Analyst, I was brought into one company to train their new BAs. We spent lots of time covering the basics and then we started working on projects. The documentation was very uneven between the BAs (including me), so I said “Everything has to be peer reviewed before it goes out of the team.” And within a couple months everyone was writing great requirements. Really great. A couple months later, after we had stopped our internal reviews, the clarity and readability of our documentation was in the toilet. We had fallen back to our old habits. Just knowing a peer was going to review our work led everyone to do better work. There is no doubt in my mind, measurement and feedback can and do improve performance.

Unfortunately, most requirement metrics don’t help a BA, a project, or a team. They hurt it.

Typical Requirement Metrics

Measuring requirements can be difficult. Here’s a list of easy-to-gather requirement metrics:

  • Quantity (of use cases, requirements, user stories, process flow diagrams, etc.)
  • Volatility due to scope changes
  • Volatility due to technical & design changes
  • Volatility due to missed requirements
  • Volatility due to changes to existing requirements
  • Volatility due to clarification required
  • Defects due to requirements
  • Schedule variance due to poor or missing requirements
  • Tool compliance
  • Process compliance
  • Comparisons of the above versus:
    • initial estimates or baseline
    • time
    • project phase
    • project size
    • scope

These metrics have a couple elements in common. First, they are relatively easy to measure and calculate, presuming you have the right tools in place. I think many requirement management systems have been sold because for the first time companies will have metrics about requirements! Second, they all help ensure a team is builds correctly and in accordance to the original vision of the product.

Value?

I think it is important to ask, “How do these measurements benefit a team or project?” When I look at the above metrics, the focus seems to be on comparing requirements from one phase to the next, from how well did we understand the needs at the beginning of the project to how what was built at the end, to ensuring the process was followed. These all help teams “build right.” Which is important, but I think it is significantly more important to ask if the team is building the “right product.” Take a look at Gojko Adzic‘s chart from Specification by Example:

This chart describes my very real concern about requirement metrics. They help us build right. They help us ensure everything is checked-off the list, but none of the metrics push us to break the mold and build something great. They help us build something we planned months ago. I want to reinforce BA behaviors that push us to ask hard questions, pushing us up the value stream. I want us willing to take a new direction because we can see a project could be better. We should love killing projects because the value has already been reached, or never will be.

Behavior Reinforcement

If you want to improve teamwork, you need to reinforce behaviors that support acting like a good team member. If you reward people based on individual behavior, you are undermining the goal of improving teamwork. Similarly, it’s not uncommon to find metrics being misused. Sometimes the problem is minor, metrics are unused and the only impact is the wasted effort to gather and analyze them. Other issues include inappropriately punishing a team because of metrics and unintentionally focusing more on metrics than on delivering business value. None of these are part of the initial goal when a company or team decides to track information, but they are pretty easy to find.

Better choices

When you have to measure requirements, the first thing I want measured is their quality. First, define what a quality requirement ( or use case, or user story, or . . .) looks like. Then audit everyone against the standard. This ensures the quality of what BAs produce stays high. If your team is currently using a different style, template, or process for every project, this step will also push for more process compliance.

In a similar vein, I encourage teams to ensure everything goes through a peer review. I’m not sure metrics around this are especially valuable, but it might help with enforcement.

Lastly, think about the dimensions in Gojko’s chart above. Think about what’s really makes a difference. Fellow ThoughtWorker and Agile Manifesto signatory, Jim Highsmith has a great talk on this and often discusses with executives interested in enterprise agility. You should read his post and learn more about the most important metric of all, delivered value.

 

IIBA Chapters Should Care About BA Managers

The primary mission for most IIBA chapters is serving the local members. We serve our members with chapter meetings, training on tools and techniques, and networking events. Many chapters offer help preparing for CBAP certification, online discussion forums (Nice example here [IIBA Dallas]), information about local BA jobs, and more.

But what are we offering Business Analysis Managers? In the first post of this series, I talked about how BA Managers are underserved and need a network of peers. It’s not surprising; the BA discipline is rather new and only becoming organized in the last decade. Historically, the folks who supervise BAs have a background in development, project management, or were part of the business operations. When your profession is new, you can reasonably expect the management around the profession to be similarly inexperienced with subtleties of the work.

I mentioned the networking luncheon for them, but this is the first event for BA Managers I’ve ever heard of. We have not even held the event yet and already people have asked if this is being held or repeated in other cities. So far, the answer is no, but I certainly hope others will pick up this torch and carry it on. The need is too great to limit this to just one city.

Also, Managing Business Analysts was just published by the IIBA, another good step to give some support to this audience. Lastly, many chapters also offer an annual moderated panel discussion where BA Managers and IT executives answer questions from BAs, but this is pretty directly related to BA needs, not their leaders.

In the second post, I listed many reasons why BA Managers should care about local IIBA Chapters. The list isn’t complete and focused on BA Manager goals, but this isn’t bad. It’s just recognition we all act, on most levels [link to Maslow’s Hierarchy here], in a self-serving manner. Let’s acknowledge this point and move on.

In this final post, it is time to talk about why local IIBA chapters should be working overtime to get BA Managers involved. It’s in their best interest!

Relationships Increase Attendance

One of the biggest reasons people stay, or leave, their job is due to relationships with coworkers [http://www.apa.org/monitor/apr07/social.aspx]. Relationships are key to a happy working environment. The same is true for organizations. Relationships are key to a happy and growing a IIBA Chapter.

You should accept as a given co-workers and bosses will influence how many and how often BAs will attend your meetings. If you own a restaurant and upset your customers, they won’t come back. When you build a good relationship with customers, they are more likely to return. Building a positive relationship with supervisors forms the basis for a strong relationship with their staff.

Building Your Membership

Let’s talk about the most obvious and overarching reason you, the local IIBA chapter, should focus on satisfying BA Managers; their employees are Business Analysts! Talk with BA Managers in your area and let them know how you are working to improve the discipline of business analysis.

Good managers should understand you are helping them when you help the profession. Employers want to work with you when are helping their staff. Employers are often willing share the areas you can help their staff grow in preparation for upcoming challenges. Maybe the managers know about upcoming projects, projects needing more facilitation skills, or presentation ability, or how to document for that new Scrum style they are about to adopt. Building the skills of individual BAs helps not only the individual, but their employer.

When you are partnering to improve the skills of BAs, you are helping local employers. What company or manager turns down a partnership that improves their staff?! When bosses and employers understand your goals include building relevant skills; BA Managers will encourage their staff to attend your meetings.

Finding Good/Great Members

In general, there are two kinds of folks who will attend IIBA meetings because their managers attend or suggest the staff attend. The first kind is a “suck up.” (I was going to type something a bit meaner, but you get the drift.) These people will attend and, at best, fake involvement to win some brownie points. So what? Give them a reason to get involved and maybe you can win them over! If not, it doesn’t hurt you to have them attend your functions, does it?

The second type is the Business Analyst who wants to get better. These are the mother load! This is the stuff you really want to find. BAs who care about their job? Coming to your chapter meetings and functions? Learning more about their professions? PLEASE, SEND ME MORE!

The truth still is, many BAs are unaware of IIBA and how the chapters can help them grow professionally. Building relationships with BA Managers in your community will give you a pipeline to BAs who want and need what chapters have to offer! You may never find these folks without an insider in their organization. Why wait for an IIBA member to be hired into Acme Rocket Co? Just go talk to the relevant manager and show them what you can do for their employees. Let them do the recruiting for you.

 

Other articles in this series on BA Managers: 
Part I—The Hidden Problem of BA Managers
Part II—BA Managers Should Care About IIBA Chapters

A special thanks to Neil Bazley, IIBA Vice President of Chapters (@neilbazley) for his early review and advice on this series.

 

[editorial update] After posting this article, I realized I missed a key reason why IIBA Chapters want local Business Analysis Managers to attend. If you are the first person to list the reason I thought of in the comments below, I will send you a copy of Managing Business Analysts. Contest ends Feb 16. Good luck!

BA Managers Should Care About IIBA Chapters

I have met BA Managers who attend IIBA meetings, but it’s never been very many or very consistent. Most of them were active BAs and really enjoyed the profession. A few come announcing a job opening and often leave following their pitch.

This is a serious mistake, one of the biggest mistakes you can make as a BA Manager.1

I’ve already written about how BAs are growing professionally because they are setting their own expectations (see Part 1). Implicit in this is the need for BA Managers to learn more about the role, and then take this understanding to set a high performance bar. Setting high expectations is key to your team’s success and an important reason why you should become involved in your local chapter. But it goes far beyond this.

I typically learn something at every chapter meeting. Sometimes it’s from the presenter, a new tool to try out or a variation on a technique to increase its effectiveness. Sometimes it is from someone who has gone through a similar situation, or can give an outsider’s opinion on my problem. Whatever it is, I often learn something new and bring it back to the team, encouraging them through today’s challenge; something to make our lives back in the office just a bit easier. It also shows my team that I am always trying to grow, setting an example of how I want them to pursue self-improvement.

Beyond setting the right expectations and example, I recommend involvement as an investment; an investment in building, finding, and selecting your future staff. Here are some of my key reasons and rationale for being involved.

Participating improves the community. Whether I am presenting to the chapter, or asking a serious question about how to apply the speaker’s tool in the workplace, participating helps improve the skills of local BAs. Because I will one day have to hire from the pool of local BAs, helping to improve their skills today is helping myself tomorrow.

Attending meetings says, “I get it.” BAs are still a bit skittish. Many have struggled to receive recognition of what they do and why, so a little encouragement typically goes a long way. This is one of the few times where just showing up can make a difference, because merely by attending you are showing the community you care about it, you want it to succeed. Being personable at the local chapter meetings is a quick way to become the favorite BA Manager in town.

Knowing BAs gives me early insight. One of the biggest challenges for BA Managers is hiring the right personnel. Being an active participant in the local chapter gives you a network of connected BAs who will take your phone call and give you honest feedback on their current and former peers. Understanding a candidates strengths and weaknesses before you make a job offer is a huge advantage.

Preferred bosses get more candidates. Finding the perfect job, or candidate, is often about being part of the right network. I love job boards, and good recruiting firms are worth their fees and more, but neither one gives you the right network. If you are going to hire a BA, doesn’t it make sense to know them? When I am hiring I want to get more to find qualified candidates right away, something I do not get by depending on others to post my open position.

You may be able to pay competitive wages, but do you pay the most in your area? You might like what your company sells or stands for, but how does it compete with the cool start-up across town? These areas are just the tip of the iceberg when it comes to things you cannot control about your company and the offer you can make. One thing you can do, a deciding factor for many job seekers, is offer an environment where you are known as a good boss. Attending your local IIBA meeting is a small thing, but it’s something a bad boss wouldn’t do.

Why don’t you set yourself apart and attend a local chapter meeting? I’m guessing they’ve got an upcoming meeting and would love to see you.

Post script: Ramit Sethi has a good article on building Natural Networks. His audience is different, but his argument is strong and reinforces my points.

Top performers build their network BEFORE they need it. That’s how they can get laid off on a Monday and have a better job lined up by Friday. Read that sentence again, please — it means that top performers are comfortable meeting people and cultivating relationships with no specific purpose. In fact, it’s almost always to help the other person!

The same is true when you occupy the hiring side of the desk, top performers build their network before they need it.

 

1: I don’t care if your title is Business Analysis Manager, Development Supervisor, Director of Business Analysis, or Janitor. If you have a staff of people, dedicated to understanding the business needs & defining software / system requirements, and your role involves, hiring, reviewing, and growing them to meet the needs of the business, then you’re a BA Manager.

 

Other articles in this series on BA Managers: 
Part I—The Hidden Problem of BA Managers
Part III—IIBA Chapters Should Care About Business Analysis Managers

A special thanks to Neil Bazley, IIBA Vice President of Chapters (@neilbazley) for his early review and advice on this series.

The Hidden Problem of BA Managers

As a profession, business analysis has come a huge distance in the last decade. Most Business Analysts now understand how to elicit good requirements, want a defined project scope, can write a good requirement, understand and use either User Stories or Use Cases, know how to negotiate agreement between business and technical partners, and so on. What the profession takes for granted today was hard to find 10 years ago.

During this time it was easy to find me arguing about how poor the business analysis profession was practiced. Far too many BAs did not have the right background, competencies, techniques, tools, or training. We were floundering as a discipline because we did not know what we were doing. Tony Chen heard me one day and said it was all about poor expectations [from supervisors and management]. I’ve thought about this over the last few years and I think he hit the nail on the head.

The International Institute of Business Analysis (IIBA) is a central reason why the profession has improved so very much. They have provided a number of great things for Business Analysts. We now have a Business Analysis Book of Knowledge (BABoK) and a competency model, a great repository defining the scope of our role and tool for understanding the strengths & weaknesses of a practitioner, respectively. They provide webinars, a monthly newsletter, certify training firms, promote conferences, and even offer certification. The most valuable offering that we, as a professional organization, might have, however, is the opportunity to meet and exchange ideas in person through our local chapters.

It is this networking between BAs making the biggest impact. Even though I can read the details about some technique or tool in a book, being able to ask a peer how it works for them makes all the difference in the world. I still learn from articles and white papers, but discussing this with other BA accelerates my learning far more than reading a second article ever could. It is the connection we have between our peers that has led to the professional revolution.

This combination—a central body providing guidance and the network between people in the BA role—is the primary reason we have improved. We have given ourselves a better definition of who we are and we have been improving to meet our definition. We have set our own expectations and we are growing because of it.

But we are still missing something. While a small few managers do have great expectations, most do not have a strong enough understanding of the discipline and the benefits to have well-defined expectations. One of the most common conversations I have with BAs is about explaining our role to those who would manage us.

Part of my standard rant mentioned BAs being managed by supervisors who did not understand the function or how to supervise it1, which just underscores Tony’s point. The poor expectations started with leadership.

As much as we have improved our profession in the last 10 years, especially the last 5, we still have a long way to go and I think one of our biggest hurdles is helping BA Managers2 understand their function.

Many BAs have been busy learning about their profession and sometimes arguing for more resources to continue their self-improvement. A few have done a good job explaining their role and what the expectations should be for BAs. Not everyone feels so equipped. Not every boss wants to listen to employees explain what the role is and isn’t. Not every boss has the time to figure this out; they already have a full plate.

The IIBA has recently recognized the need to help BA Managers in their new compilation, Managing Business Analysts. Published last fall, it is the first resource I know of to help our supervisors.

A few years ago, Allan Dunn asked me if he could buy me lunch and introduce me to another BA Manager. I had spent much more time in my role than she and he thought we might benefit from a conversation. Our lunch was one of the best meetings I had that year. I grew from both learning about her experience and sharing my own.

I soon realized this was a missing part of what every BA Manager needed; a network of peers. All of which leads me to say I am very happy to announce we are building a network of BA Managers here in Dallas, TX.

As the new president of the IIBA Dallas Chapter, one of the very first things I have done is organize a networking event solely for BA Managers. Our chapter’s premier sponsor, MDI was happy to to sponsor a very nice luncheon, paying for 15 managers to come together and network with each other.

As part of this networking luncheon, we are restricting all vendors and anyone who does not manage BA from attending. This is an event for peers to come together and help each other. It’s not about BAs directly, though we’ll benefit. It’s about giving BA Managers a chance to accelerate their personal learning, from someone who is living with the same sorts of issues.

A nice bonus for the inaugural event attendees is our special guest, Kevin Brennan (@BAKevin). Kevin is Chief Business Analyst & EVP for IIBA and a contributing author to Managing Business Analysts.  He’s agreed to speak for a few minutes, take questions from participants, and offered to give everyone their own copy of Managing Business Analysts.

If you manage BAs in Dallas, then please drop me a line. I cannot promise a seat at our first event, but I can certainly place you on the invite list for our next one.

 

1: I don’t care if you have performed the BA role. I believe the best managers are found in those who care about their team, not in those who once did a specific job.

2: I also don’t care if your title is Business Analysis Manager, Development Supervisor, Director of Business Analysis, or Janitor. If you have a staff of people, dedicated to understanding the business & defining software / system requirements, and your role involves, hiring, reviewing, and growing them to meet the needs of the business, then you’re a BA Manager.

 

Other parts in this series on BA Managers: 
Part II—Business Analysis Managers Should Care About IIBA Chapters
Part III—IIBA Chapters Should Care About Business Analysis Managers

A special thanks to Neil Bazley, IIBA Vice President of Chapters (@neilbazley) for his early review and advice on this series.

Waterfall image

Waterfall Is the Wrong Enemy

I was reading The Inmates are Running the Asylum by Alan Cooper when I came across this passage in chapter 8:

“Some of their previous products were successes and some were failure, but the process they used to create them was the same. From this they deduced that the success or failure of a software product is due only to chance; software success is simply a crapshoot. The problem is reminiscent of physicians in the nineteenth century, before it was discovered that the anopheles mosquito carried malaria, who were unsure of the disease’s source. It was thought to float on the evening air, striking randomly, and one’s only defense against the often-deadly fever was luck. After the cause-and-effect relationship was discovered, the disease was quickly brought to heel.”

And reading this, I thought “That’s us! We have looked at our randomness and declared Waterfall to be the culprit. Agile is the cure!”

Only, I’m not sure we yet understand the problem. I have little faith agile alone can save us. I fear we have become students of nineteenth century doctors.

The Manifesto signers were right, but all too often we have looked beyond the principals they espoused and cried for process and tools. And in our search for what’s easy to digest, we have missed what is most important.

Waterfall image

The problem with waterfall was not too much documentation, but documentation over conversation and understanding. The problem was not in developing plans, but in blindly following plans that were developed with too little information. The problem is we like simple tools and easy-to-use processes, and we are following them without understanding when they work best.

It is difficult to look at ourselves, our skills and shortcomings, to honestly evaluate a team, and then to cast the same critical eye over our technical environment, our business partners, our corporate culture, a nascent understanding of the marketplace, and more to develop the right version of a process. It is easy to say “I will follow Scrum (or any version of Agile)” and fight for meeting the version you were taught in class. And because you still have to fight for your version against the reticent and resistant, it feels like a good fight.

But it is the wrong fight.

Let us commit to reviewing both the manifesto and the principles. Then let us commit to working on the foundations, rather than just a new process. Because if you’re only changing the process without understanding what you are changing and why, I’d rather you change the lighting and humidity.