Skip to main content

Author: Bola Adesope, B.Sc, MCITP, CCNA, MCTS, PMP, ITIL, PRINCE2, BAP, SSYB, SFC, CSSBB, CBAP, MBA

Efficacy of Team Working Agreement

Written by Bola Adesope, B.Sc, MCITP, CCNA, MCTS, PMP, ITIL, PRINCE2, BAP, SSYB, SFC, CSSBB, CBAP, MBA on . Posted in Articles.

More often than not, we take little things for granted. Although Agile/Scrum is simple (but you know simple doesn’t necessarily mean easy), there are a few (little) things that must be in place to ensure success, specifically achieve or create a high-performing team.

One of such little, albeit often neglected, things for high team performance and good working environment is a TEAM AGREEMENT. Almost all the Scrum Masters (and even Managers) with high performing and happy teams use Team Agreements. If you are a Lead Business Analyst or Project Manager with a happy and high performing team and you haven’t used a Team Agreement, then you must be one damn lucky fella. But how do I explain Team Agreement? Okay, let me use a TV Series. I am really not much of a movie or TV person. As a matter of fact, I can remember a couple of times, falling asleep more than twice in a cinema, in the middle of a movie. I have, however, managed to see a couple of movies and TV series, and some of the ones I have seen usually have very deep meanings with relatable and applicable concepts. One of such is BIG BANG THEORY and how a concept (ROOMMATE AGREEMENT) in the TV show helps improve team health and productivity, one of the most important things in working as a Project Manager or Business Analyst. To provide a bit of context, and also to be able to relate TEAM AGREEMENT with teams’ effectiveness, I will attempt to narrate this concept in the TV series, and marry that with the theme of this article.
In the TV Series BIG BANG THEORY, there was a character named Sheldon Cooper who had a friend and roommate named Leonard Hofstadter. In other to ensure the two friends, turned roommates, understand what is expected of each person, know what rights they both have, set boundaries, reduces friction and misunderstanding, Sheldon Cooper drafted a bunch of stuff and called it “ROOMMATE AGREEMENT”, and handed it over to Leonard Hofstadter to sign. Upon signing, the two friends and roommates were able to manage expectations and lived “happily”. While the period was ongoing, Sheldon reviewed and updated the agreements severally, albeit to favor him the more. But the objective of the agreement still remains to ensure they both live together happily.

Now the same concept applies with (Scrum) teams, except that the agreement is not drawn or written by just one person. In the remaining sections of this article, I am going to explain TEAM AGREEMENT using the WHAT-WHY-HOW theory.

So, WHAT is Team Agreement?

Usually, when starting out with a team, you don’t expect them to start operating in the PERFORMING stage of Bruce Tuckman’s Stage of Team Development model. Why is this? Well, most of the people on the team have different backgrounds, personalities, interests, and configuration. So in order to establish a modus-operandi that will guide the way the team operates, there should be a document that defines responsibilities, expectations for how the team will function together to enhance their self-organization.

Something that creates an awareness of both positive and negative behaviors that can impact the team. That thing is called THE TEAM WORKING AGREEMENT. For the sake of definition, a Team Working Agreement an informal agreement between the agile/scrum team to perform activities or to abide by certain guidelines or set of acceptable behaviors.

HOW to develop a Team Working Agreement

Unlike the way it was in BIG BANG THEORY, The Team Agreement is jointly developed by the team.

The process of defining the Team’s working agreement is straightforward. The Business Analyst facilitates a session with the Project Manager and the team, where they generate a number of team disciplines together. A working agreement should be recalled easily, so they will then vote on the top five to ten disciplines. Once the Team has agreed upon a set of disciplines, they should be posted in their designated area and/or stored in a virtual folder that is accessible to all members.

Specifically, let me run you through how I worked with a team to come up with a Team Agreement. The first meeting I had with this new team, I gathered the team together in a room, explained the concept of team agreement (some of them understood the concept from GROUND RULES), but I was careful not to use the word GROUND RULES, because typically, Ground Rules are set by an individual and imposed on the team. This was a pretty new team. New to one another, new to the product we were building, new to the project. I also helped structure the session such that everybody had something to write.

At the end of the silent writing section, each team member had written at least 4 points on post-it notes that would form the team agreement. We then collected all the points written by the team, put them on a BACKLOG, and started discussing them one after the other. We had some that the team didn’t collectively agree on, while some that everybody agreed to. At the end of the session, we came up with five points that would become the TEAM AGREEMENT. I will try to explain them in the following sections.

Thankfully, we had someone who could really draw in the group. So, we used a large piece of cardboard to write the TEAM AGREEMENT and pasted it on the walls of the Team Room and the Team Lab (where the team holds sessions, reviews etc.)

At the team became mature, we gathered again to review and refine the team agreement collectively. So, what did we come up with as the Team Agreement? I was getting into that. Check them below.

Advertisement

BE NICE: Everybody on the team will be nice to one another, will help one another, will be kind and considerate to one another. Everyone will respect one another, no one will shout another down. Generally, everybody on the team will be nice to everybody on the team

BE PROMPT; Projects run on few meetings and schedules. For the team to really be high-performing and productive, we need to start our ceremonies on time, finish them on time, and that wouldn’t be possible if team members are not prompt. Daily Stand Up starts at 10:00 AM on the DOT, and hence, everyone must be around to start by 10 am.

BE PROACTIVE: This took some clarification for the team to fully agree. It means that everyone in the team should be more responsive and proactive about issues and everything that concerns the product, the task, the approach, the stakeholder etc.

BE AVAILABLE: You know you can be in a meeting and not be available mentally. You can be in a meeting and be engaged in something else like using your phone or computer. So, the team agreed that to be more productive, everyone must be available physically, mentally and psychologically. No one should engage in another activity apart from the activity the team is currently on.

BE BOLD: Scrum runs on empiricism, which loosely means experimenting. And in other to make any meaningful discovery and improve the way we work and the products we deliver as a team, we need to be bold and fearless. We need to be able to explore and experiment with new methods or approach

Why must you have a Team Agreement?

The saying goes “Where there is no Law, There is no SIN”. Recall, the Team Agreement is not a LAW or Set of Rules, just an understanding of the acceptable behaviors within an association or a team. Below are the few reasons why every team must have a team Agreement

  1. Team Agreements help eliminate (if at all possible) frictions among teammates. Ok, scratch that. Team Agreements help reduce friction among teammates. The agreement gives all members of the team a template for what is expected during their day-to-day work.
  2. Team Agreements, when well done, help even the most controversial of teams come together to produce great results.
  3. Team Agreements help to onboard new team members easily and smoothly…..

So, in summary, if you have a team that is not productive or not healthy, you may want to consider TEAM AGREEMENT.

Few closing tips to take away from this article:

  1. Never start a team on a project, assignment, task without a TEAM AGREEMENT. If you already started one, NEVER continue without a TEAM AGREEMENT. Stop right now and develop a TEAM AGREEMENT
  2. Involve everybody on the team in the development of the TEAM AGREEMENT
  3. Ensure everybody on the team agrees to the TEAM AGREEMENT, and if required, have them all sign it.
  4. Do not make the TEAM AGREEMENT too long or one-sided
  5. Make the TEAM AGREEMENT visible. Paste it on every wall the Team uses.
  6. Continually review and update the TEAM AGREEMENT.

Wish you a productive and high-performing TEAM.

Top 5 Skills for Business Analysts

Written by Bola Adesope, B.Sc, MCITP, CCNA, MCTS, PMP, ITIL, PRINCE2, BAP, SSYB, SFC, CSSBB, CBAP, MBA on . Posted in Articles. 1 Comment on Top 5 Skills for Business Analysts

One of the most frequently asked questions I get is “What are the top skills required in Business Analysis”.

This particular question comes from different quarters ranging from students and participants from my Business Analysis/CBAP Certification classes, folks trying to get into the business analysis function and folks who had read my previous article “Top 5 techniques in Business Analysis’. By the way, the article won “Best Article of the Month” on Business Analysis Times (betimes.com). You should check it out. So, back to the question. I know these guys have access to the Underlying Competencies section from the BABOK, and as such, I was sure directing them to pages 187-215 of the BABOK wouldn’t directly satisfy their curiosity. So, what did I do? How did I arrive at my Top 5 Skills? Please read along.

Methodology

I could have provided responses to this question using my experience working in Business Analysis function, interacting directly with other Business Analysts or just shopping for top skills across several platforms. However, I wanted the response to be unbiased, so I decided to conduct a research. I developed a survey using SurveyMonkey. The survey was broken down into two sections. The first section gets to know the respondents, with questions about the background and function of the respondents, the geographical locations, their industries, the years of experience they have in Business Analysis and if they have any Business Analysis Certification (I decided to include this to check if the responses would be tilted towards recommended skills in BABOK etc). In the second section, I went straight into the core of the research by asking them to list 8 skills they have found useful working as a Business Analyst, then a follow-up question asking them to choose five out of the 8 skills they had listed in the previous

The Respondents

After creating the survey, I targeted people with Business Analysis responsibilities across North America, Africa, Europe, and Asia. I sent over 150 people private messages on LinkedIn from these continents. I also posted the link to the survey on my LinkedIn page.

I received about 107 responses from North America (Canada and USA), Asia (India), Europe (UK), and Africa(Nigeria, South Africa, and Ghana). These respondents all perform business analysis function in their current roles. The respondents have an average of 5 years working in Business Analysis, about 45% of them have certifications from IIBA, PMI, and BCS and they come from different industries ranging from BFSI, Consulting, IT, Retail and Manufacturing (interesting).

So, below are the responses I got and the five skills that featured in almost all their responses. Please note that these skills are arranged in absolutely no particular order.

Advertisement

1. COMMUNICATION SKILLS

Communication Skill was present in over 95% of the responses I got and this is perfectly understandable.

But before I go into explaining the justification, let me unpack Communication. Communication covers speaking, listening, writing, presenting and documenting etc. As a Business Analyst, the bulk of your work is in Information. A Business Analyst is either eliciting information, analyzing information, disseminating information or processing information, and this is why Communication Skills is totally one of the top skills needed for one to function and succeed in Business Analysis. The type and kind of questions you ask as a Business Analyst, the way you ask the questions and the way you process the questions you are asked would define the next steps in your business analysis assignment. The things you hear, the way you hear and interpret them, all form the basis for your work. When asked, over 70% of Business Analysts would answer that bulk of their work include eliciting, gathering, processing and presenting requirements and information from and to stakeholders. How more important can communication skills be in business analysis.

2. CREATIVE, ANALYTICAL & PROBLEM-SOLVING SKILLS

Quite interestingly, half of the respondents merged these somewhat distinct skills together, while the other half separated them. However, for the purpose of this article, I have decided to merge them. Again, I totally and completely agree with this skills. According to IIBA, Business Analysis is the practice of enabling change in an enterprise by defining needs and recommending solutions that deliver values to stakeholders. From the definition, a need can either be a problem or an opportunity, so for a Business Analyst to be able to define the problem and recommend a solution to the problem, the BA should be creative, should be able to analyze so many actors and factors at play within the context of the problem and creatively solve the problem by recommending solutions. In-depth analysis facilitates a thorough understanding of the context of the problem. Creativity would be at play for the best solution.

3. TECHNICAL (Technology) Skills

I am not very sure if you could call this a skill, however, the respondents picked this as one of the top five skills they have used consistently in Business Analysis. Given that lots of solutions being implemented by organizations across industries and continents leverage technology, so it is safe to agree that for a business analyst to succeed, he/she needs to understand trends in the technology space, be highly skilled in the technology that the solution would run on and be able to speak the technical language that the implementation team would understand. Technical skills such as database, architecture, frameworks, and systems come to mind when thinking about the technical skills for Business Analysts. Also, remember that a business analyst acts as an intermediary between technical and business people, one can’t but hone some technical skills.

4. INTERPERSONAL SKILL

Skills such as influencing, emotional intelligence, Teamwork, leadership etc. were what my respondents came up with when I sent a follow-up question to a subset of the respondents to provide further clarifications on what Interpersonal skills encompass. And this is really a valid point. The Business Analysts depend on stakeholders and their engagement to make any meaningful outcome of their assignment, and given the natural nature of humans, a Business Analyst would need lots of interpersonal skills to be successful with their stakeholders.

5. MODELLING/DESIGN SKILLS

A lot of the deliverables the business analysts create are models of the future state. The respondents believed that they have used lots of skills that boil down to modeling and/or designs in several assignments.

So, before completing the report of this study, I decided to pilot the result with a group of 10 students a few months ago who were in my CBAP/Business Analysis Class. I presented the above 5 skills, then mixed with randomly selected 5 other skills, and asked the participants in the training class to write down, from the list of 10 skills, their top 5. The result? Not a major deviation from the result of my research. Four out of the 5 skills above featured randomly among at least 8 of the students in the class…

So, based on the research and responses I received, these are the top 5 skills used by Business Analysts across industries and continents. Are you a Business Analyst? Have you been doing business analysis for a while? Do you agree with the above 5 top skills? What are the other skills you have found highly useful in performing business analysis functions? Kindly drop your thoughts in the comment section.

Top 5 Challenges in Requirement Management for Business Analysis & Project Management

Written by Bola Adesope, B.Sc, MCITP, CCNA, MCTS, PMP, ITIL, PRINCE2, BAP, SSYB, SFC, CSSBB, CBAP, MBA on . Posted in Articles. 1 Comment on Top 5 Challenges in Requirement Management for Business Analysis & Project Management

Whether you are doing Project Management or Business Analysis, the foundation of Success or Failure of the exercise is REQUIREMENT.

Get it right, and you are on your way to achieving success in the Business Analysis or Project Management assignment. I sampled results of research studies conducted by several organizations and institutions between 2010 and 2016 on reasons for project failure, and one common factor reported by over 95% of these studies is inadequate/poor requirements definition and management. Also, after being involved in several projects and initiatives both in Project Management and Business Analysis capacities across many industries, I have realized the importance of Requirement Management.

I have outlined the top 5 challenges faced in Requirement Management. This list is as a result of personal experience, discussions with Business Analysis and Project Management practitioners and a mini-survey conducted across a community of practitioners.

Note: Requirement Management, in this context, covers the whole spectrum ranging from Elicitation, Analysis, Verification, Documentation, and Validation.

  1. Conflicting Requirements: No matter the scope and context of your project or business analysis exercise, you are certain to have more than 3 stakeholders or stakeholder groups whose requirements and needs must be managed (starting right from elicitation). And because these stakeholders or stakeholder groups have different needs and represent different interests within the business, there are always issues aligning their requirements. From my experience, this is the topmost challenge I have faced in managing requirements. I recall having this major challenge on one of the projects I managed for a top stockbroking firm in Africa. The project involved deploying a self-service, interactive and transactional trading portal for the firm’s clients where the clients can trade on stocks and shares directly from the portal without recourse to the company. One of the major requirements on the project was “User Idle Timeout (a maximum time for the user to stay logged in and not perform any activity on the portal). The business wanted to have the clients perpetually logged on (set at infinity), except if they decide to log out solely because the clients need to do some research before taking a position on a particular stock, while the IT Security Executive, another stakeholder on the project, recommended an idle timeout of 2 minutes. This conflicting requirement took us about 4 additional days of back and forth before agreeing to a 5-minute idle timeout. This happens on almost every project I have handled until I started using Facilitated Workshop technique for Requirement Elicitation. 
  2. Customers don’t know what they want: Let’s be factual, more often than not, customers don’t know exactly what they want. This is a huge challenge for the Business Analyst and Project Manager during Requirement Gathering. How do you elicit, analyse or document what is not knows? This challenge often leads to the technique called IKIWISI (I’ll know It When I See It). But a downside of IKIWISI is that it can easily lead to Scope Creep, which is an ingredient to Project Failure in itself.
  3. Unavailability of Stakeholders: Irrespective of the technique you have chosen to use in your requirement elicitation, be it interview, observation/shadowing, focus group, requirement workshop, prototyping, name it. You need to meet with Stakeholders. These are the guys with needs and expectations for the change or project you are working on, but scheduling a meeting or session with these stakeholders has always been a challenge. They are just not available, either due to their busy schedule or they are not interested in the CHANGE or project (hopefully, this is not the case). I had a key stakeholder, a representative from the user community on one project I worked on in the past who took over 2 weeks to track and get him to sit with me for 30 minutes to elicit their requirements. Unfortunately, no one could take his place. Imagine 2 weeks added to a 3 months change project.
    4. Advertisement
  4. Changing Priorities: For a lack of better word, I have used the word “Changing Priorities”, but more bluntly said, it would be “Customers keep changing their minds”. This is a VERY common, rampant, and tiring challenge I and couple of other practitioners have experienced on BA and PM engagements. I can authoritatively say I have experienced this challenge in 7 out of every 10 projects I worked on in the past. The customer comes with one set of requirements, the next hour, they are changing the requirements, irrespective of whether the Business Requirement Document has been signed-off. A typical example of this challenge was while working on an initiative for a stock broking firm to develop a self-service trading portal for their investors, same project I referenced above. During requirement elicitation, the business owner was very emphatic about online chat integration as a Must-Have requirement/feature. During implementation, the stakeholder called a meeting and decided to expunge that requirement, and replace with google map integration in the contact us page. The next review process, she was thinking and having another idea, hence a completely new requirement, different from what was elicited earlier. I find this challenge quite common when doing Requirement Management.
  5. Unsupportive Stakeholders: Well, maybe this is not as rampant on projects as the other four, but I have faced lots of challenges on requirement management when the stakeholders do not buy into the change. This could be as a result of a segregation between senior management and the user community or sheer lack of enthusiasm towards the change being implemented. A while ago, I was working on an automation initiative as part of a firm’s digital transformation program, and part of the process included understanding the current (manual) process (AS-IS), identifying bottlenecks and improvements, to be able to develop the future (TO BE) process. Unfortunately, the key stakeholders felt this automation would render them redundant and threaten their jobs. So, we faced a lot of restriction and challenges while meeting with them to elicit requirements of the current process or identify improvement opportunities.

Whilst I believe some of the highlighted challenges can be addressed by implementing the Agile method, there are still some residual challenges.

So, I would like to end by asking you to confirm if you have experienced any of those challenges identified above and provide comments on those other challenges you have encountered and possible solutions.

Top 5 Techniques in Business Analysis

Written by Bola Adesope, B.Sc, MCITP, CCNA, MCTS, PMP, ITIL, PRINCE2, BAP, SSYB, SFC, CSSBB, CBAP, MBA on . Posted in Articles.

Having been involved in several Business Analysis engagements and assignments, I have discovered top 5 techniques that I find most useful for Business Analysis, and they are highlighted below.

One Caveat: I am more tilted towards Strategic Business Analysis.

1. SWOT Analysis

The SWOT Analysis, which stands for Strength, Weakness, Opportunities, and Threat is a very simple, yet powerful technique used by Business Analysts to analyze both internal and external organizations under analysis.

When using SWOT Analysis, the Business Analyst conducts, and thorough analysis of the internal (Strength and Weakness) and external (Threats and Opportunities) actors and factors at play in the space the organization operates in.

In using SWOT Analysis, the Business Analysis answers the following questions under each of the quadrants

  • Strengths: characteristics of the business or project that give it an advantage over others
  • Weaknesses: characteristics of the business that place the business or project at a disadvantage in relation to competitors or other projects
  • Opportunities: elements in the environment that the business or project could exploit to its advantage
  • Threats: elements in the environment that could cause trouble for the business or project

Use: The SWOT Analysis is useful in understanding the position of the organization and helps to recommend the capabilities the organization needs to build or the feasibility of any initiative based on the result of the analysis.

2. MOST ANALYSIS

The MOST Analysis is a very simple and extremely powerful framework tool used by Business Analysts for analyzing and planning the details of what an organization does and initiatives the organization should be looking at doing and helps maintain strategic alignment. It can also be used to give the business or organization a fresh sense of purpose and capability.

The M.O.S.T. Analysis is a highly-structured method for providing targets to team members at every level of an organization. Working from the top down, it ensures that you retain focus on the goals which matter most to your organization

The MOST Analysis comprises of four elements:

Mission: Mission is the top-level, overall reason for being in business and defines outcomes the organization wants to accomplish. The more specific the business is when defining the mission, then the more success the business will have later on trying to define the remaining points within the tool.

Objective: The objectives are one step down from the mission. Think of these as a collection of individual goals that will add up to reaching the overall mission. Just like with the mission, objectives should be specific enough to guide decision making and planning for the future. With the mission in place, it should be relatively easy to develop a list of a few objectives. Objectives should be Specific, Measurable, Achievable, Realistic, and Timely (S.M.A.R.T.). Otherwise, goal-creep will set in, and objectives will become fuzzy and difficult to implement.

Strategy: These are the things the organization or business will do to reach the objectives. What actions should be taken to accomplish the objectives, and in turn, the mission? Strategies offer a way to quickly review and group the tactics implemented on the ground floor, so they make sense as methods to achieve your objectives

Tactics: Tactics are the methods you will use to carry out your strategies. They should be simple and relatively discrete processes that can easily be understood and carried out even by people who do not have a high-level overview of the M.O.S.T. analysis.

Use: The MOST Analysis is used to ensure the BA recommends the solutions that the organization needs to meet its objectives and mission. It is also used for alignment.

3. PESTLE ANALYSIS

The awareness of the influence the environment has on the organization the Business Analyst is working with is a very important factor in any Business Analysis engagement. The PESTLE Analysis, which is also called PEST Analysis is a tool used to identify and analyze the key drivers of change in the strategic or business environment. The analysis looks at the drivers and factors in the following and how the happening in those areas influence the decisions and the type of recommendation the Business Analysts gives the organization

Political: What are the current happenings and factors in the political landscape of the environment the business operates and how can it affect or change our business.

Economic: What are the important economic factors such as inflation or meltdown is happening, has happened, or will happen in our business environment and what do they mean to our business

Social (or Socio-cultural): What cultural aspects are most important that we need to pay attention to

Technological: What are the trends and innovation in the technology space. What is the direction technology is going, and what impact will they have in our organization or business?

Legal: What are the regulations or legislations that directly impact our industry or environment and how do they affect our business

Environmental: What are the environmental considerations we need to make in our business and organization.

Use: The PESTLE Analysis is used to understand the factors and drivers within the environment the organization operates and how those factors will influence the narratives of the organization

4. BRAINSTORMING

Brainstorming in a group creativity technique that is used extensively by Business Analysts to generate ideas, identify root causes of problems, and solve complex business problems. Most of the other techniques such as Mind Mapping, Root Cause Analysis, SWOT, and PESTLE Analysis use Brainstorming and an underlying technique.

I particularly find this technique very useful in generating diverse ideas.

Use: This is used in problem-solving, fact finding and idea generation

5. MINDMAPPING

You want to be sure you have all the areas within the analysis covered, you want to certainly confirm you have considered the different and diverse components and elements under analysis, you do not want to miss anything out? Then you would need the MINDMAP technique.

The Business Analysis function has over the years been greatly helped by this special and often unrecognized technique, but I find it extremely helpful during my business analysis engagement

What are the techniques you find useful in Business Analysis engagement? Share in the comment sections