Skip to main content

Tag: Facilitation

It’s the End of the Business Analysis World as we Know it? Part 5

Written by Steve Blais on . Posted in Articles.

FEATUREJuly30thBeing the serialized story of Brian Allen and Ann Brady, business analysts, and their Adventures in the New Oder of Agile

Excerpted from the forthcoming book from John Wiley, The Agile Business Analyst due out the end of 2013

Chapter 5:  Wherein the business analysts encounter the Scrum Master, Scott discloses his concerns about business analysts and Verna summons

The organization was quite dynamic.  Meetings were held in the hallways and corridors of the vast headquarters on a more frequent basis than in the meeting rooms. This might be considered by some to be an agile practice since the meetings were held not only standing up, but moving along, which meant that the meeting had to be completed by the time one or more participants got to their destination or their ways parted.

Thus it was that Brian and Ann attended meetings that morning.  Brian ran into Ann as he came out of the elevators after arriving at work, his black Swiss Army backpack slung over one shoulder and a cup of coffee in his hand.  Ann had had an earlier morning meeting with Belice Despacio who was assistant to the CFO. Ann was presenting the information she had amassed on the efficacy of buy versus build decisions on the Backbone project. She considered it her ‘kiss-off’ project for the organization.

“I don’t know about you, but I’ve been avoiding people like the plague these past couple of days trying to get things in order.” Brian greeted her.

“Me, too. You mean you haven’t seen Ken or Scott?”

“Not yet.  But it looks like the waiting is over.”  Ken came down the hall toward them.

“Shall we make a break for it?  If we run in different directions one of us will get away.” Suggested Ann.

“It’s all right, kid.” Said Brian doing his best Bogie imitation. “They’d find us wherever we went. We gotta stay here and face the music.”

“It isn’t even High Noon yet.”

“Well,” said Ken with a vacuous smile. “It’s the Last Brigade, or maybe I should say Lost Brigade?  I see that you have managed to infiltrate your business analysts into the projects anyway.”

“Nope,” said Brian continuing to walk. “There are no business analysts on the Backbone project. There are new developers who used to be business analysts and there are product owners who used to be business analysts.”

“And there are impact analysts working with the product owners,” added Ann.

“Why do I feel this is a trick?  Once a business analyst always a business analyst.”

“First of all,” said Brian, putting his backpack down and facing Ken. “There is no such thing as ‘once a business analyst’. None of us were born business analysts nor did we plan to be business analysts throughout school. We all gravitated or were inserted into the position and the profession. Most of us came from other disciplines like systems analysis or engineering for which we were initially trained. Both Ann and I have done some turns as project manager. Many of us came out of school as engineers or with IT degrees. So it’s not that difficult to move back to one of our former positions. Besides, you have a lot of former Java and C++ programmers working on your dot-net and C# programming projects.  Do we say the same thing about them?  ‘Once a Java programmer always a Java programmer’?”

Ken ignored Brian and walked away.  “Good luck in your new jobs elsewhere in the organization, Allen.  But remember, the New Order of Agile is taking over.  Two more divisions have decided to also go with agile. There won’t be any place to go soon.”

As Ken walked down the hall and Brian shouldered his backpack, Ann mused, “We were avoiding that?  I wonder what he really wanted to see us about.”

“I guess I distracted him.”

“O, well, looks like today is the day.  Here comes Scott, and he looks like he knows why he wants to see us.”

Scott looked troubled.  He came straight at them like a shark after its prey. Brian could hear the Jaws theme playing in the background.

“I’m glad I found you,” breathed Scott. “Can we go someplace to talk,” he said conspiratorially looking over both shoulders. “How about a cup of coffee.”  Brian stared at the cup of coffee in his hand and then at Ann and said, “Sure.  Why not? I’m not on the clock yet anyway.”

After they got settled in a corner table of the cafeteria with their coffees, Scott leaned forward, put his glasses on the table and pushed back his longish black hair. “What do you know about Scrum Masters?”

“It’s a Zen discipline arising from the sport of Rugby in which there is both a ball and not a ball and the less you try to score the more goals you make,” offered Brian.

“My, we are quick this morning, aren’t we, and only on the first cup of coffee,” commented Ann. “We know what a Scrum Master is, Scott. What’s your problem?”

“We drafted our Scrum Masters from our developer teams. We let them volunteer because we didn’t want to impose any management selection of roles on them. These are, after all, self-organizing teams.” He paused for acknowledgment, and receiving none, continued. “Those who said they would like to be Scrum Masters were sent to Certified Scrum Master classes at our expense. So we got a number of CSMs to fill the role for the Scrum teams.  Of course it was difficult. Most of the developers did not want to give up their coding to run interference for the teams. Many also felt that the Scrum Master had to indulge in politics and wanted no part of that. “

“I’m not sure I understand,” interrupted Ann. “What ‘politics’ are they concerned about?”

“One of the primary duties of the Scrum Master is ‘removing impediments to the development team’s progress’ * and another is working with the organization to promote and promulgate Scrum: ‘The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t’ And these things mean that you have to deal with the rest of the organization and that means politics.”

“Isn’t that what you and Ken are doing?” asked Brian.

“Yes. And we take seriously those edicts. And we are ‘leading and coaching the organization in its Scrum adoption’. But that is beside the point. And the point is that we don’t have enough Scrum Masters, and those we do have are not working as well as they should.”

“Didn’t they go to class and get certified?” Asked Ann.

“Yes. I said that. And the certification is two days of class followed by an exam. And it’s a fairly easy exam, too.”

“You passed it?” asked Brian.  Scott didn’t pick up the sarcasm. He continued: “And they tell you what to do, but there is no real training in how to do it. And, for example, in one of my teams a senior developer is somewhat arrogant and is shredding the new, young product owner. She has left the room in tears as a result of his questions.  And all he says is ‘there is no crying in software development’. And I have no experience in dealing with such things, since I am basically a developer.”

“Once a developer, always a developer”, chided Brian, only for Ann’s benefit as Scott was oblivious.

‘As I recall,” Ann tried to bring the conversation back to the point. “The Scrum Master also “Leads and coaches the organization in its Scrum adoption, causes change that increases the productivity of the Scrum Teams, coaches the development team in self-organization and cross-functionality’ *, and so forth. Those are high expectations for a developer, or anyone for that matter. Was your plan that they should be able to do these things with a two day class?”

“No. In agile it’s about learning. Each of the Scrum Masters would learn how to deal with people and learn how to play their Scrum Master roles.  But they are not learning fast, and some don’t seem to be able to learn, or want to learn. And I’ve had three tell me they don’t want the position anymore. And the others on the team see that happen and they don’t want to step in. And I think we are discovering that learning soft skills is not as easy as learning a new programming language or hardware platform.”

“It seems to me as though the Scrum Master job description was written as an inducement for organizations to bring in experienced, qualified consultants. I recall one of the tenets says the Scrum Master ‘coaches the Development Team in organizational environments in which Scrum is not yet full adopted and understood,’ and ‘Helps employees and stakeholders understand and enact Scrum and empirical product development’. So why don’t you just bring on the consultants?” Asked Brian.

“No can do.  I think we oversold the simplicity of the Scrum concept to Carl and Vince. And they won’t pay for consultants. They say the self-organizing teams should be able to handle it themselves. And they were willing to allow for a ramp-up time and the classes. And they expect that since the developers are able to talk directly to the business now that they should be able to do the Scrum Master roles as well. So, no consultants.”

“Yes,” agreed Brian. “It would seem contradictory to the concept of simplicity to have to bring in a high paid consultant to get things started. But what about the project managers?”

“Ken didn’t want any of them around. He wasn’t sure they could successfully drop their authority around the team. And even if they were able to stop managing and start coaching, the teams would still see them as project managers and that would make them ineffective. And, besides, Carl grabbed all the good project managers and assigned them to other projects in the organization and let the others go.”

Ann sat back and sipped her coffee. “Hmm.  OK. Sounds like a problem. What do you want us to do about it?  Offer suggestions?”

“Actually, I’m looking for advice, and maybe a little help.  One of the aspects of business analysts I have admired is their facilitation skills: they seem to be able to enable discussions and get people involved. And, like you two guys, you seem to be able to get things done when you’re on a project, especially outside the project boundaries, working with other projects and business areas.” Brian and Ann exchanged glances, both with raised eyebrows “And I am thinking that we might be able to co-opt some business analysts into being Scrum Masters. For example, Shelly. Shelly is able to make a meeting work well. I go into a meeting and have no idea why I am there. And even when there is an agenda, all it does is list the attendees and none of us know why we are there. But a meeting with Shelly always goes well. And when any of us walk out of a meeting that she attends we know exactly why we were in the meeting and always feel that we spent our time well. And, she, like, asks questions and gets the attendees to come to conclusions, even when the meeting isn’t hers.  And she seems always to be able to resolve conflict among the attendees if there is any, even among developers, and sometimes even before it starts.  And I’ve seen you two do this as well.”

“Well,” replied Ann.  “That could be arranged. We can send a few of our remaining available business analysts to Scrum Master classes and they can be Scrum Masters for your teams.”  Ann hid her delight at having this solution drop into her lap. 

Brian on the other hand had another question. “Scott, you seemed to be totally against business analysts.  And now you are singing our praises. What gives?”

“I am not singing the praises of all business analysts.  I’ve been in meetings with the users and your typical business analyst. And I’m there in the meeting for technical support and half the time I just sit there and daydream or wish I could open my laptop and do some coding. And the business analyst just sits there and takes notes. And whoever it is says that they are there to get the requirements and then records what the users tell them. Sometimes I have to ask questions when the users ask for something outrageous. And the BA takes everything down, you know?  And it all ends up in the requirements document. And the BA tells us, ‘it’s what the customer wants.’ I mean, we could do that, and we’d spend more time asking questions  And then later we find out that it’s not quite what the customer wanted because the user forgot to mention something or didn’t state it clearly. And the BA complains about the customer changing their mind or never knowing what they want.  And, I mean, we could do it, you know?  And, even if we did the same thing, which I doubt, at least we’d be getting the straight scoop, and getting it earlier. And the business analyst just does not add value to the exchange.  Present company excepted, of course.”

“Of course.” Said both Brian and Ann together.

So it was agreed. Shelly and Juan and a couple of others would start work as Scrum Masters applying their business analyst facilitation skills to ‘facilitating Scrum events as requested or needed’ *. They could use their influence, negotiation, mediation, and conflict resolution skills to support the teams and the projects as Scrum Masters. Scott and Ann would schedule them into Certified Scrum Master classes as soon as possible.  Scott agreed that both Brian and Ann would make excellent Scrum Masters, just as they might make excellent Product Owners, but they had been business analysts too long and the imprimatur of their role and their reputations in the organization would act against them in being successful as servant leaders, just as the former project managers would have run into difficulty. “And besides, there’s Ken standing in the way”, concluded Scott.

“Well, that’s it,” breathed Ann as they left the cafeteria. “Looks like we did it. That’s everyone accounted for. ”

“Except us,” said Brian hoisting his backpack on his shoulder.  “However, that is all the meetings, right?  Everyone who was looking for us found us.”

“Not everyone.” Ann was afraid to say the name. Just then Sandra, Verna’s Personal Assistant, rounded the corner and headed straight for them with Ken at her elbow. Ken looked like he remembered why he had been looking for them.

Was Ken in Cahoots with Verna?  Had he swung Verna over to the New Order of Agile Development?  Would this be the end of Rico?  And do we have to hear Scott say ‘and’ one more time? And where is Cahoots, anyway?  Tune in for the season finale where we find out what happens to the last two stalwart business analysts in the organization and finally meet Verna although like the Sopranos, the screen may go blank when we do.

* Quoted from Schwaber & Sutherland, “The Scrum Guide, the Definitive Guide to Scrum: the Rules of the Game”, published by Scrum.org, July 2011

Don’t forget to leave your comments below.

Innovation and Business Analysis

Written by David Morris on . Posted in Articles. 3 Comments on Innovation and Business Analysis

How can I use the concepts of ‘innovation’ and ‘business analysis’ in the same phrase?

While, to some, this might sound oxymoronic (like the term ‘deafening silence’), or at least moronic (and those who know me would expect nothing less); I would argue that innovation contributes to business analysis, and business analysis contributes to innovation.

What does this mean and how do we make it happen?

We don’t need to be innovative, though, do we?
Business analysis practitioners can provide an excellent service as we work through the project process, asking questions, applying techniques, creating documents and presentations, and clarifying how to implement the approved solution. Like any discipline involved in business change, done well, business analysis can make the difference between a successful and a struggling project.

Where we can add real value, is in providing creative analysis – enabling stakeholders to think outside the box, encouraging them to behave like their project was their own business so that they care about the outcomes, and providing thought leadership from the project space to the organisation.

How innovation contributes to effective business analysis
An essential purpose of business analysis is to “recommend solutions that enable the organisation to achieve its goals” (p3, BABOK v2, 2009). Sometimes this will involve helping organisations to ‘invent’ something new, although more often it will be to ‘innovate’ – to improve something already in use.

However, with business analysis typically practiced within the confines of a project, under the direction of a project manager, we risk adopting convergent thinking approaches. By following the ‘correct’ process to document requirements for sign-off, we can be seen to add little value in the process – that is, we become a requirements clerk gathering requirements.

Of course, we are more effective where we plan and manage our own business analysis activities, identifying the stakeholders and negotiating the scope, so that we can elicit, analyse, document, and communicate what is needed.

We add even more value where we apply divergent thinking too; this is where innovation is key to business analysis.

What does this mean? We need to push our stakeholders outside their comfort zones, to think laterally, to challenge them beyond an assumed solution and find out why they want something – so that we can be clear about what they really need and guide them to selecting the optimum solution, not just the one they first thought of; that is, let’s not make a bad process faster, let’s design the right process and work out how that needs to be supported.

How do we do this? At its simplest, this requires two things: to develop our underlying competencies (in areas like creative thinking, problem solving, and facilitation), and to have the courage to push back (suggesting that there could be alternative solutions, challenging to ensure that the underlying causes or needs are identified).

How business analysis contributes to effective innovation
Business analysis also has much to offer to how an organisation approaches its innovation processes, that is, well before there is a project.

Innovation in the pre-project stage
Most organisations will go through some form of scoping and business case stage before a project is initiated. While this is often undertaken by a project manager; mature organisations and PMOs recognise that it is a better fit for the BA to build the case for a project, or at least support the business owner in doing that. (Indeed, some would argue that you cannot assign a project manager until you have a project to manage, however there is always business to analyse).

Now, you might contend that building a business case is not showing innovation, it is simply taking the information that is available then researching and analysing it enough to understand the likely costs, revenue, duration, return on investment, risks, etc.

However, to develop a strong business case, we are required to explore alternatives, and can often uncover unexpected options or combinations that were not in the mind of the customer or requestor. More examples of divergent thinking.

How do we do this? If BAs in your organisation do not currently work at this level, find a small project that cannot yet proceed because it needs a business case, then volunteer to ‘have a go’. Even if it still doesn’t get the go ahead, you can learn from the experience and interact with stakeholders in a slightly different role.

Innovation in ideation
Further upstream (in the new product development process), before an idea has even been approved to be scoped and have a business case developed, business owners are busy working with sales performance data, customer satisfaction feedback, market research, and blue-sky thinking – divining answers that will result in a new or improved product, give a jolt to sales, or eventually withdraw a product from the market.

Equipped with our divergent, lateral-thinking, and facilitation skills, we can really enable an organisation to make the most of smaller investments to determine if an idea makes sense, before anyone even thinks of writing a business case. Working at this fuzzy front-end is also very rewarding; as well as being very focused on good business outcomes, you definitely get a sense of play, and interact with senior management.

How do we do this? Opportunities for these sorts of roles are rare, and are often promoted internally rather than advertised. The best way to attract these is to be seen to perform well in the pre-project space, and if there are ever any moves to revise the solution delivery lifecycle, governance, and/or new product development process, volunteer to be involved – from there you can agitate for a role like this and position yourself as the ideal candidate.

Conclusion
I’ve shown that irrespective of where we work in an organisation, and the development process stage, business analysis has much to offer in terms of helping foster innovation in our organisations. Do you agree?

I’ve said it’s rare for us to work outside the project space. Is this your experience?

What steps can we take to convince our organisations to allow us to play in this more creative space?

Don’t forget to leave your comments below.

The Great Facilitator Part 4: What Great Facilitators Know About Estimating

Written by Bob Zimmerman on . Posted in Articles.

Bob_Z_mar_27_28309844_XSIn my previous article, I shared an exercise that helps teams understand how to develop a plan that is manageable and achievable. I call this “Commitment-Based Estimation.” Now I will show how great facilitators can play a role in making their teams super confident about their estimates.

Who Should Facilitate an Estimation Session?

Before we talk about how to do a great job in facilitating estimation sessions, I’m going to discuss how to select the best person to facilitate these sessions.
I typically find that the Team Lead drives estimation sessions. Project Managers and Architects are also fairly popular in this role. The key, however, is to find a person who will allow the team to own the estimate.
When a Project Manager leads the estimation, they usually drive a team to develop estimates that reflect the project plan. Once the Project Manager starts imposing schedules, or challenges the team to optimize an estimate constantly, then the team won’t feel ownership. This is not how to get a Commitment-Based Estimate.

Similarly, when an Architect drives the estimate, they typically assume a technical frame of reference and try to help the team understand the mechanics of the estimation. If they impose their vision for the complexity of certain tasks, once again, the team won’t feel ownership.

So who makes the best facilitator for estimation sessions? I’d say look for a person who is:

  • Part of the team and has skin in the game
  • Already a respected leader and trusted by the team not to impose their personal views
  • Is experienced in helping teams balance risks, contingencies and dependencies

The One Rule You Should Never Break

There is one rule the facilitator must never break: Allow the team to come up with estimates they believe in. Unless the team is very junior or new to estimating, every team needs the freedom to come up with their own estimates. If the team asks for two weeks, never impose a shorter schedule and tell them to get the job done in one week.
Now you may be thinking: Does this mean I can never challenge a team? It does not. What it does mean is that as a good facilitator, you ask the right questions and help them share and test their assumptions.
For example, ask the team: “What would you need to get this done in a week?” or “How much can you get done in a week?” By asking the right questions, the scope may get reduced. Now you get the deliverable within a week because the estimation was not imposed on them. Again, the facilitator does not want to undermine the ability of the team to own the estimate.

Other Things Great Facilitators Do:

Some of the other approaches that have helped me personally manage some very strong groups include:

  • Make sure the team does not give an estimate that is simply unrealistic. I talked about this recently on my blog, in a post called “Attitude of Estimation.” As a facilitator, you want to encourage the team to come up with an estimate that is workable.
  • Ask questions and create assumptions to make the team think of scenarios that might happen. This helps the team create more accurate estimates.
  • Make sure everyone has a voice. Business Analysts need to be able to articulate the business needs and clarify what is being delivered. Project Managers can offer perspective on dependencies and resource availability. The QA team needs to test not only to see if something works, but also to see if the product is in compliance with business needs. Developers, Architects and the database team also need to weigh in. Too many times an estimate does not include a full set of voices and results in inaccurate estimates and mediocre functionality.

In my opinion, too many people take the facilitator role for granted. I think there are some jobs that are too important to perform any less than perfectly. Facilitation is one of them. A poor facilitator can break the spirit of a super talented team while a great facilitator can lead a good team to surprise itself on what it is capable of.

Get the whole picture by checking out the other 3 parts of this series –

Part 1 –  Part Business Analyst. Part Orchestra Conductor. Part Psychologist – Do you think of yourself as an effective facilitator but unsure how others perceive you? Maybe you’ve been at a meeting recently where the facilitator is doing a fantastic job but you just can’t figure out exactly she is doing differently. The differences are subtle.  This series is about those subtleties that separate the great facilitators from the mediocre ones.

Part 2 – Check in and the Chair:  Why can some facilitators effortlessly lead their team to achieve brilliant clarity and enthusiastic alignment? This article includes some basic practices great facilitators use to manage a room and deliver impressive results.

Part 3 – Commitment Based Estimation: In order for an estimate to have teeth, the team must feel ownership of the process and genuinely believe the estimates are achievable. This article includes exercises to facilitate estimates that are realistic and manageable. 

Don’t forget to leave your comments below.

Bob Zimmerman’s career in custom software development spans more than two decades and has been largely dedicated to the process of leveraging technology to drive innovation and growth. As Geneca’s CTO, Bob Zimmerman continues to build on his work as the driving force behind Getting PredictableS.M., the requirements definition and project best practices that are the foundation of Geneca’s mission to make software development predictable. He continues to extend these best practices to leverage more value for clients and new growth opportunities for Geneca.

The Best Virtual Meeting…EVER! Five Fun Games to Engage Your Virtual Project Group!

Written by Claire Sookman on . Posted in Articles.

Do you ever have those days when go you off on philosophical tangents? You know, those cold, gloomy mornings when you stare out the window, coffee mug in hand, wondering, “Does a fish know what water is?”, “Is the colour red really universal?” or “Is Robert from marketing a real person?”

We’ve all been there. The truth is it’s hard for virtual project groups to bond on a personal level with other group members…partly (well, mostly) because we may not even know what the other person looks like! Without bonding, the results could be dangerous. The University of California, San Francisco, lists some of the common symptoms of a disengaged team:

  • Decreased productivity
  • Conflicts or hostility among staff members
  • Confusion about assignments, missed signals and unclear relationships
  • Decisions misunderstood or not carried through properly
  • Apathy and lack of involvement

And there’s more:

  • Lack of initiation, imagination, innovation; routine actions taken for solving complex problems
  • Complaints of discrimination or favouritism
  • Ineffective staff meetings, low participation, minimally effective decisions
  • Negative reactions to the manager
  • Complaints about quality of service

And there’s still more! A 2009 article from the Occupational and Environmental Medicine showed that a lack of team spirit can even cause employee depression…But don’t panic!

Before you scurry off to Google, furiously searching “how to engage virtual project groups” — take a breath. We’ve done the work for you. Here are some innovative games that are sure to have your team amused and engaged in no time.

1) Virtual Charades – Charades is a great game that builds group spirit, whether in a traditional workplace or a virtual one. If your company usually sets up video conferences for meetings, this is definitely a game that will have everyone working together, solving problems and having fun along the way. If you’re unfamiliar with the game, Charades requires the player to mime or imitate a certain action or subject that the rest of the team has to figure out. For more information on how to play, click here .

For those who use voice chat instead of video chat, there’s a fun alternative for you too — Voice Charades. For Voice Charades, create a secret list of objects, animals or famous people. To decide who will go first, enter all team member names onto a site such as Random.org and choose the first name that shows up. Email or send an individual/private instant message to this team member letting them know what they will be acting out. Remember to keep the clues work-appropriate and respectful of others. Have fun guessing what/who the person is imitating. Some entertaining suggestions are:

  • Printer sound
  • Al Pacino impersonation
  • Star Wars Light saber
  • Monday traffic
  • Radio anchorman

2) Spin a Tale – This fun game fosters creativity and helps team members think on their feet. During a meeting, make up the first line of a story. Then ask team members to take turns and add each subsequent line until a whole plot develops! Let the story go along on its own path and deviations. This is the fun part of the game; you never know what perils or fortunes can occur next! The best thing is, even though your team may develop favourite start tags, the story will never end up the same! In other words, you learn how to think innovatively. Here are some ways you can start your tale:

  • I woke up at 9am — that was when we were supposed to Skype in for the meeting…
  • Jared looked over the ledge of his balcony, wondering why the crowd had gathered…
  • The email had no subject line…I hate it when he does that…
  • Fifteen years, 15 days, 15 hours and finally the letter had come…
  • As Sophia hid behind the red SUV in the parking lot, she tried to remember how exactly she had gotten there…and why there was that giant scar on her arm…

3) Situation Puzzles – Situation puzzles are an exciting way to exercise creative problem-solving skills while also building team unity. In a situation puzzle, the team leader states one mysterious sentence such as, “a bell rings, a man dies, a bell rings”.* The rest of the team must now solve the situation by asking “Yes” or “No” questions. As each question unearths new information, the team can creatively build on each other’s thought patterns and ideas until all the loose ends are tied. A great reservoir of situation puzzles can be found here!   *(Click here for the answer)

4) PowerPoint Game – You will never look at PowerPoint presentations in the same light after this game! This is a great way to get group members thinking on their feet while having loads of fun. To play the PowerPoint game, go online and find a series of complicated or extremely nonsensical PowerPoint presentations (try SlideShare). Then ask team members to improvise a presentation with the slides they’re using. Hilarity is bound to ensue! Go here for more information about the PowerPoint game.

5) 2-Minute LOL – This is another improvisation game that will get everyone thinking fast, learning about team members and literally laughing out loud. First, divide the team into smaller groups or partners. Then give each group a topic or let them choose one. Allow each team about five to ten minutes to create a set of jokes based on their topic. Make sure they have this discussion in a separate virtual conversation so that the rest of the team does not hear the punch lines beforehand. When everyone regroups, randomly choose a group to go first while timing their comedy improvisation for two minutes. Once again, remember to keep all jokes respectful and workplace-appropriate. Award the funniest team with a gift card or some other form of prize!

And there you have it — five amazing ways to engage your virtual project group! Try them out and let us know which game your team liked the best! And if five tips aren’t enough, here’s a whole book full of tips! Across the Hall, Around the World is the ultimate archive of virtual team-building tips that’s sure to get your team engaged!

Don’t forget to leave your comments below.

Claire Sookman is the driving force behind Virtual Team Builders, Claire brings to the table over a decade’s worth of corporate and public sector training experience, working with over 4,500 managers in the past three years. Specializing in virtual team building and communication strategies, Virtual Team Builders provides training that enables global teams to work more efficiently.

The Missing Link to BA Competency Development

Written by Angela Wick on . Posted in Articles. 1 Comment on The Missing Link to BA Competency Development

When I think about what it takes for BAs to be successful, it always comes down to the same thing: Using hard skills and soft skills together strategically to get results and engagement from stakeholders. When I think about what it takes to execute on any BA activity or technique and to be good at it, it is rare to find a scenario when both hard skills and soft skills are not needed. This may not be new to anyone as underlying competencies (many of which are soft skills) are foundational to performing the various BA tasks. Where we fall down on this is in executing this concept well in a variety of situations and complexity levels and showing the path to truly deepen these competencies.

Why is it that we rarely look at the path to developing skills in underlying competencies in the context of BA tasks and techniques? Or when they require an elevated and advanced level of complexity to execute well?

I would like to look more closely at these skills in additional dimensions.

For example: It is easy for someone to say they have been trained in facilitation, and may have some successes and good experiences in facilitation, and therefore they feel they are a great facilitator. But what does it really mean to be a great facilitator? Are those learned skills and experiences really enough to succeed in new and more complex situations? Would they really be successful in facilitating a highly complex topic while working to build consensus with a group of executives?

A BA organizes and facilitates a meeting with a group of stakeholders to review the future state of a business process. The process flow being reviewed was technically correct and the facilitation methods, tone and techniques were flawlessly used. However, the meeting still failed to achieve a desired goal of reaching consensus from a group of executives on the future vision of the business process. 

What happened?

This was an opportunity to strategically use the skills of facilitation and process modelling together aligned to the purpose of the meeting. In this example, what gets missed is thinking about the goals and purpose of the meeting as well as the audience, and thinking about how to use these hard and soft skills strategically for the purpose. In many cases like the scenario above, the process flow and meeting planning were thought of as needed together, but not strategically planned and executed together; they were performed as separate tasks in the same meeting. There is an opportunity for the meeting goals, agenda, and expected participation to drive the level of detail that the process flow is presented at.   The review and discussion, along with expectation setting with the participants on the level of detail is critical to the success of the meeting. This was a missed opportunity to engage executives in the facilitation techniques used by modelling at a higher level appropriate to the ways they engage.

The soft skills needed to be a great business analyst are difficult to develop. It is hard to find resources, mentoring, etc. that really help develop these skills in the context of being a BA in a variety of contexts, situations and different stakeholder groups.

We hear from our leaders about how important soft skills are, and are usually trained on them separately from BA tasks, activities and techniques. It can be a challenge to apply what is learned to the BA context. Rarely do we discuss or hear about leveraging them together. This makes it difficult to grow and apply the skills and build awareness of when to use soft skills. Some would say it is intuition, and either you have it or you don’t. I believe there is some truth to that, but that much can be learned through developing experience and awareness.

My callout to the leaders of BAs:

Give mentoring and feedback that shows the context and linkage of soft skills and hard skills together to your BAs in the context of business analysis. Help your BAs build an awareness of situational complexities.

My callout to BAs:

Seek feedback in specific situations on a variety of soft skills and how the situation and tactical activity could be improved through soft skills.

Focus more on developing these skills together and seeking feedback on how we use these skills together.

Truly bringing tactical and influence skills together by thinking differently about how we plan and execute our BA activities and technique usage is key to developing strong competencies as a BA. 

What are your thoughts and examples of how BAs can leverage tactical hard skills with influential soft skills? 

Don’t forget to leave your comments below.