If they have eggs . . .

Here’s a great requirements joke, sent by a great friend and former co-worker, Jen.

Milk and eggs

A story which is perfectly logical to all males business analysts:
 
A wife asks her husband, “Could you please go shopping for me and buy one carton of milk, and if they have eggs, get 6?”
 
A short time later the husband comes back with 6 cartons of milk and his wife asks, “Why did you buy 6 cartons of milk?”
 
He replies, “They had eggs.”

Using BDD & Feature Injection

I am very excited to be talking this morning at the Building Business Capabilities Conference 2011. The organizer, Rising Media, has done a fabulous job with over 900 attendees with 4 related, but separate focus areas.

My presentation, Using Behavior Driven Development and Feature Injection to Build Better Software will be @ 11:30 AM in Regency 1. I do hope you will come and hear the presentation.

Notes:

  1. Click for a PDF of my PowerPoint presentation deck, with full slides & transitions. EXTRA: This has just a touch more than the “public” PDF deck you will find at the conference website. It’s something extra for the folks who follow me on twitter & read this blog. All rights reserved, etc.
  2. If you can make it to the talk, then please help me make this a conversation, not a boring presentation.
  3. Huge thanks are due to everyone who helped me learn more about this topic. With a special shout-out to Paul Hammant for the introduction to BDD and Chris Matts for the kind conversation.
  4. Any oversights and mis-statements are someone’s fault. I’m not sure who, but someone is to blame.
Dug, looking for a squirrel

Accountability: It’s Not Just for Stand-ups

Have you ever worked with an especially disfunctional team or group? I’ve run across my share and this story came to mind lately. [If anyone from the old days cares to let me know how the guys mentioned are doing today (privately please, not in the comments), I’d appreciate it! -ed]
 
Dug, looking for a squirrelAnyway, this particular team had two members who didn’t always work well. It was especially bad when they worked together. Maybe my memory has added some oddities, but here is how I describe them: Bentley [names have been changed] is like a Cocker Spaniel, excited by every squirrel running by; imagine Dug, the dog in Disney’s UP. Fred was the old curmudgeon who went off a cliff in the passenger seat of a beat-up pickup truck and while on the way down says, “Yup, I could have told you this was a bad idea.”

In addition to having very different personalities, they also had habits which reinforced the worst in their partner. To give you some background on the work-environment, they worked in Paired Programming. Their computer was set-up with dual monitors, keyboards, and mice. They worked on a single task at a time, most of which should take from 1/2 to 2 days.  Bentley hogged the keyboard and did not share the typing responsibilities well. It was incredibly common to find he spent a few hours digging into a problem unrelated to his work. Fred, also a nice guy, appeared frustrated he was not allowed to type or control the direction. In response to his growing annoyance he would withdraw from the process, often leaning back and literally watching with crossed arms.

Now, they were not on my team, but their colleague, Andrea asked me how I would deal with them. Bentley and Fred didn’t report to her, but to the extent anyone was leading the team, she had the role. The problem was they hadn’t accomplished anything in the previous two weeks. Remember, tasks should take less than two days, but this was two weeks and not one thing was done. Really!

Andrea received a report the team was not accomplishing much and sat down with them for the afternoon. While she worked with them they were able to take three tasks they had started over the last week and move them through to completion. Yay! The next day the team went back to their old ways and completed… nothing. What’s a colleague to do?

I had a couple pieces of advice for Andrea, one set of advice was about enabling both team members to communicate and work with each other. But I also advised her to take accountability to the next level.

Some teams use a daily stand-up to increase accountability. It may be called a huddle or scrum meeting, but it’s all the same thing. The point of the daily stand-up is to get everyone on the same page for the day’s tasks. Everybody states what they accomplished yesterday, what they plan to accomplish today, and lists anything in the way of them achieving their goals. When this is used on a daily basis, most teams find it incredibly empowering for themselves and the team, in part because they are aware of what is happening, in part because they have made a statement about their goals and know they have to speak about their results the next day.

The very best managers I have worked with are incredibly strong at holding people accountable and use a version of this technique. Here are the basics:

  1. Break down the work into a small unit—something that can be accomplished in 2 – 4 hours.
  2. Ask if there are any roadblocks in the way of getting this completed. If yes, deal with this immediately.
  3. Say “Good job. Go do it. If you have any problems, come find me and we’ll knock them down. I’ll be back in a couple hours to see how you’re doing.”
  4. Come back on time and see if the work is done.
  5. If the work is done, congratulate the individual / team and repeat.
  6. If the work is not done, find the problem, fix it, and get a new commitment.

The more you use this method, the more you realize this has power. I think everyone should be managed this way. People in new roles should have shorter time periods. If you are training someone in a fast food or retail establishment, then you might set tasks that can be accomplished in minutes. If you are dealing with an executive the task might be weeks. The key here isn’t the time period, it’s the mutual commitment and follow-up.

I have had staff members who think this technique is micro-managing, but I disagree. I’m not telling anyone what programs to use or keys to push. I am not telling how the work must be accomplished or even asking how it is going to be done. I am asking for a commitment, asking if it’s met, and offering help to clear obstacles. Oh, and I am expecting those around me to treat me likewise.

Take away: Increasing your team’s accountability will lead to greater productivity.

Not for the Faint of Heart

The process of the good life is not, I am convinced, a life for the faint-hearted. It involves the stretching and growing of becoming more and more of ones potentialities. It involves the courage to be. It means launching oneself fully into the stream of life.

Carl R. Rogers

With thanks to Lisa Haneberg of Management Craft for the quote.

Are You “Just One in a Crowd?”

just one of the crowdI was talking a friend about their employer,  Great Software Company (GSC) [names have been changed -ed]. GSC had a reputation for being a powerhouse in the software development field. They hired the best and set them at client problems with flair and gusto. My friend was lamenting they’ve lost their mojo, now they are “just one [company] in a crowd.” GSC is waiting for clients to recognize how great they are. Clients are looking for someone new to solve the problem of the day. And existing clients are often going someplace new rather than turning to their (formerly?) trusted parter, GSC.

Reputations are great tools for a company. A strong reputation, based on effective delivery of innovative solutions is great for a company. It’s also great when you own the problem and you are looking for solution provider. You can check your networks for a company that has the chops you need.

Unfortunately, reputations for most firms in software and high-tech are short lived. The fields are changing at such a rapid pace, very few reputations become “household names.” Whether large, mid-tier, or a boutique firm, it is a rarity to establish a reputations both wide- and deep-enough to impact the client if you are not currently solving the biggest problem they face.

I propose two causes for this. First, the rate of change. You may have been great in programming 4GL languages a decade ago, but who cares today? Website design has moved dramatically in the last three years. Are you ready to move to NoSQL databases? Is your team running with Continuous Integration? Have you heard about the teams looking for post-Agile coaching yet? If you do not have the latest skills, or at least paying attention to the related trends, your clients have every reason to look for another firm for solutions.

My second proposed cause is the ever-shifting audience. Not only is the technology changing quickly, but the people in and around technology are fast moving as well. Heck, it’s not just the people in technology, but the people you talk to every day. You cannot count on your client remembering how you solved their Tough Problem when they have had leadership changes, multiple staff shifts and promotions, or a department reorganization. As a company, you have to find a way to display your talent, your skills, your ability to solve the tough problems.

 

Now, reread the section above and imagine I am talking about you and your role, not GSC and software firms.

Are you “just one in a crowd?” Have you done anything to build a reputation for thorough analysis with the new people on your team? Does the new person in the Operations Department <insert department/customer/client you serve> think you exceed expectations? Are you wishing people would just “trust you” because you haven proven yourself before? If you find yourself wondering why you don’t have the respect you used to, then it’s time to look at what you can do to reassert yourself.

Business Analysts regularly get assigned to new problems and new teams. It’s easy to remember the basics of building a reputation when all or most of the faces around you are new. The situation is very different for long-running teams / projects. It is easy to forget the basics when only one name changes at a time, but it is no less important.

Take the time to make a good impression for everyone added and re-added to your project. Introduce yourself to newcomers, whether they are teammates or executives. Find the chance or make a window of opportunity to prove your skills and capabilities. Show you know how to deliver as a daily habit.

If you’ve built a solid reputation, then kudos! It’s the first step to a great career and interesting opportunities. But keep investing in it. Don’t stop and rest on what you’ve done because building a reputation is only part of the goal. Now go forth and show you are worthy of your laurels!

Take away: Determine how to get the attention of the right people instead of waiting for people to notice you.

Thanks to Global Citizen for the picture above.

Bloom's Taxonomy

Assessing Yourself with Bloom’s Taxonomy

Have you heard of Bloom’s Taxonomy? More importantly, have you thought about how you can use the taxonomy to give yourself a performance evaluation?

 

Benjamin Bloom led a team of educators in the 1950s to identify a taxonomy, or classification, of learning objectives. The committee broke the objectives into three distinct areas, Cognitive (knowledge, comprehension, and critical thinking), Affective (emotional response and empathy), and Psychomotor (physically manipulate body and tools / instruments). For more information, I refer you to Wikipedia and Don Clark‘s articles for more information.

Bloom's Taxonomy

For my part, I want you to focus on the Cognitive function. You can find a number of cool graphics displaying the domain with an online search, but for my part I want to focus on the following chart, taken from “Critical Thinking in the Management Classroom” (by Athanassiou, et al., full reference below.)

Cognitive Hierarchy, credit to Athanassiou et al.

When reading this, I translate it into BA practices:

  • The basics of our job start with Knowledge, learning about and defining our business’ domain, able to answer a developer’s questions about a given process.
  • We daily demonstrate Comprehension, translating business process needs into requirements, paraphrasing and summarizing the business needs into the language of our multiple audiences.
  • Application is where we start to prove ourselves, applying business expertise to answer questions and predict behaviors & outcomes.
  • It takes deeps business knowledge to do good Analysis, understanding not only business definitions, but seeing patterns, recognizing hidden meanings, understanding the context of information, systems, users, etc.
  • Synthesis is all about combining old ideas to create new ones, generalizing for given facts, integrating and designing.
  • Comparing and discriminating, assessing options, and verifying the value of different ideas is part of Evaluation.

Note: Bloom’s Taxonomy was revised in 2000, changing the names from nouns to verbs and changing the order of the last two items. The new list is: Remembering, Understanding, Applying, Analyzing, Evaluating, Creating. It is worth considering if BAs should in fact spend more effort on Evaluation / Evaluating and have less need for Synthesis / Creating.

I want to argue every BA needs to be great. Every BA needs to be able to perform at all of these levels. Every BA needs to be perfectly fluent in each of the Cognitive domain areas. But do they really need to? I am better at some than others. In fact, I am better at some higher levels than I am at some lower levels. Does this mean I’m a bad BA? I don’t think so.

Imagine you could have your pick of three BAs. All three are very good at Knowledge and Comprehension. The first BA is outstanding in Application, applying all the knowledge they have learned. The second BA loves Analysis, in particular digging into business operations and understanding how it relates to business rules. The third BA lives for Synthesis, integrating old ideas into something that seems new.

Now continue imaging and tell me which BA would you pick for a project that has to combine information from four different systems into a single report? Which BA should go to the project with the stable team, supporting the finance department with regular upgrades and system maintenance? Which BA should work on building out a new CRM system to track all of customer interactions?

As you can see, different projects have different needs, different cognitive levels. And as individuals, we are better at some tasks than others. So what does that mean?

It means we need to understand and play to our strengths. It also means we need to acknowledge our weaknesses and look for the best way to support our project and team when the project does not match our strengths. You can partner with others on your team if Synthesis isn’t your strong suit. You can push more decisions to the team if your Evaluation level is weak. You can still contribute to a successful project when it needs one of your weak areas, but only if you are paying attention and diligently shoring up this level.

Here’s a checklist to think about your contribution to your current project, modified from Athanassiou’s paper:

The Checklist

  1. ____  Did you summarize the concepts / goals / stories / requirements covered by your business partners? (Knowledge)
  2. ____  Did you demonstrate you understood what this project was about by comparing it or contrasting it with other projects, requirements, applications? (Comprehension)
  3. ____  Did you connect the ideas from this project to other projects, initiatives, business goals, competitor actions? (Application)
  4. ____  Did you examine the business goals and requirements so that you identified the theories, assumptions, fallacies, and ways of organizing their ideas? (Analysis)
  5. ____  Did you explore the goals and use this exploration to build a new understanding of the business or formulate new ideas or solutions? (Synthesis)
  6. ____  Do your actions demonstrate you critique ideas and solutions based on an understanding of overall business objectives rather than personal opinion? (Evaluation)

Reference:
Athanassiou, Nicholas, Jeanne McNett, and Carol Harvey. (2003). Critical Thinking in the Management Classroom: Bloom’s Taxonomy as a Learning Tool. Journal of Management Education, 27(5), 533-555. Available here (@ $32! for 1 day of access)

Hat tip to Chris Boynick for referencing the above paper and giving me more context to start digging into Bloom’s Taxonomy.

Building Better Acceptance Criteria

As you can see from the widget on the right, I am speaking at the Building Business Capabilities conference this year. I’m super excited to be included as part of baf: Business Analysis Forum, billed as The Official Conference of IIBA. As far as I am concerned, there are three great confereces for BAs in North America, and this is one of them!

They have released the Conference Preview Guide for this huge conference, but I have included my information below so you don’t have to look too hard!

 

Building Better Acceptance Criteria Using Behavior Driven Development and Feature Injection

Thursday, November 3, 2011 11:30 AM
Building Business Capability: Business Analysis Forum, Fort Lauderdale, FL

 

It does not matter if you have a great idea for a software product; you have to communicate this to the developers building your system. Beyond user stories, developers need to understand the value and function they are building. They need good, or better yet great, acceptance criteria.

The secret to writing great acceptance criteria lies in Behavior Driven Development (BDD) and Feature Injection. The fabulous thing, besides the cool names, is they are easy to learn, easy to use, and produce better stories, requirements, tests, & code!

The heart of BDD and Feature Injection lies in using natural language to describe the value and features a system contains. Following a simple grammatical structure leads both writers and readers to understanding the goals and how they will be delivered. This process uses real examples, in business terms, to describe the behavior of the application.

While there are significant benefits for business partners, developers, and testers; one of the key benefits is how this turns Business Analysts and Product Owners from gathers of information to distributors. Rather than constantly pulling information from others, this provides BA’s the tools for pushing information out.

Attendees will leave understanding:

  1. Fundamentals and benefits of Behavior Driven Development and Feature Injection
  2. How to write better requirements / acceptance criteria using natural language and business terms
  3. How to easily develop real-world test cases to prove the feature is working as desired

 

About the speaker:

Jeffrey DavidsonJeffrey Davidson is a Lead Consultant with the global IT consultancy, ThoughtWorks, with deep experience as a mentor, coach, and trainer. An engaging and entertaining speaker, Jeffrey speaks with passion to audiences across the United States on business analysis and agile development.

Jeffrey has had many titles, including Director of Business Analysis & Quality Assurance for UTI, Business Analyst for Dell, Systems Engineer for Raytheon, and Product Manager for Ebay. He is a Certified Product Manager (PMC) and a Certified Scrum Product Owner (CSPO).

Jeffrey’s focus is helping organizations and Business Analysts transition to Agile, delivering great requirements, and building world-class teams.