Tag: Team

The Fruits of a Problem May Be the Problem

Written by John Vaught on February 26, 2019. Posted in Articles.

Old agricultural metaphors are fascinating –

sometimes we are using them even though the closest we ever get to harvesting a crop is squeezing a tomato in the store; the thought of even getting dirt under your nails may send shivers down your spine. One of the most common is the idea of bearing fruit.

The concept is easy to understand because there are only a rare few of us these days who can look at a fruit tree in the off season and have any idea of what it is, but I’ve plunked down some money and walked into a grove to pick fruit that magically appears in the fall (and eaten a few while filling the bucket – don’t judge, I know you’ve eaten grapes in a store). When I’m yanking that red ball of sweetness off the branch it’s easy to see that it’s an apple tree. I can tell what kind of tree it is by the fruit it bears.
In our places of work we sometimes come across fruit that has spoiled and rotted. If you are in IT or a process-oriented team you are used to the idea of root cause analysis – when something stops working it is usually the results, or fruit, of a deeper issue that needs to be discovered and fixed so that it doesn’t happen again. It’s not often easy, but if you don’t do the hard work of determining the underlying causes then it’s bound to happen again and again, causing more stress and pain in the long run. Sometimes a whole team may need to be utilized to dig in and figure it out.

While root cause analysis is a incredibly useful thing to do when something stinks with technology or processes, it is highly tempting to do the same thing with people.

Don’t.

With processes and systems, you can take them apart and look at the pieces individually, often no matter how complex they are. That’s not true for humans beings. We are far, far too complex in ways that the best of us do not understand, with a hint of wackiness in everyone. Looking for a root cause is rarely worth the effort, and can even lead you down a path that takes you away from looking at them as human and instead as something to figure out.

From Hal Runkel, a licensed Marriage & Family Therapist:
We’ve all been schooled to pursue the deep roots of a problem–searching for the underlying cause. In reality, it is often the fruits of a problem that spur its continuation. These are the secondary, unspoken gains we receive as a result of the problem’s presence.

Every parent out there has done this – it is really hard not to. Your kid just did something inexplicable such as tell you a blatant lie that everyone in the room knows is a lie. Your first instinct, after wondering what you did to deserve this kind of treatment (and you probably do deserve it since you did it to your parents), is to say something like the following: “Why did you lie?” As if they are going to do a deep, serious introspection and come up with an answer that would astound Freud. And when they come up with something lame you send them to their room to go figure it out. You head out the door to go to work, where you lie to your coworkers at least 10 times. University of Massachusetts psychologist Robert Feldman says it’s hard to have a conversation without someone lying, often without even realizing it.

Why do we think a seven-year old is going to know why they did anything? Frankly, we don’t really know why we do most of what we do; being a grown-up means we are just better at justifying it afterwards.

This is true not only for our kids, our partners, our in-laws (definitely don’t know what they’re thinking), and our co-workers. You are not equipped to determine motivation. What you can do is identify the fruits.

Sometimes when we are struggling with a problem it is because we may be unknowingly enjoying the benefits, or the fruit, of the behaviors that are putting us in that situation. The same is true of coworkers that are spoiling the bunch.

Rather than looking at the person, or yourself, as “rotten” maybe we should be assessing the environment or culture to see if there is something that rewards the behaviors we want to avoid.

For example, maybe there is someone on your team that is constantly late for meetings. Rather than labeling that person as “spoiled” and trying to understand their motivation, deal with the fruits of the problem. Address the person to see if there is some environmental or scheduling issue. Is there some cost for the person if they have to arrive on time to the meetings in other areas, such as not getting other work done? Help them understand the cost of being late to meetings for the rest of the team.

Ask yourself: What are all the results of my current problem, even ones seemingly unrelated. Do I unknowingly want those results? If not me, is there someone who does? What are all the possible results if I solve my problem? What will be missed?

Why Don’t They Get It? Understanding Learning Preferences for Better Business Analysis

Written by Janelle Edge on February 8, 2019. Posted in Articles.

I am not a visual person.

This came to light early in my career when a stakeholder came to me with a beautiful diagram full of lines and colors and a few keywords. He handed me the picture and very proudly stated, “Here. This is what we want to do”, and then walked off. I stared at it for the longest time. There may have been tears. I spent hours translating that beautiful nightmare into written language trying to figure out what I was being told. My stakeholder was attempting to communicate with me the most efficient way he knew how, and yet I had a huge disconnect. There was no shared understanding. Eventually, I did figure it out, but it was a very frustrating process.

I never saw any value in images, so until this defining moment, I saw no value in including them in requirements. A picture may be worth a thousand words, but my question is, which thousand and what do you mean by them? For me, only words could answer that. Visuals just took up space and duplicated information that was already there.

Now I have much more empathy for those who rely on those symbolic representations. That one interaction started me on my search to incorporate all learning preferences into my business analysis processes. There was a lot of information on adapting teaching styles for each type of learner, but I could not find good examples of utilizing different techniques for different learning styles outside the classroom. Most people can absorb basic information through any method, but complicated material is easier to understand and retain when communicated in their preferred method(s).

Learning preferences can be categorized in several ways. However, for purposes of this discussion I will use:

Visual – Preference toward pictures, images, and spatial understanding
Auditory – Preference toward sound and music
Linguistic – Preference toward spoken and written language
Kinesthetic – Preference toward body, hands, and sense of touch

Most people have a combination of the above learning preferences. However, Business Analysts are a communication bridge for everyone on a project, so we don’t get to have a weaker area. We must learn to work within all learning preferences, regardless of our own personal style.

My first step was to take a free online self-assessment. My results were not all that surprising – Read/Write 13, Aural 8, Kinesthetic 5, Visual 1. That’s right. A one. No wonder mind maps trigger hyperventilation and all sorts of other stress responses! Unfortunately for me, visual is one of the most common learning styles. I needed to learn to speak that language quickly. I wasn’t going to become fluent overnight, but I at least needed to become proficient.

So, what’s a BA to do?

I now knew how crucial it was to start using visual aids. I created a guide to help me remember how to use several common diagramming tools. I started by using illustrations that were similar to my preferred linguistic style such as process flows and matrices, then expanded from there. I often refer to my catalog of visual aids for ideas on how to bring that aspect into my requirements as well as a reminder before joining large group meetings.

I’ve seen a lot of success since I consciously started considering diagrams and other images in requirements. I’m getting more feedback. I take that to mean more people are reading and approving the content rather than just approving to stop my nagging. I’m still not able to start with creating a visual rather than text, but maybe it is like a foreign language and I can get there with enough practice. I take consolation that I’m helping everyone get to that mutual understanding.

What are your learning style preferences? Are there any that you would like to improve?

Look for ideas in the lists below if you are struggling with a specific audience. Turn to your peers as well. If you notice someone skillfully incorporates a learning style, ask them for some ideas to expand your communication strategy or ask them to be a test audience when you try out a new technique. Once we’re aware of our own learning style preferences as well as those of our stakeholders, it becomes much easier to spot potential misunderstandings earlier or prevent them entirely – saving time, minimizing frustration, avoiding rework and helping us achieve a successful project.

Visual (learn through seeing)

Visual learners prefer:

Drawing pictures on the whiteboard
Organizing concepts into separate areas on the whiteboard to create “piles” that can be worked through
Color coding
Including diagrams of overall concepts in requirements documentation

How you can get there:

Allow yourself time to translate into a picture.
Arrive early for key meetings to create models on whiteboards or allow pre-meeting prep time to create images that can be shared virtually.
Write a legend for color coding and reference it as you write.
Review documentation to find areas that can be displayed pictorially.

Auditory (learn through hearing)

Ever had someone ask to discuss an email or an invite, even with a clear agenda? I had a Project Manager that was an egregious offender. Every email, instant message and meeting invite sent was followed by a call. Everything was discussed at length until she understood. She is a purely auditory learner.

Auditory learners prefer:

Earworms
Minimizing silence during meetings
Repeating things out loud
Meeting in person rather than discuss through email

How you can get there:

Keep and follow a meeting agenda so that you always know what to discuss next. (Always a good idea regardless of who is in the meeting.)
Incorporate music where appropriate, such as at the beginning of a workshop while people are finding their seats.
Ask the auditory learning participant to summarize the meeting or concept just discussed.
When creating an email, offer to be available for a brief call or meeting to discuss or clarify.

Linguistic (learn through language)

Linguistic learners prefer:

Clear & precise written documentation
Exactly the right word to express a concept
Lists

How you can get there:

Provide summary talking points or step by step instructions with visual aids and demonstrations presented in meetings.
Use illustrations with a verbal component such as grids and process flows.
Keep a glossary.
Use unfamiliar terms regularly to reinforce their significance.
Review pictorial documentation to verify all requirements in the image are also put in writing.

Kinesthetic (learning through doing)

User Acceptance Testing is a wonderful time to leverage the kinesthetic learning style.

Kinesthetic learners prefer:

Demonstrations
New skill practice
Content in bite-sized chunks
Frequent breaks and activities that provide opportunities for movement during longer meetings

How you can get there:

Add activities such as role-playing to meetings.
Use a prop that can be moved around (sticky notes, ball, modeling clay, etc.).
Incorporate real-life stories and examples
Try collaborative games.

Imagine a world without BAs

Written by Katie Cubitt on February 6, 2019. Posted in Articles. 1 Comment on Imagine a world without BAs

Imagine a client is looking for a bespoke software solution in a world without business analysts (BAs).

The developers believe they understand what the clients or business users are looking for, while the users have their own expectations of how the project will ultimately turn out.

“This is not really a winning recipe for successful delivery” states Patricia Draper, an executive at BBD, a leading software development company.

The scenario above isn’t impossible to imagine, and it happens more often than you think. Why? Because BAs play the role of translator in the software development life cycle (SDLC), enabling the effective conversion of the business user’s needs into technical specifications that the developers use to build the most appropriate solution. Draper explains that without this ‘meat in the sandwich’, the business logic isn’t clearly defined. The more precise the requirements are, the less likely reworking is needed on the development side. Ultimately, knowing the business as well as the client means a smoother process for the whole team.

The other important function BAs fulfil is project management or stepping into the role of scrum master. As logical, detail-orientated problem solvers, BAs not only outline the initial specifications, but co-ordinate all the moving parts and teams throughout the SDLC, thereby removing most impediments. This process involves numerous tools such as JIRA and Confluence, Microsoft Visio and Excel, Zoom, Enterprise Architect and Trello, to name but a few.

Because BBD has adopted an Agile mindset, the focus for each project team is on working software and client interactions rather than exhaustive documentation. This way of thinking informs how our BAs are adaptive to working in a manner that is most beneficial to our clients. “BBD isn’t prescriptive. Having our BAs as a flexible fulcrum for the management of the task, people and project as a whole, helps ensure that the business logic and user requirements stay top of mind.”

Lastly, and maybe most importantly, is the working relationship between developers, BAs and the client. Like any good relationship, it’s one built on trust. While the BA has to be technically aware, they are not expected nor presumed to be, a technology expert – that’s the developer’s realm. Draper adds that BBD BAs are so good at their job because they ‘speak developer’.

Despite this, a clear understanding of the solution will aid the BA in knowing what is possible; avoiding fanciful requirements and impossible expectations. Similarly, a developer need not be a whizz in the business domain and should rely on the BA to provide the necessary understanding or knowledge of the problem being solved. BAs also shouldn’t be afraid to run thoughts and ideas past the development team.

Remember, solutions are built as a team. Draper explains it as all coming down to the working relationship between the analyst and the developer; the better it is, the more timeous the delivery and better quality the solutions are.

The software development world without BAs would be rife with unmet expectations, unhappy clients and frustrated developers. Draper concludes that any software development house would want to avoid this outcome, and for BBD, BAs are simply non-negotiable in their teams.

LEANing into Service Delivery with User Story Mapping

Written by Jason Greatrex on January 23, 2019. Posted in Articles.

Canadian winter weekends bring snow, shoveling, – and those of us with tiny tikes, Little League Hockey.

Nothing says Little League Hockey, like weekend hockey tournaments. During these weekend getaways, travelling along highways to arenas, hotels, cities, and back again we invariably hit a few Tim Hortons coffee shops. (Perhaps, too many, as a successful tournament means several stops a day for the parental coffee fix!) Although each Tim Hortons is a standard franchise, offering the same products, the customer service experience can vary substantially.

Experiencing such inconsistencies and inefficiencies instinctively activates our Business Analyst training. What is the situational problem? How can we re-engineer this process for better service delivery effectiveness? If improving the process, leads to delivering a better service, then immediately, two tools and techniques spring to mind: User Story Mapping and LEAN improvement methodology.

Provide a Customer-Centric Approach

By using a User Story Mapping technique, you provide a customer-centric perspective to the problem. User Story Mapping is about building a narrative from the user’s perspective. This storyline traditionally describes using a product; however, the flexibility in this tool allows the technique to be equally transferrable to describing a process flow or delivering a service like serving coffee and Timbits. For practitioners, not acquainted with User Story Mapping and its approach, an in-depth description can be found in Jeff Patton’s book, “User Story Mapping” is a must have BA resource.

At a high-level, User Story Mapping is a collaborative team technique that begins first with individual experiences. Team members express their own personal experiences using a product, performing a process, or delivering service. Describing an individual’s own perspective, each participant writes their activities on separate Post-It notes. These actions take on the structural format of verb-noun or action-object, like “greet customer,” “add sugar,” or “pour coffee.”

Develop a Shared Understanding

After individual experiences are captured on multiple Post-It notes, the team comes together to build a narrative, combining these separate users experiences into a single collective story. Collectively, team members stick their Post-It notes up on a wall. The storyline they create resembles a book, starting at the left and finishing on the right. At this stage, the team works collaboratively to map a “collective” narrative of the service, discussing, and collectively designing and understanding the overall big picture from these various detailed tasks. This activity creates a chronologically organized story, mapping the processes activities and, the outcomes of service delivered, including a shared understanding and agreement among the team.

Apply LEAN Methodology

This collective narrative sets the team up for reflective analysis of the processes they perform and the services they deliver. Standing back, looking at the entire process from end-to-end, both a high-level overview and multiple detailed actions create the stage to apply LEAN methodology. LEAN by its core definition is the elimination of waste. Thus, LEAN methodology focuses on reducing activities that do not add value to the customer, such as unnecessary work, extra work, or rework. For example, when analyzing the process in preparing a customer’s coffee, is the employee’s environment set up with readily available milk, cream, sugar, stir sticks, and lids? Having these items easily accessible means the employees need not move to another location and therefore are not wasting time or energy with additional work. Another key LEAN principle that compliments User Story Mapping is that both methodologies focus on the customer. Applying LEAN improvements always come from the customer’s perspective. In LEAN literature, this customer’s perspective is called the “Voice of the Customer.”

With a service story expressed from a customer’s viewpoint and an eye for reducing and removing unnecessary work, the team is in a position to deconstruct the service. One approach to help the team focus on identifying only its service essentials tasks involves placing a line of tape directly under all the Post-It notes on the wall. Next, team members are asked, if you were limited on time and resources what and how would you provide this service in the shortest and most efficient time possible. Then place those essential actions written on Post-It notes below that tapeline.

Establish a Minimum Viable Process-Service

This tape line acts as a visual separator, or a demarcation point, where all current activities described are above the tape line and, those tasks posted below, are the essential elements needed to deliver that service. The activities underneath the line represent its minimum viable process (MVP) or — in the context of a service — its minimum viable service. This identification and deconstruction process translates as the least amount of effort to deliver a service to the customer. As a unit, the team can step back, observe, communication, and collectively flesh out where excessive work may be occurring in their processes.

This parsing down exercise takes on an iterative and incremental form. Few processes are refined immediately.

Experimenting must occur, physically moving the Post-It pieces around the wall finding efficiencies and improving process flow. The delivery of an effective service is all about improving the process that delivers that service. This collaborative exercise translates value back to the customer, the end-user of the service. The MVP point, although an effective outcome, can also act as the starting point in the processes continuous improvement cycle, a baseline from which a team can incrementally build up their processes and services incrementally, evaluating, analyzing, and adding what is important.
Increasing the success rate for people accepting process re-engineering and adopting continuous improvement techniques are dependent on defining a common purpose and building commitment from those involved. The User Story Mapping technique is a natural and simple platform for facilitating and supporting collaboration between people and teams while deconstructing a process from a customer’s perspective with a common goal focus. If services delivered are defined by their process, then the procedures behind how Tim Hortons staff brew, package, pour and pass coffee to the customer reflects the service provided and perceived by customers. Thus, by refining the process, you can improve the service. Applying the user story mapping technique and LEAN methodology improvements do that.

In improving the process, you improve the service — are you improving your processes to better your service delivery? Buy a coffee and see for yourself!

Efficacy of Team Working Agreement

Written by Bola Adesope, B.Sc, MCITP, CCNA, MCTS, PMP, ITIL, PRINCE2, BAP, SSYB, SFC, CSSBB, CBAP, MBA on November 7, 2018. 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.

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

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.
Team Agreements, when well done, help even the most controversial of teams come together to produce great results.
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:

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
Involve everybody on the team in the development of the TEAM AGREEMENT
Ensure everybody on the team agrees to the TEAM AGREEMENT, and if required, have them all sign it.
Do not make the TEAM AGREEMENT too long or one-sided
Make the TEAM AGREEMENT visible. Paste it on every wall the Team uses.
Continually review and update the TEAM AGREEMENT.

Wish you a productive and high-performing TEAM.