Skip to main content

Tag: Learning

Better Tools 5: Managing Feedback in Word Documents

SmartExtract is a tool that extracts revisions, comments and similar feedback made by others into a table so that you can review and respond to them.

The table includes the context of the change so you can interpret the feedback, often without needing to refer to the source document.

It complements my earlier posts which describe Word tools for quickly recording content into tables, automating the layout of bulleted lists, and a hand drawn process modelling stencil for Visio. The last post was Better Tools 4: Productivity Tools for Process Modelling in Visio, which provides a set of Visio tools to resize and realign shapes in process models.

Smart Extract

SmartExtract allows you to summarize comments and revisions received in a word document. It extracts the feedback into a table that allows quick point-by-point responses that look very professional. Providing detailed responses is a great way to acknowledge the effort reviewers have put in, and using this tool makes it easy.


{module ad 300×100 Large mobile}


By showing each comment or revision in its wider context, your own review of the feedback can be very efficient, allowing you to skim through minor changes and focus on those that are important. If you do need to refer to the source, there is shortcut key that takes you from the summary entry directly to the page in the document where the comment or change occurs.

If there are multiple reviewers, collating a summary of all changes into a single table is a great way to prepare for document review meetings.
If you record placeholders for gaps and highlight areas for rework in your own documents, the tool can also be used to summarise the outstanding work to be done to complete a working draft.

The summary report

The sample below shows the summary extract. Each change or comment appears in the order it appears in the document and is numbered for easy reference.

coomber1

Context

The context of the change or comment is given, with the specific change or comment highlighted within it. In most cases, the context is sufficient to make decisions about the feedback.
If the change or comment is in the body of the document, the context includes the preceding 30-40 words. If the comment or change is in a table, you see the contents of the entire cell.

The page and line number of the change or comment are shown, and a reference to the table row in any table is given. If you click into this heading line and press a shortcut key you will be taken directly to the relevant page in the source document to inspect the comment or change further.
Insertion and deletion changes are shown as they are normally seen in track changes, in a different colour and with deletions shown in strikethrough. Comments are shown in grey highlight.

Only insertion and deletion changes are recorded by SmartExtract; formatting changes are ignored.

A single large table can be assembled from several feedback documents returned to you. There are subtle layout rules in the context entry header that allow you to sort on this column and merge all responses into a single correctly ordered list.

Comment or Revision

The text of the change or comment is shown. As well as showing comments and revisions, SmartExtract also includes highlighted text because some reviewers like to use this as a tool to indicate gaps or other areas of concern.

Often a reviewer will make several minor changes, for example, correction of punctuation or change the tense of a phrase. SmartExtract combines minor changes into a single entry for the entire paragraph concerned. Without this, the summary table would contain many distracting low-value entries.

Author

The author column allows revisions from multiple people can be reviewed.

Action

The action column allows you to record responses to the feedback. Since the context and the comment or change are already present, the response does not have to be very lengthy, and in many cases, the same response is copied from entries above, saving a good deal of time.
Inspiration

I frequently receive feedback on the documents I produce. Collating this and responding to it is a real chore. I decided to write this routine after getting 12 sets of feedback on a lengthy document having to present a summary for a review meeting.

The ability to respond point-by-point to feedback is really important for me. In the past, any response I gave had to be very generic because of the effort needed to indicate each change before responding to it. This routine saves hours of effort and allows me to present professional responses very quickly.

Learning about Word and VBA programming

Word stores changes and comments in separate objects. Listing these in a table is fairly straightforward. However, I wanted one list showing all feedback of all types in their natural order. This meant some preprocessing and sorting to get the items in the correct order. I used arrays and a bubble sort to do this.
I also wanted to include the context; this meant determining the location of the feedback item and extracting the surrounding paragraphs. I had to understand and manipulate document and range locations using character and paragraph information. It also had to switch the source document into the correct mode so that the context copy process extracted the text in the correct format.

Another complication was the treatment of minor changes. I wanted to combine these into one entry for each paragraph. This meant pre-reading the upcoming changes, checking their size and collating them if they were minor, then resuming normal processing from the correct point onward.

As is usual with Word programming, special treatment for tables was an extra complication.

Becoming the Trusted Advisor

A couple of months ago I wrote on the value of the business analyst being a trusted adviser to many people on the project team and within the organization.  Read The Value of Business Analysis: The Trusted Advisor to see that discussion. 

I conveyed the business value of becoming that trusted advisor, but I didn’t tell you how to get there.  So if you read that article and thought to yourself “well that is all fine and dandy, but how do I become the trusted advisor to everyone within my company?”  Well, read on.

Set Expectations

Let your stakeholders know what is coming up next.  You shouldn’t leave anyone questioning next steps or action items; always call those out for both yourself and other team members.  When you take ownership of action items, that is called making a commitment.  It shows a willingness to be held accountable to complete the action item on time.  It does not guarantee completion on time, just shows your willingness to accept the responsibility.  There are many things that can crop up that get in the way of meeting commitments once they are made but never shy away from accepting the responsibility. This is a major way to earn respect.

When action items are assigned to other stakeholders on the team, especially when they intersect with action items assigned to you, check on their progress from time to time.  Your items may have a dependency on other’s action items or vice versa.  In the latter case, stay in contact with that team member and let them know your progress so that they may plan out their work on their action items.  When monitoring the progress of others, do it in a very non-intrusive and non-authoritative way.  Typically, you won’t have authority over someone else’s work so approach this from a co-worker checking on a friend or offering a helping hand.

Deliver

Now that you have made the commitment to take responsibility for an action item or task deliver on it.  Always work to finish your assigned tasks ahead of schedule so when those inevitable items pop up that take your time away from these tasks, you still have time to get back to it and deliver on time.  In this way your team members don’t see all your tasks slipping behind schedule. This is a major way to lose trust.  Be creative when the situation calls for it to complete task assignments.

I was always astounded by my children who always looked like they were trying to get a “C” in every class in school.  A “C” is a passing grade right…the problem was that far too many times they missed that “C”, and sometimes by a lot; so what did they end up with…a “D” or “F”.  When I was in school I always tried for an “A” in every class, whether I liked the subject or not.  So when I didn’t meet expectations what did I end up with….a higher GPA than my kids did.

Communicate

You know the old adage…communicate early, communicate often.  This ties back to setting expectations.  Let your team members know what to expect from you, so they can know how to work with you.  When new issues or risks pop up, identify and communicate them early so they can be properly managed.  Raise those red flags early.

Communicate bad news early.  When the project is behind schedule, when it needs more resources, or when lack of stakeholder engagement is slowing the project, address the issue with the project manager and/or project sponsor.  Be prepared with information and examples, and possibly a plan of action to get back on track.  This again ties back to setting expectations, are things slipping behind because expectations weren’t properly set or communicated?


{module ad 300×100 Large mobile}


Provide frequent updates to the project manager, project sponsor or other stakeholders on your work or the project solution.  Survey your stakeholders to determine the right level and frequency of communication.

Be Consistent

Be consistent in your setting of expectations, making commitments, communication, and interactions with your stakeholders.  Consistency is at the heart of integrity.  Inconsistency tends to build walls between people and inhibit collaboration.  When people don’t know how you will act or react, they may shy away from approaching or engaging you.  As a business analyst you need information, and when your stakeholders do not wish to interact with you or discuss issues in an open way, this impedes your ability to get the information you need to be effective.

Have the Courage to Challenge Appropriately

I will combine lessons from Elizabeth Larson, Rich Larson and Bob (BobtheBA) Prentiss to say have the courage to challenge appropriately.  It takes courage to deliver bad news or just say “No” to someone.  You may see how a simple “No” won’t go very far; people  will find other avenues to get what they want if they see you as a roadblock.  So be prepared to back up that “No” with solid evidence, data and/or facts.  As Elizabeth says ”Courage without preparation is foolish.”

You will not challenge every idea that others have; that  is truly foolish.  Make sure you take the time to understand fully the idea and reasoning behind it.  Determine if the idea has value and feasibility.  Take a structured approach to determining when it is time to challenge an idea.  When you do challenge, make sure you do it with respect to everyone including those that presented the idea to the group.  Make sure your challenge isn’t perceived as offensive or confrontational.  This is another good way to destroy trust.

To Gain Respect, Show Respect

This should go without saying, if you want respect you have to earn it.  One of the best ways to earn respect is to show it to others.  Respect every stakeholder’s expertise in their subject matter or domain.  Respect and acknowledge everyone’s contribution toward the common goal.  Respect their role within the team and organization.

Also, remember that your role within the organization is one of the newest, and not everyone has worked with a business analyst before or knows how to interact with that role.  So some education of your role within the team and organization may be in order.  Take a coaching approach to this opportunity and don’t make any feel dumb because they don’t know this yet.

Be Proactive

Anticipate the needs of others.  Not only your project manager and business stakeholders but your technical resources as well.  When preparing a presentation to management or your project team, anticipate questions you will get and be prepared to answer them.  Have adequate examples and models prepared to demonstrate an idea or concept.

When issues or risks arise, identify and communicate them early.  Possibly prepare an action or risk mitigation plan for it.  Don’t allow tasks to slip so far behind that it affects the project schedule and is noticeable by everyone, communicate roadblocks and other commitments, so team members understand the conflicts and pressures. In this way they understand that slippage isn’t because you are lazy; communicate the situation.

Take responsibility for action items and tasks quickly; ask for them, don’t wait for them to be assigned to you.

Be Authentic

Being authentic is simply being yourself.  Be sincere, speak from the heart, be respectful and be empathetic. Don’t mix your words in a cloud of ambiguity; say what you mean and mean what you say. Take the time to build relationships with your team members and stakeholders.  Be interested in their situation and ideas.  Understand their perspective, motivations and attitudes.  If you are not truly interested in their perspective, motivations and ideas; then don’t pretend that you are.  However, you will find how much harder it is to work as a business analyst when you don’t understand your stakeholders.

If you are able to master these skills and competencies, you will gain the trust and respect of your stakeholders.  Remember, that it takes much longer to regain respect and trust once destroyed then it does to earn it in the first place.  So take the easy road and earn that trust from the first encounter with every stakeholder and work vigorously to keep that trust.  Respect each stakeholder’s role in the project and organization, show your capabilities and you will earn their trust.

If you would like some additional reading on this topic, I suggest you take a look at:

  • The 7 Habits of Highly Effective People: Powerful Lessons in Personal Change by Stephen R. Covey (2013)
  • The Influencing Formula: How to Become a Trusted Advisor and Influence Without Authority by Elizabeth Larson and Richard Larson of Watermark Learning (2012)
  • The Speed of Trust: The One Thing that Changes Everything by Stephen M. R. Covey (2008)
  • Influence Without Authority by Allan R. Cohen  and David L. Bradford (2005)
  • The Trusted Advisor by David Maister, Charles Green and Robert Galford (2001)

Self-Directed, Self-Organized… Really?

One of the core ideas or principles of Agile teams is this notion of a self-directed, self-managed, and self-organized team. 

In my experience, it’s one of the hardest things to get right in your coaching and team evolution efforts. 

Often I see two extremes, either:

The teams use the self-organization, self-directed mantra as a means of having no accountability. It’s essentially the “inmates running the asylum” and they can choose to do whatever they wish, whenever they wish under the banner of – “don’t bother us…we’re being Agile”.

Or the other extreme is that:

The management team says that they’re empowering their self-directed teams, but when you look at their behavior, they’re doing what they’ve always done…tell folks what to do.

People also seem to like being told what to do; being micro-managed

Self-directed teams are teams that, once given a mission or goal, are expected to sort out the challenges and deliver. 

While this is a central notion, in my experience, it’s hard to get individuals and teams to take this on. I’m not quite sure why, because it’s really such a compelling premise. That is (You) own your own destiny (Results) so figure things out.

Instead of folks embracing it, I often see them fighting it. Is it a lack of practice in decision-making? Is it a fear of accountability? Is it a fear of failure? 

I’m not quite sure, but it could be aspects of all three and much more.

It seems that many of us have become comfortable complaining about things and “pointing upward” to “them” as being the problem. Point being, many individuals have become comfortable with being told what to do. With the accountability residing with their managers and they simply are – doing as they’re told. However, if Agile is done well, then “they” becomes “us”, which can be particularly scary.

On the flip side of this, when I do see individuals and teams embrace self-direction, then it’s a “magical” thing. There is a shared accountability between the leadership team and the teams doing the work. It’s balanced and effective, with each one supporting and trusting the other. 

But this balance can often be quite difficult to achieve.


{module ad 300×100 Large mobile}


What the Scrum Guide has to say…

Next let’s review what the Scrum Guide says related to the overall Scrum Team:

The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team. The team model in Scrum is designed to optimize flexibility, creativity, and productivity. 

And then it goes on to say the following about the Development Team:

The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint. Only members of the Development Team create the Increment. 
Development Teams are structured and empowered by the organization to organize and manage their own work. The resulting synergy optimizes the Development Team’s overall efficiency and effectiveness. 
Development Teams have the following characteristics: 

  • They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;
  • Development Teams are cross-functional, with all of the skills as a team necessary to create a product Increment; 
    • Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule; 
    • Scrum recognizes no sub-teams in the Development Team, regardless of particular domains 
that need to be addressed like testing or business analysis; there are no exceptions to this 
rule; and, 
    • Individual Development Team members may have specialized skills and areas of focus, but 
accountability belongs to the Development Team as a whole. 

In this case the Scrum Guide is focusing the term self-organizing towards how the team decides to attack the work they’ve been asked to perform via the backlog. Schwaber and Sutherland seem to go to great lengths to emphasize the team owning and deciding work strategy. They also emphasize a blending of roles to the point where they are near meaningless. The key points seem to be: team, teamwork, delivery of a product increment and accountability.

What Esther Derby has to say…

In 2011, Esther Derby wrote a really nice article that tried to address some misconceptions related to self-directed teams. The three misconceptions she highlighted were:

1.Self-organizing teams are completely autonomous, self-managing, and don’t need managers.

2.All you need to do to form a self-organizing team is provide a goal and apply pressure.

3.Since the team is self-organizing, they can accommodate moving people on and off the team easily.

http://www.estherderby.com/2011/07/misconceptions-about-self-organizing-teams-2.html

There is an overall misconception that Esther discusses surrounding the relationship, role or ‘dance’ between the self-organizing team and the leadership structure within the organization sometimes referred to as (‘management’). 

In most cases, there isn’t a whole lot of guidance coming from the Agile community around managing/leading agile teams. And usually what does come out emphasizes the team over management. What I mean by that is that management is basically told to “leave the team alone” or “go and handle a few impediments” as their primary role.

I really like the balanced (and necessary) role that Esther describes. 

Constraints? Or do the inmates indeed run the asylum?

There seem to be two schools of thought when it comes to applying constraints to Agile teams. One is that they’re inherently bad; that they undermine the empowerment and accountability of the teams. 

I sometimes see this in coaching colleagues who use terms like:

  • Agile Purism;
  • Un-Agile, Un-Lean;
  • Arbitrary or Dogmatic;
  • Prescriptive or Prescription.

To describe anything that “forces” the team to do something against their will. Literally they want the team to be unencumbered in their journey without literally any constraints. 

Unless you’re working in your own company, or for a non-profit perhaps, I’ve never encountered a job (yes, Agile team members usually work) with a total lack of constraints. Usually there are quite a few, for example:

  • quality constraints;
  • appropriate working conditions (language, dress, hours, etc.)
  • business & financial constraints;
  • agile constraints – Definition of Done, agile approaches used, tooling, etc.
  • legal constraints.

But at the same time as we’re applying constraints, we need to be careful that they’re not too oppressive – that they leave some room for the team to make their own rules and their own decisions.

Definition of Done

I’ll use Definition of Done as an example. I believe teams need to have a deep and broad definition of done. I wrote about what that means here and here. But at the same time, I usually encourage teams to “extend” their DoD with team-based agreements and to make it “their own”. 

I encourage the same thing to happen when the team is making other operational agreements amongst themselves. 

How do we “Create” these teams?

I don’t think you do. I think the leadership team has a responsibility to create a fertile space for these sorts of teams to form, become established, and grow. 

Aspects of which include:

  1. Staffing the team with the skills required to deliver on their backlog;
  2. Trying to avoid part-time team members at all costs; if you do have some, limit them and clearly define their “capacity” within the team;
  3. If you’re doing Scrum, have a dedicated Product Owner and Scrum Master. Make sure they have the experience, time, and focus to do the job well;
  4. Respect the autonomy of the team and trust them to deliver in your stated goals and directives;
  5. And engage in all aspects of the agile ceremonies so that you leverage the transparency and real-time adjustment nature of the methods.

And the team has self-direction responsibilities as well. For example:

  1. Holding each other accountable to professional ethics and standards;
  2. Having congruent discussions in retrospectives guiding the team towards continuous improvement;
  3. Having the courage to push back as appropriate on traditional leadership that might be pushing the team too hard or in the wrong direction;
  4. Holding quality dear within the team, not only from a Definition of Done perspective, but with solid professional attitudes and practices;
  5. An overall responsibility to respectfully work together (swarming around the work) and avoiding Scrummerfall behaviors – delivering as much high-quality and high-value software as possible.

Wrapping up

I’m quite curious as to how readers might react to this article. What are your experiences in achieving self-direction in your Agile adventures? Is it easy or hard? And have you seen team resistance to the notion?

Have you discovered anything worth sharing about how to achieve this level of organizational balance? I’d be very interested in hearing about it.

And is it something, that once you’ve achieved it, it sticks? Or do you have to continuously work on your self-direction, autonomy, and self-organization?

Stay agile my friends,

Bob.

A few nice references

http://blogs.agilefaqs.com/2014/10/29/self-organised-vs-self-managed-vs-self-directed-whats-the-difference/

http://www.infoq.com/articles/what-are-self-organising-teams

https://mikemacd.wordpress.com/2012/05/01/what-does-a-self-organising-team-really-mean-organisation/ http://www.growingagile.co.za/2012/11/self-organising-teams/

The Silver Bullet Syndrome

Over the past several years I have heard an increasing number of complaints from a large number of Agile adherents accusing organizational management of expecting Agile to be a silver bullet (usually stated as “the next silver bullet” although I am not sure what other “silver bullet” Agile is replacing).

These accusations usually occur when there are problems with Agile or the approach does not work as advertised and organizational management pulls the plug or reverts to more traditional software development or management approaches. These complaints are not unique to the Agile community, although they do seem to be somewhat IT related in general. Hearing them got me to thinking about the whole concept of the silver bullet, the results of which follow.

We in IT are fond of condemning management of organizations for continually looking for “The Silver Bullet”. There is certainly some evidence to support IT’s contention that management expects a “magical” solution to business problems. We can cite many instances of technologies or approaches in IT that rose to preeminence and then were cast aside as not having The One Answer:  Business Process Re-engineering comes to mind as an example.

Perhaps we feel we in IT have a greater insight into how things work since Fred Brooks paper was published back in 1986  titled “No Silver Bullet – Essence and Accidents of Software Engineering.” And to a large degree, technology, headed by computer technology, has been the victim of “the next great thing” for decades. Since we in IT are the ones producing “the next great thing” perhaps, like Pogo, “we are the Silver Bullet that we complain about”. [1]

The Evolution of the Silver Bullet

For those not aware of the legend of the silver bullet, in folklore a silver bullet fired from a gun is the only way to kill a werewolf. (Note that the silver bullet was also used by the fictional Western character, The Lone Ranger, as a calling card and a symbol of law and order. We are not referring to that particular use of silver bullet in IT.) Initially, in common parlance, a “silver bullet” referred to the only successful solution to a given problem or situation (to kill a werewolf for example). It was a positive concept. I can remember management meetings in which someone would say, “well, that looks like our silver bullet to resolve the issue.” And it was.

Since Brooks’ article, “silver bullet” has become a pejorative term usually applied to management with the emphasis on the fictional aspect of the concept: there are no werewolves, and, therefore, no “magic” silver bullets to kill them. In other words, there is no single approach or technology that will solve a complicated business problem.

Deus ex Machina

Perhaps we in IT might be better served by using the term Deus ex Machina rather than silver bullet. The Deus ex Machina, Greek for “god from the machine”, was a device used by playwrights, and others, to get the hero or protagonist out of an impossible situation by means of some unexpected, and marginally believable, power or event that occurs to save the day. Usually, in Greek plays it was portrayed as some god arriving in a chariot when things were darkest for the heroes (the monster was about to devour them, or the enemy wipe them out) to set things right and to save the day.

Deus ex Machina might be a better analogy for the single magical solution that management would like to see to solve its business problem: A new product, or technology, or approach that would get them out of whatever difficulty they are in, and most likely got into by their own actions, or lack thereof.

However, Deus ex Machina is hard to say and is not quite that familiar. After all, Greek drama is not a common course for MBAs, not to mention IT curricula. So it looks like we will have to live with the term “silver bullet”.

There is a Silver Bullet

The logical binary oriented computer and IT people declaim management’s persistent belief in and search for the silver bullet. IT people, especially in software development, and more especially in the Agile approaches, state categorically that there is no silver bullet. This may be a valid, logical conclusion, at least in IT, but it flies in the face of human nature.

We might recall as children getting ourselves into an untenable situation or simply being the victim of circumstances of which we could not get out. The situation seemed hopeless, at least to us. Then our parents or teachers or some other adult produced a solution to the problem, sometimes with money, sometimes with an action they took, and sometimes with some simple adult advice and counsel. Whatever was done, a single solution evaporated the unsolvable problem. And this is the way it is supposed to be. Children trip and fall and the adult gets rid of the pain and comforts the injured so the child can get up and run again. Children try something new that does not work in the adult steps and to make it right. In other words we are used to “silver bullets” even though as we look back as adults on those events, we realize they are simply adult solutions to problems that we as children could not determine. Still, as children filled with a sense of relief that the problem is solved, we would call them “Silver Bullets” if such a phrase were in our vocabulary.

Being so used to “adult intervention” is it any wonder that we humans believe in silver bullets?

Romance and Comedy

Hollywood contributes to our continuing belief in the silver bullet. In romantic movie after comedic movie, the lead character gets something (love of their life, money, etc.), the lead character loses it, and then by some magical happenstance, the lead character gets it back (usually along with some insights) in the third act, and everyone lives happily ever after. Centuries of books, plays, operas, and nearly a century of movies (not to mention television and now Internet shows) have conditioned us to expect some kind of silver bullet to make everything right by the final credits. Regardless of how implausible, Andy Hardy puts on a show to save the orphanage. Cars line up for miles waiting to pay money to visit the Field of Dreams and save the farm from foreclosure. King Richard returns just in time to save Robin Hood from the forces of King John. The real criminal confesses to save the innocent man’s execution just before midnight. And so forth.

Our popular culture continues to reinforce the belief that somehow, someone or something will come along and save the day. More silver bullets.

The 24 Effect

In the very popular television series 24, the lead character, Jack Bauer, played by Kiefer Sutherland, had two often repeated phrases. The first, “dammit”, spawned a college drinking game. The second phrase, repeated in nearly every episode, shows how ingrained the concept of the silver bullet is in our culture. The phrase is “this is the only way”, usually stated after another character recites a laundry list of risks, such as death to Mr. Bauer.  Not only is Jack Bauer stating a single solution that will magically solve the problem (the problem of that 15-minute segment anyway) but the solution generally, in fact, works. And we believe it, or at least we suspend our disbelief.

As humans, we want to believe that there is a solution, even a “magical” solution that will get us out of our most dire situations.

This is called hope. And hope is not a bad thing.

And who knows? Maybe there are silver bullets. After all, someone has to win the lottery.

Silver Bullet Expectations

There are two primary reasons that Business Analysts have to be aware of the natural occurrence of the belief in silver bullets. We might call this the “Silver Bullet Bias.”

The first is one of expectations. This is the primary reason behind the negative connotation to the phrase “silver bullet”. If management assumes that a solution, for example an Agile approach, is a silver bullet, management will assume that the problem will be completely solved with no other action necessary.

Part of the reason for the Silver Bullet Bias is those who are proponents of the approach, the zealots or true believers.  There has been a lot of hype about Agile, for example, especially from the Agile advocates themselves. Agile, a software development philosophy or mindset, has been pushed to the corporate level far removed from the developers who signed the Agile Manifesto with promises that if the organization is Agile, great things will happen in software development and elsewhere (sales, marketing, customer service, etc.)  There is no mention of the work necessary and one of the underlying principles of Agile, which is that failure is necessary for success. Based on the concept that management is made up of human beings (although there are those in IT who doubt that concept), management will naturally jump at the possibility of a silver bullet.  We have only ourselves to blame for their expectations.

Expectations can be managed. Identifying the risks involved with the proposed solution, the shortcomings of the solution, and the aspects of the problem that may not be solved by this “silver bullet” solution will put the “silver bullet” in its proper context. Sometimes placing a potential solution in a realistic scenario including risks, impacts and limitations might force management to look for other solutions, which is never a bad thing, time permitting, and in many cases, the constraints of time tend to be artificial.

No Other Way

The second issue is more insidious. If management or anyone assumes a silver bullet approach, they will not consider any other options, and have a tendency to overlook the risks, similar to the 24 effect. If the solution is the “only way”, then there is no need to do risk analysis for the purpose of determining the alternative with the least risk, much less come up with another alternative. And this can be disastrous. 

The last thing a Business Analyst wants to hear about a failed solution is “we didn’t consider…” I’m not talking hindsight bias where the phrase is “If only we had known this would happen”.  I’m suggesting that additional information or analysis was stopped, prevented, because a silver bullet appeared and became “the only way.”  As Courtney Turk says in The Secret Diary of Ashley Juergens, or as Dr. Mouhamed Tarazi titles his book:  “There is always another way.” Or as Sherlock Holmes would say, “It’s a capital crime to theorize before you have all the evidence. It biases the judgment.”

The silver bullet is sometimes another way of jumping to solutions, or worse, ignoring or discounting any other possible solution (confirmation bias).

“No Silver Bullet” is a Silver Bullet

And, finally, the Silver Bullet Bias can be used as an excuse. It’s easy to say management is wrong because they want a silver bullet, and expect every solution to be a silver bullet and that’s why didn’t work. 

“Management expected Agile to be a silver bullet, so they pulled the plug on it when it didn’t solve all their problems.”  This is a convenient excuse, and it may hide the real reasons for the failure. Perhaps expectations were not set at the right level. Perhaps the approach was not correctly implemented. Perhaps the implementers tried to shoehorn the organization into a standard approach when customization, while more difficult, was called for. It’s easy to blame things that don’t go your way in business as a negative attitude on the part of management. The harder thing to do is to evaluate and assess and come back with a plan to do it right the next time (or at least to do it “righter”).

What can the Business Analyst do about it?

We recognize that all of us want, and to a degree believe in a silver bullet, to rescue us from whatever difficulties we are in.  While we cannot eliminate silver bullet thinking, we can address the issues of Silver Bullet Bias in business.

Considering the aspect of the “one and only” solution, the Business Analyst will offer multiple solutions to any business problem – or for that matter, any problem at all. The solutions do not have to be mutually exclusive nor realistic. In other words, one solution might be too expensive, and another realistic but improbable.  Solutions might be variations on the same theme. But they will be separately identifiable solutions to the problem.  Faced with options to solve the problem, management will likely recognize that the Silver Bullet solution is not the only way to go, and be forced into evaluating alternatives to come up with the best viable approach.

The Business Analyst can throw a little tarnish on the silver bullet showing that the solution may not provide all the answers or relief. The Business Analyst provides measurements and metrics pinpointing where the solution may fall short, and how management can determine that the solution is viable (or not). In this way, the “magic” of the silver bullet solution starts being replaced by situational reality. Management can begin to see behind the curtain.  Remember that even when the magic of the Wizard of Oz was shown to be fraud, the Wizard still satisfied everyone’s goals for going to Oz: a heart for the Tin Woodman, brain for the Scarecrow, courage for the Lion, and Kansas for Dorothy. The reality is that goals and solutions can be achieved without the silver bullet.

And, who knows, maybe the Business Analyst will show that the solution was, in fact, a silver bullet.

[1] The comic strip, “Pogo”, scripted by the late Walt Kelly (1913 – 1973) produced many quotes, among which, the most famous is “We have met the enemy, and he is us.”

Facebook using Business Analysis and Improvisation

There are two things I really love.  One is business analysis, and the other is improvisation (improv). Even more so, is applied improv. Applied improv is the concept of applying improvisation skills to other things besides acting. I focus on helping others apply improv skills and business analysis in a business environment.

So, when I read this article via Business Insider, How Facebook’s design team organizes its critique meetings so nobody gets offended and everyone has clear goals, I loved how they talked about business analysis and improv in one article. I thought they wrote this for me. Or maybe their Product Designer, Tanner Christensen, is my long lost twin.

Here is the catch, though. They never mentioned business analysis or improv in the article. Not once.  Regardless, you can recognize it if you read between the lines.  This phenomenon is a big issue in the business analysis space.  I believe that business analysis is happening everywhere in organizations, and no one even knows it.  We are also always improvising. When is the last time you had a conversation with someone and you used scripts?! Articles like this prove it. 

In our book, Business Analysis for Dummies, Kate McGoey, Paul Mulvey, and I wrote a chapter about business analysis happening at all levels of an organization. We mention there is analysis at the enterprise level, organizational level, operational level, and project level. With books like ours, other experts in the field writing and speaking about this, and even some companies realizing it, the majority of people and organizations either don’t understand the value of analysis or see the value only at the project level. 

To help break the trend of some not seeing business analysis happening at all levels, I will break down two key points in the article about Facebook. The article is covering Mr. Christensen’s design critique process his teams use to yield positive, useful information to create or improve products.  

1)      Business Analysis: The first step in their process is to make sure everyone understands and agrees to the problem that is trying to be addressed. At its heart, this is business analysis. If teams do not have a shared understanding of the problem or goal that is trying to be achieved, then the chance of success is limited. 

The best business analysis professionals around the world do this day in and day out. Even if a solution is handed to them, they work to understand the problem that the solution is trying to solve. They use tools like the problem statement, impact mapping, etc. to draw out the problem and communicate it in a way that it is clear and visible to the team. In creative ways, they are asking the “5 Whys.” Since asking why can put people on the defense you can ask, “What does success look like” or “What will be different after we implement this solution?”

2)      Improv: For the team members critiquing the proposed design for a product there is a general rule they should follow. In the article it is written, “To make a critique valuable to a presenter, it is advisable to begin with a positive note on something you liked about the solution and to pose your thoughts as questions. Doing so will encourage him/her to offer reasonings instead of being defensive.” I almost jumped out of my seat when I read that. It was music to my ears.

When I work with individuals and teams, I stress the need for having positive conversations.  One way to do that is by having the “Yes, and” mindset. The mother of all rules in improv is never deny. Since there are no scripts used when you are performing improv denying just kills scenes. In improv if someone walks into a scene and exclaims “Wow, I love that you colored your hair yellow,” you never say “it’s not yellow.” That denial instantly puts the burden back on the other actor to come up with something else. If you deny like that on stage too often, the other actors won’t want to work with you anymore.  The same applies to the work you do.  If someone proposes something and you consistently deny them using words like “that idea is terrible” or “yeah, but I have a better idea” your co-workers won’t want to work with you much longer. And, no value is gained. 

Improv actors practice the art of never denying by playing a game called “Yes, and.” One version of the game goes something like this. A topic is given, and one actor starts off with a sentence. The next actor says “Yes, and…” then adds to the conversation. Then is goes back and forth.  The feeling is very positive and rewarding as you keep adding things and supporting your partner. And crazy ideas come out of those conversations.  Try it!

When I am teaching this to business professionals the conversation around not agreeing with someone always comes up. In real life, you can’t just keep saying “yes, and…” Absolutely, you need to critique without putting others on the defensive.

The advice I give is exactly what Mr. Christensen gives to his team. One idea is saying, “What I like about that is…” You need to have the mindset of finding something good in other people’s ideas. The other piece of advice I share is to ask a question. Sometimes the ideas people have are viewed to you as crazy, wild, unimaginable, or maybe you know things like that have failed before. So instead of saying, “yeah, but that idea is crazy, what about this.” Ask, “Help me understand how that idea gets us closer to solving our problem. I just don’t see the connection yet.” Two things can happen there. One is the person may realize that their idea is crazy and does not work for this problem or two, they convince you the idea is good and will work.  Either way, both parties have a positive conversation rather than an adversarial one. 

One way to help others understand that business analysis (and improv) is happening everywhere is for us to highlight it when you see it.  Read between the lines, keep your eyes open.  When you see good business analysis and improv happening tell the people around you what is really happening.

All the best,

Kupe