Skip to main content

Author: David Shaffer

Are You Suffering from Agile Fever?

Have you ever come across a colleague or a family member who has a knack for making every conversation about them?

Do you have people in your social circle who influence every group decision to their benefit? Of course you do! When describing these people we typically say “You know the whole world revolves around Joe!” Do we really enjoy spending time with these people? Of course we don’t because they are exhausting and frustrating to work with. Well let me tell you something, these people have a lot in common with user stories. The user story has become the center of the Agile world. Everything in Agile seems to revolve around the user story. They have become exhausting and frustrating to work with for many of us. How did we allow this to happen? How did the Agile community get to choose the technique we must use to convey the requirements for a solution? The BABOK details numerous techniques that BA’s can master for the purpose of eliciting business needs, determining “wants” from true “needs” and communicating the actual requirements which must be met. Why is the user story being elevated in importance over all other techniques? I have personal experience in “Agile” organizations who are absolutely obsessed with the user story. I’ve also been fortunate enough to meet many of my BA colleagues at conferences who have the same frustration. Why do we seem to be limiting ourselves or over relying on this one technique?

Mike Cohn of Mountain Goat Software is regularly credited with coming up with the format of a user story. I’m sure we’re all familiar by now with the “As a _____, I want to _____ so that I can _____.” format. By no means do I intend to discredit this format or this technique. It can be valuable in the right situation.

However I view the user story as a singular tool within our BA tool belt. One single tool should not be the center of any development methodology. Unfortunately I’ve come across some development colleagues who are infected with Agile fever. Agile fever causes the temporary loss of common sense and logic and is characterized by an irresistible desire to adhere to an irrationally dogmatic process. Those infected with Agile fever latched onto the user story as the center of their world since it seemed to have lots of potential. It has a simple format and it seems that anyone can write them. With the user story as the center of the universe time consuming business analysis could be eliminated and replaced with simple user stories and conversation! What a eureka moment this must have been in the Agile community. I can imagine the crazy celebrations which must have ensued. As many of us are learning this is not necessarily working out as planned. Some organizations that tried to eliminate BA’s or relied entirely on the conversation generated from user stories learned that Agile fever can have serious consequences to their business.


Advertisement

So what does Agile fever look like and how can you tell if your team may be infected? Let me give you some examples. A developer once explained to me that he understood the requirements and knew exactly what we were doing and why. However he demanded that the requirements be reworded into the typical user story format because our group was “Agile”. Agile fever was infecting him to the point that he could not function unless the user story became the center of his world. Once the requirements were rewritten he instantly calmed down and was able to function once again! If project team members are demanding requirement rework so you can be “Agile” then you’re likely infected. Agile fever can also cause Goldilocks paralysis. If you’re not familiar with Goldilocks it is the story about a little girl who wanders into a home occupied by three bears. While in the house she tries out three chairs exclaiming “This chair is too big! This chair is too small! And this chair is just right!” I must warn you that Goldilocks paralysis is extremely contagious and can infect entire project teams very quickly. It is characterized by project teams that spend significant time arguing over the size of the user story. You’ll hear comments such as “That story is too big! That story is too small! “We need to break these stories down” or “This story doesn’t fit in our sprint”. As a BA if you notice teams arguing over the size of a story and wasting significant time over it then be aware that they are infected with Goldilocks paralysis. It is treatable with an injection of common sense and reason but it may take a while to take effect depending on how high their Agile fever is.

So what do I suggest we do as BA’s to counteract this over reliance on the user story? I propose that we remember that the word “analysis” is in our job title. Therefore we must never forget that great analysis is what our methodology should revolve around not a single technique. Don’t let anyone influence you away from using other techniques. Great BA’s utilize the right tool or the right technique at the right time to uncover the business needs that will drive business value. The user story is one way to convey that information but it does not need to strictly adhere to the standard format. I have successfully used fully dressed use cases (Oh my!) on a project since they happened to be the best way to convey the requirements for that particular project. Don’t be afraid to think differently and convey the requirements in what may seem to be an unconventional way because it doesn’t fit into the Agile prescription. Drawing a picture, creating a wireframe or using some other visual technique will drive conversation much better than a standard user story. Do some stakeholder analysis to make sure all possible stakeholders are being considered. Then go ask those stakeholders to tell you stories related to the problem that must be solved. Trust me you will have richer conversations and uncover information that the traditional user story would not. My fundamental point is that we as BA’s are software professionals that have creative analytical skills that must not be suppressed by an over reliance on any one technique. So wash your hands, clean your keyboards and get enough sleep so you can avoid Agile fever. If the BA becomes infected then the project team is certainly doomed!

Are You a Great Business Analyst? Here’s How to Tell!

I’m sure many of you think that you are a really great business analyst. You read BA Times, attend BA conferences and write great requirements. But how can you tell if you truly are a great BA?

Recent articles by Kupe Kupersmith and Brad Egeland have outlined many characteristics of a highly performing BA. I’d like to take a slightly different approach and provide you with some questions that you can ask yourself to help determine if you truly are a great BA.

Do you actually know who all of your customers are?

I define “customers” as anyone who utilizes your work to get their job done. Notice I said “work” and not “requirements.” A great BA delivers much more than a set of written requirements. If all you do is write requirements you can stop reading. You are not a great BA. If you are still with me, then take a minute to write down whom you think your customers are for the projects you are currently working on. I’ll wait…

Related Article: The Great Facilitator

Great BAs understand that they serve a diverse group of customers. If you wrote down developers, testers, business SMEs, project manager, product owner/product manager, internal customers who use or support the system, external customers who use and pay for the system and executive management then you are on your way to being a great BA! To succeed, you must consider everyone who will be impacted by the solution your team is working on. Forgetting or neglecting a customer will lead to missed expectations and significantly increase the risk of creating a solution that is not well accepted. Since the pressure to develop the solution is always high, it’s easy to focus heavily on writing perfectly detailed requirements for the developers and testers to understand.

Great BAs remember that we deliver more than just written requirements to developers and testers. We need to explain the business problem to be solved and the vision of the solution. We also need to understand the scope of the project and help the team limit scope creep.

BAs serve various customers whom all have different priorities and agendas within a project. Great BAs can identify each of these customers and understand their priorities. Developers and testers are most concerned with the details of the requirements. They need to know exactly what to develop and what to test which is why they tend to wordsmith the requirements. Product managers/owners are concerned that the end product satisfies the primary business needs of the paying customer. Project managers want to know how many more stories we have left to develop. When will we be done? Internal customers are concerned with how easy the solution will be to support. Executive management doesn’t care about the nitty gritty details of the requirements. They care about overall costs, timelines and whether the project will bring in new revenue or not. Of course, your external customers who pay for the solution want their problem solved.

Great BAs realize that they must do more than just write clear requirements for developers and testers. They must consistently communicate the vision, scope and reason why we are completing the project to everyone who has an interest in the solution.

Do you know exactly what problem you are solving for your customers?

The best solutions explicitly solve a well-defined problem. Ask yourself if all of your customers can describe the problem your team is trying to solve. If the answer is no, then you need to communicate the problem clearly to everyone.

Great BAs clearly define the business problem being solved and communicate it early and often. Everyone needs to be reminded why we are creating the solution. Software development takes time. During that time, it is very easy to forget why we are creating the solution in the first place. This leads to shortcuts, scope creep, and missed expectations. A great BA ensures this never happens. Make it a habit to start your meetings with a quick recap or reminder of the problem we have been tasked to solve.

Do you have empathy for your customers?

Do you really understand the pain they are experiencing due to the problem your team must solve?

Paying customers or people at the ground level who use or support your product every day typically are not consistently involved in a software development project. If a BA truly has empathy for the customers who will be using the completed solution, then the probability of success will skyrocket!

Great BAs take the time to observe and experience the pain of the problem that needs to be solved. Empathy allows a BA to focus on the customer experience within the solution. Deadlines, resource constraints, and scope considerations can contribute to shortcuts that negatively impact the customer experience. Having empathy gives the customers a voice in the development process via the BA.

Do people enjoy coming to your meetings? Are your meetings always fun and productive?

That’s right; I used the words ”fun” and “meeting” in the same sentence!

Great BAs always have an agenda and goals for a meeting clearly communicated.

Great BAs always prepare for their meetings by preparing visuals or determining what facilitation technique is appropriate. You should be using innovative facilitation techniques such as collaborative games to increase the interactivity within your meetings. Do all of your meetings consist of having people sit around a conference table while multitasking on their laptops? If so then they are not fully engaged and participating in your meeting. Don’t be afraid to get people out of their chairs to join you at the whiteboard for a collaborative session.

The BA is uniquely positioned to interact with every customer associated with a new solution. It is this unique position that allows a truly great BA to ensure the project is a smashing success. Great BAs communicate frequently to each role on the team and are able to remind everyone why we are completing the project in the first place.

Congratulations to those of you who can claim they affirmatively answer these questions for every project! You truly are a great BA!

Business Analysts Should Focus on Desirability to Deliver Products Customers Value

Henry Ford once said “It is not the employer who pays the wages. Employers only handle the money. It is the customer who pays the wages.”

Unfortunately, the software development industry does not always remember this fact. High profile failures such as Windows 8 and the Blackberry 10 are constant reminders that you must listen to your customers and deliver a product that solves a problem.

Related Article: Shift Your Business Into Drive – Focus With a Balanced Scorecard

Windows 8 was a product that solved a problem that Microsoft invented. No one wanted a touchscreen laptop that had the same interface as a Windows phone. Does anyone actually have a Windows phone? I remember my first experience with Windows 8. I had to use an old laptop to look up how to shut down my brand new Windows 8 machine. It was a terribly frustrating experience.

The Blackberry 10 failed for similar reasons. Customers had difficulty turning the phone on and once they did they couldn’t figure out how to access their email or the internet. Windows and Blackberry simply refused to listen to their customers. They also created products that did not solve a problem.
To learn from these failures we must understand there are three main factors to consider for every software product:

  • Viability – how much will it cost to build and how much revenue can it provide?
  • Feasibility – is the product technically feasible to build?
  • Desirability – will our customers want the product and does it solve a problem for them?

In my experience, software development groups have a tendency to focus heavily on viability and feasibility while neglecting desirability. This is a recipe for guaranteed failure of your product. If your product isn’t desirable, then it is a disaster regardless of how well you managed to budget and timelines.

Software development teams are comprised of many different roles. Executive management will always be laser focused on the viability of the product. Executives are paid to be concerned with costs and revenue potential.

Project management and technical roles are always heavily interested in the feasibility of the product. If we don’t have the resources or technical skills to build the solution, then we can’t move forward.

The desirability of a product can easily fall off the radar of the executives, project managers, and technical leaders.

Ironically it was Bill Gates who said: “Your most unhappy customers are your greatest source of learning.” Microsoft listened to their unhappy Windows 8 customers by scrapping the design and giving Windows 10 away for free. The tremendous reputational and financial loss drove Microsoft to have a stronger focus on desirability for their Windows 10 product.

So who should be focusing on desirability? I think the business analyst is in a great position to constantly focus on the desirability of the product. A well-defined requirement elicitation process must be focused on defining the problem the business is trying to solve for our customers. If defining the problem is the first step in your requirement process, you are on the way to guaranteeing that the delivered product will provide value to your customers.

Throughout the development process, you will be able to monitor if the product is actually solving the problem. Additionally, your requirements should be directly related to solving the problem. It is the job of a business analyst to question the value of every proposed requirement that product owners want to add. If the requested feature or function is not directly related to solving the problem, then it should be taken out of scope. Focusing on the customer experience and the desirability of the product throughout the entire requirement elicitation process is our responsibility as business analysts. It’s very easy to concentrate on costs, revenue, and timeline issues while neglecting the customer experience. Never forget that our customers are much savvier computer users than they were in the past. They are familiar with using Amazon, Facebook, Netflix, Google and many other major products without requiring training or a user manual. They will expect the same from the products your team develops. If your project plan has a task for writing a user manual, it is officially time to panic!

Some organizations are lucky enough to have a mature product management group or dedicated UX/UI designers. These organizations are typically committed to having a focus on the desirability of their products. If you are lucky enough to be in an organization with strong product management and UX/UI design, then you should be tightly integrated with those folks. In fact, adding UX/UI skills is one of the best ways to improve your overall BA skills. The best business analysts utilize visualization and storytelling in their requirement process by providing low fidelity wireframes, sketches, or whiteboard drawings to stimulate conversation and uncover the true business needs. BAs should think, draw, and write – in that order – at all times.

Understanding the skills and tools of the UX/UI Designer helps a business analyst focus on the desirability of the product and ensure the customer has a positive experience using the solution. There are numerous online courses in UX/UI that are reasonably priced and provide a solid background in the profession. In my opinion Steve Krug’s book “Don’t Make Me Think” should be mandatory reading for all business analyst. Obtaining basic UX/UI knowledge is a simple and fun way to improve your skills and advance your career as a business analyst. Your customers and delivery teams will thank you for it as well!

Snake Oil or Miracle Cure? Is Agile all it’s Cracked up to be?

The Agile Manifesto was born out of frustration by a group of developers who were fed up with how software was being developed. Software development is a learning experience, and no one understands this better than those who are actually writing the code.

Waterfall was a misguided concept that seems reasonable on the surface but does not work in reality. Since software development is a learning process, it is impossible to think of every single requirement up front and have them signed in blood before starting development. We are all familiar with the limitations of Waterfall. However, how many of you have seriously debated or discussed the limitations with Agile?

It seems to me that Agile is too often viewed as the silver bullet cure to all of our delivery issues. Management is constantly under fire from the C-suite to improve the quality, timing, and costs associated with software development. In response, many organizations are diving into Agile with the belief it will cure all of their ills. Billions of dollars are being spent on Agile consultants and software solutions to manage requirements and project plans according to the Agile principles. All of this is being done with the best of intentions. With all of the certification programs, books, blogs, software and training programs devoted to Agile it seems to me that excessive process and red tape is taking over the concept of being “Agile”.
In multiple organizations, I have heard comments such as “We can’t change the questions we ask during standups – if we do we are not Agile!” A number of Agile practitioners have stated to me that if we change the frequency of retrospectives or other Agile ceremonies, then we are no longer “Agile.” This concerns me.

The goal of software development is not to be Agile. The goal is to deliver high-quality software that solves our customer’s business needs. If we achieve this goal, we will meet our revenue targets and grow the business. Being “Agile” is a worthless goal. Customers do not care if a company is Agile or not. They care about the quality of the product.
Do you think Apple would have more customers if they advertised that they were Agile?

This may be coming across as being harsh, but I want to emphasize that there is a risk of losing sight of the ultimate goal when implementing Agile. So if I haven’t ticked you off, and you are still reading you are probably thinking “Ok, then what do we do about it?” We get stuff done; that’s what we do. I am a proponent of my own software delivery methodology I call “Get Stuff Done” or GSD for short. That’s what we all want to do when we get to work; we want to get stuff done. Companies pay us for how well we Get Stuff Done. Many times our processes and red tape get in the way. Think about what you typically complain about at work. I’ll bet that many complaints are about the processes you are being forced to adhere to. Believe me, I’ve had many conversations with colleagues which debate the actual business value of some of the meetings and processes we are forced to follow.

So how do we go about work and just Get Stuff Done? Well, we’ve all heard about the Ice Bucket Challenge so here is a great first step to take.

I encourage you to take the GSD Challenge! For one sprint or iteration, I challenge you to turn off your electronic system for storing requirements and tracking progress. Just say no to using TFS, Jira, Blueprint, Project Server or whatever system you are using. Collocate your team in a conference room. Get yourself some multicolored sticky notes, index cards and Sharpie markers. Write the User Story titles and Acceptance Criteria on the index cards. Prioritize and size each story by writing the priority and story points directly to the card. Tack the cards up on a whiteboard for everyone to see. Have the team write their tasks for each story on the sticky notes. Use a different color for each group (development, test, project management, etc.). Paste the sticky notes next to the story. As each task is completed, move it across the board to indicate it is complete. If you learn something new, and a completed task now requires more work, simply move the sticky note back to in progress. Your team’s progress will be visible to all. Want to know the status of the project? Simply walk into the conference room and take a look. The GSD methodology relies heavily on two skills humans have perfected and used successfully for thousands of years. Bipedal Propulsion Technology (BPT) allows us to use our feet to get up and walk over to colleagues to communicate using Human Voice Technology (HVT). In my opinion, BPT combined with HVT is far superior to email as a communication tool. As a bonus, BPT is good for you! It gets the heart pumping and progress can be tracked using a FitBit or iWatch!


{module ad 300×100 Large mobile}


Collocated teams using GSD don’t have to worry about reserving a conference room for meetings. Calendar conflicts disappear, and email communication significantly decreases. Want to call a meeting using GSD? Simply use your Human Voice Technology to call out to the team “At 1:00 PM we will be having a Sprint Planning meeting!” It’s as simple as that. Don’t worry; with a bit of practice, you will get the hang of using your HVT more often. I understand that email and texting may be seriously eroding your HVT skills but I assure you it’s like riding a bike, it will come back to you. I suggest for maximum success with your GSD challenge you consider providing the following amenities within your collocated room:

  • A large conference table with network & power connections for the entire team
  • Additional monitors to allow for dual monitor connections
  • One or more whiteboards
  • A projector and projection screen

A little preparation will go a long way to ensuring your GSD challenge is a success. Once the team is collocated, and the user stories are tacked up on the board, you may follow your preferred Agile ceremonies. Standups may still occur at the same time each morning with the team gathered around the whiteboard to comment on their current tasks and what they plan to work on for the day. Standup is a great time for the team to update the board together by moving sticky notes around as needed. I suggest a Retrospective at the end of the GSD challenge to collect feedback from the team on their experience. This should be extremely interesting and provide insight into how the GSD Challenge differs both positively and negatively from your current process.

If you consider attempting the GSD Challenge be prepared for significant pushback from some team members. One of the most common initial complaints about colocation I have heard is “I don’t want to give up my office. I need to think and not be disturbed.” My response is that if your reward for developing software is an office, then you have not actually experienced a fun and rewarding environment. Your reward should be developing quality software in a fun environment that makes millions of dollars, not an office. The team should be allowed to develop their own norms concerning how they will work. For example, when someone truly cannot be disturbed they can wear a special hat or have a funny sign draped over their monitor. Have fun with the challenge and begin working and collaborating as a team. I bet you will be surprised at how little you actually miss your office and the electronic systems most of us rely on to track our progress.

The GSD Challenge is not meant to bash Agile or Scrum. It is to get you actually to think about how you are working and whether the principles you are following actually provide value and allow you to Get Stuff Done. The Agile and Scrum principles are guidelines. They are not laws which must never be violated. Listen to your team and adapt to what works for them as opposed to ensuring that someone can call your group Agile or not. Quality software and making money is the goal. We must never lose sight of that. Thanks for reading and I hope you consider going back to work and getting stuff done!

Cooking Up Business Analysis Success

In 1961, the great Julia Child revolutionized the cooking industry with her book “Mastering the Art of French Cooking”. This book cemented Julia as an expert in French cuisine and launched her career as a gourmet chef.

In 1963, Julia used her new found fame to revolutionize the television industry by creating a weekly half-hour cooking program. Her success paved the way for all of the cooking shows on television today.

So what does this brief history of Julia Child have to do with Business Analysis you may ask? Let me explain. Julia’s book was extremely successful because it provided very clear, simple instructions along with supporting photographs to illustrate the final product. This recipe for success launched Julia Child’s career from relative obscurity to international fame.

To succeed as a Business Analyst, you must strive to deliver consistently clear and unambiguous requirements that are understood by all audiences. The most successful business analysts will also create visuals to support the requirements they write. In this respect, BAs would be very wise to follow the formula that launched the success of Julia’s famous book.

I’ve developed a recipe that business analysts can follow that will ensure they will deliver high-quality requirements that are guaranteed to satisfy the business needs of their customers. The recipe is as follows:

  1. Define the problem 
  2. Define the Scope
  3. Create an Actor – Goal list
  4. Create supporting visuals
  5. Write detailed requirements 

Step 1 – Define the Problem

The very first step in the business analysis process is to define accurately the problem the business needs to solve. It is human nature to rush into a solution. However, a great BA would be wise to keep in mind the famous words of Albert Einstein, who once said “If I had one hour to save the world I would spend 55 minutes defining the problem and 5 minutes solving it.”

Related Article: Know Your Audience – Don’t Let Requirements Get Lost in Translation

In my experience, most people on the project team as well as management, are impatient and want to push forward with implementing a solution as quickly as possible. They fall in love with the solution, not the problem. This mentality significantly increases the risk that the project will deliver a solution that does not fully meet the customers’ expectations. BAs must lead teams to fall in love with the problem, not the solution. So how does a BA slow the team down and concentrate on defining the problem? We need to use a simple template for a well-defined problem statement. The template contains four simple sections.

Ideal – this section allows our customers to define the ideal solution or process. It forces the stakeholders and the project team to define what would be an ideal solution to their problem. The information discovered via this exercise will help determine the actual scope of the project as well as uncover the most important features the customers are expecting. Feel free to use collaborative games or other interesting elicitation techniques to make this a fun exercise for your team.

Reality – this section allows our customers to define the current reality of their situation. Understanding the reality of a customer’s current situation is helpful to understand the most significant pain points in the current process. Empathy mapping is a useful technique for this section since it allows you to understand how users feel and think about the current process.

Consequences – this section is used to define the actual consequences the business may suffer if the problem is not solved. It is critical to define the actual consequences that the current problem is causing. For example, ask your stakeholders if the current problem is causing productivity loss, revenue loss, or is putting the company at a competitive disadvantage. Understanding the actual consequences allows the business to prioritize the project. It also allows the project team to understand how the solution they create will actually impact the business.

Proposal – the proposal section is used to articulate options for solving the problem. Completing this section allows the delivery team the opportunity to provide an initial set of solution options which are feasible. Having your customers and the delivery team have a discussion on potential solution options is extremely important. It ensures both sides are in agreement on the path forward and helps to define further the scope of the project.

Step 2 – Define the Scope

Once the problem is defined via a well-defined Problem Statement the scope of the solution is much easier to lock down. The Scope Statement does not need to be a complicated document that takes a long time to complete. The information provided in the problem statement should allow you to come quickly to an agreement on what is in scope as well as what is out of scope.

Step 3 – Create an Actor – Goal List

Great business analysts are able to understand who is involved in the current process as well as who will be involved in using the new solution. This analysis results in the creation of a list of Actors associated with the current problem. For each Actor identified the business analyst should understand the goal they are trying to achieve. For example, let’s consider a typical web-based application that allows a customer to order products. A realistic Actor – Goal list for this solution would be:

Customer – Search for Product

Customer – View a Specific Item

Customer – Add Item to Basket

Customer – Place Order System – Verify Payment Information

Obviously, this is not a complete list, but you should get the idea. If you write each goal in Verb – Noun format you may simply associate each Actor – Goal combination with a single Use Case or User Story. This exercise allows you to organize the requirements in a way that ensures the most important functions of the stakeholders are accounted for.

Step 4 – Create Supporting Visuals

Using visualization is absolutely critical to convey requirements. Visuals allow for the proper discussion to occur in order to elicit the detailed requirements from your stakeholders. A picture truly is worth a thousand words. Visuals may include mock wireframes, prototypes, process flows, and data flow diagrams. Visually mocking up the solution allows the BA to obtain feedback quickly and discuss the details of the proposed solution prior to developing it. Taking the time to create visuals and discuss them allows the detailed requirements to fall simply out of the discussion. You will be amazed at how easily the requirements become clear when you are discussing a visual with your stakeholders.

Step 5 – Write Detailed Requirements

Once the problem has been well-defined and agreed upon, the scope has been solidified, the actors and their goals have been considered, and the visuals have been discussed, you are ready to put together the detailed requirements. Each requirement should be associated to a single Use Case or User Story, which is directly associated to a single Actor – Goal. This ensures that each requirement is directly involved in satisfying a goal of your customer and will be adding value to the solution. Requirements should be written in Subject-Verb-Object (SVO) format and be clear and unambiguous. The key to clarity in the English language is the relationship between the Subject, Verb, and Object. If a common sentence clearly defines WHO the Subject is, WHAT they will be doing and to whom they are doing it, then the reader should have no problem understanding it.

Following this recipe for requirements elicitation may not launch you into international fame and a lucrative television show. However, it is likely to set you on a path for success in your business analysis career by establishing agreement and trust within the team.