The Three Things Agilists Can Learn From Wonder Woman

Paradise Island

Superhero stories are the parables of our time and that’s why even mere mortal Agilists can learn some lessons from these crusaders. Don’t worry if you don’t have a tiara or a lasso of truth; there are still plenty of things you can learn from Wonder Woman.

Let’s set the stage–Diana Prince, Wonder Woman, lives in Themyscira on the Paradise Islands among the Amazons. The Amazons are warriors who spend most of their time training and consider themselves the most elite fighters in the world. The Paradise Islands are living up to their name until one day, the German army arrives. Which shouldn’t be a problem, right? These are the most elite warriors in the world. But unfortunately, that doesn’t end up being the case.

The Germans have guns and the Amazonian archers aren’t equipped to handle that tech. Eventually the Amazons do win, but it takes a literal heroic effort from an actual superhero to help them make it through this battle.

Get Off the Island

The first agile lesson we can learn from this scene is to get off the island. As lovely as that island is or maybe your comfort zone is– don’t isolate yourself. As an Agilist, make sure you’re working within your community and going to local meetups. Being involved can help you stay relevant and frankly more Agile.

When the Germans begin firing their weapons, you can see the bewilderment on the faces of the Amazons. Don’t be like the Wonder Woman here; make sure you’re getting out there and seeing what is new. It will keep you from watching the bullet fly right by your face. You don’t want the first time you’re seeing a piece of technology to be when it’s already starting to overtake you.

Make Sure Your Goals Are Clear as a Team

Were the Amazons really trying to be the best warriors in the world or the just the best archers? It seems if they had aligned their goals they might have been better prepared for this unexpected attack. When you’re working with your teams think about what your end goal truly is. Make sure you align everyone with what you are trying to do and make sure you know what you’re striving for.

Don’t Let Superhero Syndrome Mask Your Deficiencies

Everyone has probably been a part of a project where you witnessed the superhero mentality. This is when someone comes in and pulls all kinds of crazy hours to save a project last a minute. As Agilists, we want to make sure that even if we do get saved by a superhero that it doesn’t stop us from continuously improving. After this battle, do you think the Amazons actually learned about this new technology and leveraged it in their future battles? I’m not sure, but I do know that if you stop learning and improving as you go along it’s easy to be left behind.


What’s New in SAFe 4.5?

SAFe version 4.5 was released on 6/21, and I’ve been excited to dig in and see the changes.  Check out the official site for more details on change.  Here are some of the changes I’m most excited to see.

Making SAFe Easier to Handle

Big Picture Scaling

The SAFe 4.0 Big Picture can be overwhelming, especially when expanding to 4 levels.  SAFe has made 4 different views of the Big Picture that limit the focus of the model, depending on the organization’s need.

Part of this change gives better guidance to organizations on how to adopt subsets of the full Big Picture.  With this change, SAFe has adopted some of the lean agile mindset to the process of adopting SAFe – start with an MVP, and build Features on top of that as needed.

Implementation Roadmap

This isn’t 100% new in 4.5 – the implantation roadmap did exist in 4.0 as well. However, the Roadmap has replaced the implementing 123 article on the Big Picture.

SAFe has recognized that there’s more to implementing a successful SAFe environment than simply training all the relevant people involved.

There’s a specific emphasis in the new roadmap on identifying Value Streams and creating ARTs within the Value Streams – a hugely important factor to get right up front.  ARTs aren’t particularly helpful if they aren’t properly aligned with a value stream.  Either you have multiple value streams within an ART, which weakens the power of an ART, and creates a divide.  Or you could have an ART where the value stream actually cuts across multiple portfolios, which creates a huge mess.  Getting this right up front saves a huge amount of time and frustration for the teams and programs, so it’s great that SAFe has baked this into the implementation guidelines.

Lean Startup Mentality

SAFe has explicitely and heavily incorporated the lean startup idea into the model.  There is a newly placed emphasis on incorporating the “Build-measure-learn” lean startup cycle (which SAFe has expanded to “Hypothesize-build-measure-learn”) into all levels.  This has caused a number of small and larger changes to the model.

Lean Startup Cycle

This is one of my personal favorite changes to the SAFe model.  SAFe has tied the lean startup model directly across the Portfolio and Program layer.  This emphasizes one of the underlying principles of Agile – build lean, release, and only build more features if the MVP is worth building upon.

It also clarifies that work continues on the MVP until the tradeoffs suggest working on something else more valuable.

Continuous Delivery Pipeline and Dev Ops

SAFe has recognized that to release lots of MVPs, you need to have the Continuous Delivery Pipeline and Dev Ops to support it.   SAFe explicitly calls out both of these on the big picture to emphasize the importance.

Other Goodies


SAFe has added an Agile version of Compliance to the Big Picture.  Compliance often lives in a Waterfall world, clashing with IT efforts to run Agile.

This is a great first step, and I hope that SAFe will look into other regulations that large enterprises face that often run in Waterfall, such as legal reviews.

SAFe Program Consultant (SPC)

The SPC has been added to the Big Picture.  SAFe is recognizing the need for additional help beyond the existing roles to help stand up and perpetuate a successful SAFe implementation.

I would encourage organizations to be careful about falling into the “Certification Trap.”  While a few of the training activities require an SPC to deliver, the majority of the SPC responsibilities can be executed by an experienced non-SPC coach.

SAFe 4.5 – A Leaner, More Experiment Heavy SAFe

The two major themes in SAFe 4.5 are an emphasis on experimentation through the Lean Startup Mentality and creating new tools that make SAFe itself scalable depending on the size and needs of the organization.  SAFe has leaned itself down as small as the Essential SAFe level.

Organizations that are considering SAFe can now combine these two mentalities in their adoption of SAFe.  They can start small and lean with an MVP of Essential SAFe, and evaluate the experiment.  If it works well, they can add new features to a larger version of SAFe, or abandon the experiment entirely.

With SAFe 4.5, I hope that organizations are now able to take these lean, experimental ideas not just into their software development, but also into their own adoption or expansion of SAFe.

Shifting Gears – Why and How to Shift your Team-Level Culture During your SAFe Innovation and Planning Iteration


SAFe is…well…safe

Traditionally, Iterations in a SAFe Program Increment are dedicated to delivering on User Stories and Features.  The ideal team is stable and has good, broken down work that allows for consistent delivery Iteration after Iteration.  The last thing any Scrum Master wants to see is a Velocity chart that looks more like a seismograph.

When teams get to consistent User Story delivery, the hope is that they can deliver Features consistently over the course of a PI. When talking about nailing the basics, one of the first things mentioned is meeting commitments on a regular basis.

In order to set up teams for consistent delivery, a conservative culture often develops in SAFe environments (and I’m not the only one to observe this).  SAFe encourage User Stories and Features that are well-defined, well-understood, and have minimal uncertainty.  Teams make sure their User Stories and Features are as refined as possible before committing to them in a PI or Iteration.

Conservative Culture Doesn’t Promote Innovation – and SAFe Knows This

This conservative Culture isn’t necessarily a bad thing.  Remember, it’s stemming from the lofty goal of consistent delivery.  However, it’s important to recognize that this Culture is not conducive to innovation.

The flip-side of encouraging consistent delivery is that risk taking is inherently discouraged. Anything inherently risky or uncertain is encouraged to be better refined.  This gives us predictable delivery, but how innovative can our delivery be if we’re not taking any risks?

SAFe explicitly recognizes that innovation may not really be possible during normal delivery Iteration by saying “finding time for free association and innovation in the midst of delivery deadlines can be difficult.” And they put their money where their mouth is by building in time in the PI to dedicate to innovation.

If We Really Want Innovative I/P Iterations, We Need to Deliberately Shift Culture

After 10+ weeks of conservative, consistent delivery, what are the odds that people will naturally shift into a mindset of innovation for 2 weeks?  As Agile leaders, we need to be deliberate to shift our Culture during the Innovation Iteration; otherwise, there’s a serious risk that the conservative Culture of the normal delivery cycle will bleed into the Innovation sprint.

How Can We Shift to Promote an Innovative Culture for Just One Iteration?


Hackathons are a common way of leveraging the Innovation Iteration to encourage novel thinking in a fun environment.  I recommend any hackathons leverage the SAFe encouragement for them to be free-form – allowing team members to work on whatever they want with whomever they want.  This is a clear shift in Culture from the hyper-organized environment during delivery sprints.

Make Time to Celebrate Failures in the Hackathon

There’s evidence that embracing failures helps encourage innovation.  If failure is actively discouraged, what incentive is there to stick out with an innovative idea if you’re likely to get hammered back down?

Take time to reflect what is being celebrated in your ART’s hackathon.  I worked with a client who celebrated the most successfully executed Hackathon deliverables, which was a great idea and added to the fun of the hackathon.  But what incentive is there to risk a truly innovative idea if only the successes are celebrated?

I encouraged the client to not just celebrate the successes, but also the failures.  We want to encourage Hackathon teams to dream big and try to build something that may not pan out.  We even implemented a “shoot for the moon” award – based on the phrase “shoot for the moon, even if you miss, you’ll land among the stars” – as a way of celebrating a Hackathon team that dreamed big, but didn’t quite hit their mark.  What a way to truly shift culture for your Hackathon Iteration by actively rewarding failed ideas. Could you imagine something like that in a traditional SAFe PI?

Culture Doesn’t Just Eat Process for Breakfast – Culture Is Breakfast


“A brittle Culture can doom even a great organization.” – Curt Cuffman

Breakfast is the Most Important Meal of the Day


It’s said that breakfast is the most important meal of the day.  But why is that?  Breakfast kick starts your day – you want to embark on your day with a healthy, nutritious meal that sets your day up for success. I know from experience that coffee for breakfast seems like a great idea for about an hour, but when the caffeine boost wears off, the rest of the day becomes a drag.


When thinking about implementing Agile, we want to start by thinking about what we’re having for breakfast – what will start our Agile transformation with the sustaining energy to propel the transformation in the right direction?



The 4 Pillars of Agile

There are 4 major pillars of Agile: Culture, People, Process and Tools.  These are the key tenants for an Agile transformation that are so important, I’ll be capitalizing them throughout this blog.  When starting an Agile transformation, we should start by thinking about these pillars.


Culture consists of all the intangibles that answer the question: “How do things get done around here?” Culture shapes the environment and ecosystems that will, or already exist, within organizations that drive behavior, feelings, and output.


Agile People are the essence of an organization. People will either thrive or diminish within an organization’s culture. When staffing, whether a team or a whole organization, it’s critical to think through the strengths, attributes, and skills needed for People to be successful.


Processes outline how People will take ideas from discovery through fruition. Processes should assist with the journey from Point A to Point B. It’s important to remember that Agile Processes are meant to be light weight, allowing People the flexibility needed to be successful.


Tools should be implemented to support efficiency and sustainability within a process. Before implementation, tools should be assessed to confirm compatibility with a process. Agile-specific tools incorporate fundamental attributes of Agile processes to ensure synergy.

Drawbacks of Skipping Breakfast

If we know coffee won’t get us through the day, why would we skip a healthy, nutritious breakfast?


When beginning an Agile transformation, there are serious drawbacks to focusing on other Agile pillars besides Culture.


Drawbacks of Tools

If we start our Agile transformation by selecting Tools, we run the risk of picking a set of capabilities that are misaligned to our organizations process(es). If we bring a football to a tennis match, we probably won’t have a successful tennis match. Perhaps we shouldn’t have skipped breakfast?


Drawbacks of Process

If we start our Agile transformation by establishing Processes, we run the risk of implementing workflows and techniques that render our People useless, preventing our organization from achieving its desired outcomes. If we guarantee 24 hour turnaround, then it would be ill-advised to implement an approval process that takes 72 hours to complete.


Drawbacks of People

If we start our Agile transformation by assessing People, we run the risk of hiring and aligning talent that won’t thrive within our organization’s desired Agile Culture. If we’re building a salt-water fish tank, we probably shouldn’t put fresh-water fish in the tank.



Culture is Breakfast


We want to make Culture our Agile breakfast – the first thing we focus on to set the rest of our journey on the right path.  Defining what your organization wants to achieve and how you’ll go about achieving it is a critical step that many organizations completely overlook.  Yet if an organization is going to have success in their Agile transformation, they should answer this question first: “How do things get done around here?”


It seems like such a simple question to answer, but pause, and try to answer that for yourself.  Can you answer that question or these follow-up questions?

  • Do you really understand how things get done? And why you do them?
  • Do you have core values that are embedded into daily activities and drive quality in work and People?
  • Is the mission of the organization visible to everyone and does the output of the organization align to that mission?
  • Has the power been given to the people to self-direct and manage?
  • Do you look around and say, “this is a thriving business?”

Focus on Culture – The Time is Now

Regardless of where you’re at within your Agile transformation, or if you haven’t even started the journey, it’s time to shift the focus to Culture. Culture truly is breakfast – it is the foundation that drives successful Agile transformations. Culture will drive the strategic direction that should align with the desired outcome of the organization.


Having a solid base of Culture will create a solid foundation to support the other 3 Agile pillars.  A thriving Culture will promote hiring of People who are aligned to what you’re trying to achieve.  A successful Culture promotes better Processes that assist and guide your People toward desired outcomes. Finally, Culture will guide your organization to the correct Tools with the right capabilities needed to support Processes, further setting your People up for success.

How to Promote a Thriving Culture

Hopefully you’re now convinced that Culture is the bedrock of successful Agile organizations.  This post will be updated with links to future blogs written by myself or my co-author Elisabeth White on promoting culture.

This article was also posted on my company’s site.

About the Authors

Elisabeth White

Elisabeth White is native to Colorado with over 10 years of global experience supporting and guiding organizations through incredible Agile transformations. Her coaching approach is industry and department agnostic – focusing on continuous improvements within Culture, People, Process, and Tools.  Elisabeth is an Agile Transformation Lead at CapTech Consulting. She serves as the National Site Lead for CapTech’s Agile Service Offering. She is saving the world, one Agile transformation at a time!

Will Fehringer

Will Fehringer is a Senior Consultant in our Richmond, VA office and has over 4 years of consulting experience, working with clients in government, banking, and consumer packaged goods industries to deliver Lean, Agile, customer-driven solutions. Will has a passion for working with team and program levels to help bridge the gap between business and technology.


Agile Estimation Woes – Is your Team Imprecise or Inaccurate?


Uncertainty Isn’t Necessarily a Problem

When I work with Agile teams that are struggling to meet their sprint commitments, they often blame the fact that there’s too much uncertainty with their stories for them to be able to meet their commitments.  There’s a lot of ways that the team can address this problem – the most direct is to perform further analysis to reduce uncertainty in the story.

However, even if we take story uncertainty as a given (after all, the Agile Manifesto includes that teams should welcome changing requirements, even late in the development), the team should still be able to make their commitments if they are pointing accurately.  The uncertainty will reduce precision, but if the team is accurate, they should still have a good chance of completing their committed stories.

Accuracy vs. Precision

Accuracy refers to how close a measured value is to the known value [1].  For story estimation, we’ll refer to accuracy as how close a story estimate is to the true size of the story, as determined after the work has been completed.

Precision, on the other hand, simply refers to how close multiple measurements are to each other [1].  A team could be precise if they’re consistently sizing stories as 5 points that end up truly being 8 point stories.

If a team is struggling to meet their commitments, the team may have been precise, but not accurate. Likely, the team is consistently underestimating the size of the stories, so more of the stories end up being larger than expected.


When uncertainty is high, we want to strive for the team to be accurate, even if they aren’t precise.  If accuracy is high, even if the estimates are wrong, the estimates should be centered around the actual story size.  Thus, some stories will be wildly overestimated, and some stories will wildly underestimated, but these differences will come out in the wash over the course of the sprint, and the team will be able to meet its commitments.


Eventually, our goal is for the team be accurate and precise:


Recalibrating an Inaccurate Team

We’ll focus on recalibrating a team that’s regularly underestimating their story size.  I very rarely encounter a team that’s regularly overestimating – if they are, they typically like to keep that quiet!

Don’t Assume Happy Path

Some teams make the mistake of assuming everything will go perfectly, or nearly perfect.  Most people know about Murphy’s Law, which states where anything that can go wrong will go wrong.  Despite knowing this, teams I’ve worked with tend to be overly optimistic when planning for upcoming sprints, and plan for the happy path, or close to it.  Make sure your team is accounting for the average size of the story, not the best case scenario.

Include Risk

Part of your story sizing should include the risk associated with the story. It’s important for teams and stakeholders to understand that this is different than padding a story.  Padding would lead to a consistent overestimation – including risk just helps to make sure the team is accurate in the face of uncertainty.

Don’t Worry About Being Right – Be Accurate Instead

Teams typically focus on getting each story estimate correct.  After all, if all of the individual stories are estimated correctly, the whole sprint will go smoothly!

This line of thinking works well for mature teams that are successfully getting their estimates correct.  For teams that are struggling to complete a sprint, it can help to remove the focus from each individual story, and focus on being accurate over the course of the sprint.  Even if some stories end up being overestimated and some are underestimated, that’s ok if the entire sprint is successful.

Journey toward Precision

Precision is something that the team will improve on over the course of multiple iterations, but the team needs to be accurate first. Separating out accuracy from precision can help the team focus on a smaller chunk of improvement, which can help the team get over the mental hurdle of the difficulty of making all of their commitments.  Once the team is keeping their Product Owner happy by keeping their commitments, there will be a greater opportunity to focus on precision.



How to Create a Hierarchical Stockroom Structure in ServiceNow

Hub-and-Spoke Stockroom Model Demands Sub-Locations

While working on a ServiceNow IT Asset Management deployment for a Fortune 500 client, we ran into an issue trying to handle stockrooms with sub-locations within the stockroom. Being a large organization, our client uses a hub-and-spoke model for their stockrooms – one central stockroom that supplies assets to a number of local stockrooms.

Due to the size of the central stockroom, it’s imperative to use a hierarchical stockroom structure to increase visibility to the physical location of an asset within the central stockroom. The central stockroom that my team was working with already had an extensive hierarchy of locations. We were assigned with capturing this information on the asset form.

Why Not Use the Location Field?

Our team was wary of using the location field on the asset, due to the way that ServiceNow auto-populates the location field on the asset. Out of the box, ServiceNow will automatically populate the Location field of an in-stock Asset with the Location of the stockroom. Without rewriting the auto-population logic, any changes to the Location field would get overwritten.

Overwriting the auto-population logic would have been difficult to implement, and incurred maintenance costs during upgrades. Also, this was an intrusive change to the system, so we investigated alternatives.

What Not to Do: Stockroom Hierarchy

Our first effort was implementing a hierarchy within the stockroom field. We added a Parent field to the stockroom form, allowing a hierarchy to be created under the top-level stockroom. With this scheme, the stockroom field would be the lowest stockroom in the location hierarchy within the central warehouse. All stockrooms in the hierarchy had the same location for reporting purposes. Unfortunately, there were two major flaws with this approach.

To illustrate the issues, let’s use a simplified central warehouse, called “Hub Stockroom,” which has 2 places to keep inventory. We’ll call them “A” and “B”. Both A and B are stockrooms themselves, and both have the Hub Stockroom as their parent. In this example, we’ll say there’s a laptop in section A:

Hub Stockroom

Stockroom Example

In ServiceNow, this is what the stockroom hierarchy would look like:

In the Hub Stockroom, the laptop asset would have a status of In Stock, and a stockroom of A:

The major problem with implementing a stockroom hierarchy is that two major existing features break due to the laptop being in the “A” Stockroom instead of the “Hub” Stockroom.

Transfer Orders Break

The first way that the stockroom hierarchy breaks the out of box functionality is on transfer orders. In our example, let’s say that we wanted to create a transfer order to move the laptop from the Hub Stockroom to a “Spoke” stockroom. We would create a transfer order to go from Hub Stockroom to the Spoke stockroom. Out of the box, when a Transfer Order is created in ServiceNow, it will filter the assets that you can add to a Transfer Order Line to only show the assets that exist in the From Stockroom, which is usually a good thing. However, in this Stockroom Hierarchy model, the laptop would be in stock in the “A” stockroom, a child stockroom of the Hub Stockroom, so the laptop would not show as an option to be added to a transfer order line.

This leads to two clunky workarounds for members of the Hub Stockroom. They can either set the transfer order to originate from the “A” stockroom, which may be confusing to the stockroom that’s receiving the inventory (What’s the “A” stockroom?) The other workaround is for the members of the Hub Stockroom to go to the laptop asset and manually update the stockroom to the “Hub Stockroom.” This is a feasible solution for this small example, but the extra work adds up quickly, especially for the hub stockroom, which is probably processing dozens of orders a day.

Stock Rules Break

The hierarchical stockroom model also breaks stock rule functionality. In our example from above, let’s say that there is a stock rule that will transfer assets of the model of the laptop that is in the A stockroom to one of the “spoke” stockrooms. If the spoke stockroom is below the threshold, the stock rule will be triggered, and the stock rule will look for assets of that model type in the Hub Stockroom. However, in this example, the laptop asset in in the A stockroom, not the Hub Stockroom. The stock rule will look in the Hub Stockroom, not find any assets, and no transfer orders will be created until the laptop is moved into the Hub Stockroom.

Solution: “Substockrooms”

The solution that worked for us was creating a new field on the asset form called a “substockroom.” This new field has a business rule that only runs when the asset status is In Stock and the Stockroom type is a Central Stockroom. If the field is visible, the user can select a new stockroom to add clarity to the location of the specific asset. In the Hub Stockroom above, the laptop asset would have a Stockroom of “Hub Stockroom”, and the Substockroom field would be A:

Because the stockroom is the Hub Stockroom, the transfer orders and stock rules will work as expected.

Gap Identified: Hierarchical Stockroom Structures

I believe that hierarchical stockroom structuring is a gap that is currently missing from ServiceNow, as there is no obvious way to capture this information without adding new fields to the form. Through trial and error, we determined what we believe is the best way to overcome this issue. Hopefully this method will prove useful until ServiceNow is able to fix this problem.

This article has been cross-posted on my company’s blog here.

ServiceNow Vendor Restocking Notification is Incorrect

We had an issue come up on client-site today about the ServiceNow Vendor Restocking notification.  This is the notification that comes up when Vendor Stock Rules fire.  Our client is using the out-of-box version of the notification.

During testing, we noticed that the notification was sending the incorrect number of assets to order.  In some circumstances, the system would tell the stockroom manager to order 0 new assets:

Restocking Email

Our developer investigated, and discovered that the email is sending the existing stock, instead of the quantity to order.  Our developer submitted a ticket to ServiceNow, who confirmed that this is the out-of-box behavior.

To solve the problem, we are rewriting the email notification in our instance.  The downside to this is that if ServiceNow does correct this issue, our changes to the email will prevent the updates from reaching our instance.  The good news is that I wouldn’t expect ServiceNow to update the notification – unless they’re fixing this defect.



ServiceNow Knowledge, Part 3: – Knowledge Admins are the Garbage Men

This blog is a continuation of Parts 1 & 2.
Throughout this 3 part series, I’ve discussed how the ServiceNow knowledge base can resemble the prisoners’ dilemma, bringing about selfish actions that may weaken the effectiveness of the knowledge base as a whole.  I’ve suggested multiple ways to curtail this effect, including several organizational change management (OCM) efforts.  However, all of these OCM efforts can be rendered meaningless if the quality of the knowledge base starts to drop.  Bad content leads to selfish users in the knowledge base.


Bad Content Leads to Selfish Users

Imagine a user with a question who two choices – either going to the knowledge base, or emailing around until he finds the correct answer.  Emailing is the selfish action – it will save the user time, but take up time of the people he emails.  Instead, let’s pretend that the user decides to go to the knowledge base, but finds it full of outdated, inaccurate information.  The user is going to say “Why did I bother looking in the knowledge base, anyway? It’s full of junk!”

How likely is it that this user will use the knowledge base the next time a question comes up?

Knowledge Admins – The Garbage Men

As a knowledge admin, it’s important to make sure that authors understand this effect of bad content.  Bad knowledge articles don’t just negatively reflect on that article – they can sour users’ perceptions of the entire knowledge base, making users less likely to use the knowledge base in the future.

In an unchecked environment, this can result in a negative feedback loop.  If users start using the knowledge base less, authors may see a disincentive from writing good knowledge articles – “People don’t check the knowledge base, so why bother writing a good article?”

As a knowledge admin, it’s important to make sure that authors understand that a bad article doesn’t just reflect poorly on the author, it reflects poorly on the knowledge base itself.  To keep the knowledge base running smoothly, knowledge admins need to be the garbage men of the knowledge base – disposing of the trash, and cleaning up the sloppy articles.

Kaizen your Knowledge Base

One way to clean up the knowledge base is to kaizen the knowledge base – have a culture of continuous improvement around your knowledge base.  One way to implement the kaizen is to force users to improve sloppy content.

In one sense, this could be thought of as the opposite of “rewarding good efforts.” (link to relevant article) If you force an author of a sloppy article to rewrite the article, you are essentially punishing the sloppy writing habits.  This will continue to fix the misaligned incentive structure (link to relevant article) – if the author has to spend extra time fixing a bad article, then maybe it would just be quicker to write it well in the first place.

But more than that, most sloppy articles are not a product of intentional negligence.  A low-quality article may simply be a situation of an author not realizing the standards of a good article.  Also, time can cause article quality to decay.  An article can become inaccurate or obsolete if it stays in the knowledge base for too long.   Like we mentioned above, poor quality articles can destroy users’ faith in the base itself; thus, it is imperative to keep reviewing content to ensure that articles aren’t degrading over time.

How to Improve Poor Content

At my Fortune-500 consumer packaged goods client, we have used a number of methods to maintain high quality articles.  Every article goes through two reviews before being published in the knowledge base to ensure that articles are high quality at the get-go.  First, they are reviewed for style and grammar by the knowledge admin, and then a subject matter expert performs a technical review.

Once an article is published, the author makes use of the built-in feedback tools to help identify articles that may have slipped past the initial review or degraded over time.  The knowledge admin regularly checks the feedback of articles to identify flagged articles that need to be rewritten or clarified.  Articles that are flagged as inaccurate have an email automatically generated to the author to initiate an immediate review.

Finally, all articles are required to be reviewed by the author at least once a year to prevent articles from becoming outdated.  The yearly review is initiated using the valid to date.  The author can set the valid to date for up to one year in the future, and the author setting the valid to date is his way of verifying the article is currently accurate and will be continue to be accurate until that date passes.    When the valid to date gets within a month, business rules automatically fire an email to the author, reminding him to review the article and reset the valid to date if the article is still valid.  The act of resetting the valid to date becomes the author’s way of certifying the article is accurate.  If the article is no longer accurate, the author is encouraged to either edit it as necessary or retire it.

If an author ignores the emails, the article will go past the valid to date, and no longer be visible in the knowledge base.  The emails, and the consequence of the article being no longer visible, gives the author the incentives to actually complete the yearly review – often good habits like this one can slip by the wayside if there are no consequences.

Because the article can become invisible in the knowledge base, it’s important for the knowledge admin to monitor for articles that have passed their valid to date, and validate whether the author simply forgot to review the article, or if the article is actually outdated and needs to be retired.

Knowledge – Energy That Feeds on Itself

Hopefully it’s clear that there’s a certain energy that the knowledge base has that feeds on itself.  When left alone, this can be a negative energy where authors and readers can be incentivized to “betray” the knowledge base by putting in low levels of effort.  This negative energy can incentivize other users to slack as well, causing a negative feedback loop where the usefulness of the knowledge base is continuously declining.

It’s up to the knowledge admins to inject positive energy to ensure the knowledge base functions smoothly.  As a knowledge admin, you are the garbage man of the knowledge base.  You need to make sure the knowledge base stays clean – that junky old articles are either polished up or retired. By injecting positive energy, you can create a positive feedback loop that ensures the knowledge base is running well.

By ensuring good buy-in, rewarding good efforts, and implementing systems to improve poor content, this can tip the scales in favor of using the knowledge base correctly.  The same way that the negative energy can feed on itself, the positive energy can feed on itself, incentivizing both authors and readers to use the knowledge base to its full capabilities, and saving everyone involved time and energy in solving issues.  With this injection of positive energy, you may find less need to police the knowledge base, as people will be fixing their articles as needed.  Ultimately, by injecting this positive energy, you can help keep your knowledge base clean as a whistle.


Note: This article has also been posted to my company’s insights page.

ServiceNow Knowledge, Part 2: Every Man for Himself Breaks Down Every Man. How To Get Users to Think of More than Themselves

ServiceNow Knowledge Base can be like the Prisoner’s Dilemma. So shift people’s perspectives of the game.
This blog is a continuation of Part 1.

In the previous blog in this series, I discussed how the ServiceNow knowledge base can resemble the prisoners’ dilemma, due to a bad incentive structure, and discussed ways to change the incentive structure to help users make choices that benefit the knowledge base as a whole.  However, there’s an underlying assumption in the metaphor that users are only self-interested, and this selfishness is part of what brings about the poor incentive structure.  With any faceless technology, there’s always the threat of users losing sympathy for the other users.  As a Knowledge Administrator, it’s important to make sure that users are aware of their other users.  By making users sympathetic to their fellow users, the misaligned incentive structure may evaporate entirely, solving the prisoners’ dilemma scenario without needing to directly change the incentive structure at all.

How are People Self-Interested?

How Prisoners are Only Self-Interested (Prisoners’ Dilemma POV)

Let’s refer back to the prisoners’ dilemma analogy from the previous post. The model above assumes that the prisoners are taking an “every man for himself” approach to their plea deals.  There is no sense of comradery or honor between the two prisoners that might encourage them to risk betrayal to help the other one out.  And conversely, the prisoners aren’t going to feel any guilt if they betray the other one, causing the other additional jail time (man, these are really some ruthless criminals).  Thus, when the criminals make their decision to betray the other, they are only thinking of their own outcomes – they don’t care about the outcome of the other.

How Users Are Only Self-Interested (ServiceNow POV)

Similarly, in this theoretical knowledge base, the participants are only self-interested.  By writing a sloppy article, the authors reveal that they are not respectful of the readers’ time.  Similarly, the readers are not respectful of the authors’ time by emailing them directly, rather than searching for a knowledge base article.

How might this happen in a real knowledge base scenario?  Are we assuming that all knowledge base users are just jerks who only care about themselves?  Is this model realistic for a real-world knowledge base?

Probably not to the full extent of this example.  However, it’s possible to imagine a scenario where users don’t think of their fellow users as much as they should.   With any faceless software, it’s easy for users to forget the other people behind the scenes.

How Can Knowledge Admins Deter Self-Interest?

As a Knowledge Administrator, it’s important to recognize that the knowledge base incentive structure may resemble the prisoners’ dilemma, encouraging users to behave selfishly.  However, if you can change users’ attitudes to think about other users, the prisoners’ dilemma situation may disappear entirely, since users will now act with other people in mind.

Good User Buy-In

Ensure that both authors and readers understand the importance of doing their part to the best of their abilities.  Using effective Organizational Change Management (OCM) techniques can help users understand the importance of all the different roles in the Knowledge base, and why it’s important for everyone to do their part effectively.

“What’s in it for me?” – Make Sure People Know the Correct Answer

With good user buy-in, users can answer the question “What’s in it for the knowledge base?”  But more important than that, is making sure that users can answer the question “What’s in it for me?”  As a Knowledge Admin, it’s important to make sure that users understand the reciprocal nature of the knowledge base – that by doing their job correctly, it makes others’ jobs easier as well, and vice-versa.  By understanding their own personal benefit, it will be much easier to create a lasting change.

Envelop High Standards Within the Company Culture

Being selfish is the lazy way to use the knowledge base.  As a knowledge admin, it’s important to set a culture of expecting high standards within the company.  Point out examples of the high standards of the company, and encourage users to be proud of that culture. If people feel like they’re a part of something bigger than themselves, they will be likely to go that extra mile to help maintain those high standards.

You’ve Users Interested in Others – Now How Do You Keep Efforts High?

Now that you have users thinking of the entire knowledge base, everything’s well and good, right?  Maybe not.  Imagine this scenario – a user is excited about maintaining the high standards of the company, and searches the knowledge base for his answer, even though it might take longer than emailing his coworker.  When he searches the knowledge base, he finds it littered with outdated, and factually inaccurate articles.  “Why did I bother searching the knowledge base, I had to email a coworker, anyway. Next time, I’ll just email the coworker directly.”

In the next article in my series, we’ll talk about using Kaizen principles to continuously improve your knowledge base, to help keep users thinking about other users in the knowledge base.

Note: This post has also been posted on my company’s insights page.

Bad Incentives: How the ServiceNow Knowledge Base Resembles the Prisoners’ Dilemma, Part 1/3

ServiceNow Knowledge Background

ServiceNow is a Platform as a Service (PaaS) that offers an array of Service Management applications, with roots in IT Service Management (ITSM).   Among them is a knowledge base, where users can gather, analyze, store, and share knowledge with the purpose of improving efficiency by reducing the need to rediscover knowledge. [1]

Prisoners’ Dilemma Background

The prisoners’ dilemma is a classic thought experiment that shows an example of where people might not cooperate, even though it is in their best interest as a group to cooperate. In the classic example, there are two prisoners who are being interrogated for a crime. Each prisoner has two choices – either turn in their partner for a reduced sentence (betray), or stay silent (comply). For this example, we’ll say that if both prisoners comply, and stay silent, then they both will only get a 1 year sentence. If they both betray each other, then they’ll each get 3 years.   But if only one prisoner betrays the other, then the prisoner who betrays will be released, while the prisoner who stayed silent will get 5 years. Each prisoner has to make the choice independently and without discussing with each other– they can’t collude to both stay silent. The chart below summarizes the options and payoffs:

Prisoners Dilemma

Implications for ServiceNow Knowledge

Clearly, the prisoners would be better off as a group if they could both stay silent –

there would only be 2 total years of prison time. However, this scenario tends to end with both prisoners betraying. A double betrayal is what’s referred to as the Nash Equilibrium, which essentially means that this is the most likely outcome (see the link for more information).

Fortunately, the stakes are much lower for ServiceNow knowledge bases. No one is going to prison (at least, I certainly hope not!) However, the basic structure of the prisoner’s dilemma can potentially apply to the Knowledge base. Using the prisoners’ dilemma as a framework, I’ll discuss some aspects that can lead to a lower quality knowledge base and specific examples of how to fix these issues.

Imagine that instead of prisoners, the two parties are the authors of articles and the readers of the articles. The parties have two choices, similar to the prisoners’ – they can either “cooperate”, or “betray,” meaning that they can either do something beneficial to the knowledge base, or something more selfish. For the author, this would be either writing a high quality article that includes some of the attributes previously described, or writing a sloppy article.   For the reader, the choices would be either checking the knowledge base for the answer, or just emailing the author for the answer. Rather than prison time, the outcomes are measured in the total amount of time that the person has to spend for his portion of the knowledge base. Again, in this thought experiment, there are no outside agents, and the author and readers make their decisions in a vacuum.

Knowledge Dilemma

How is This Similar to The Prisoner’s Dilemma?

Though the numbers are different, this thought experiment is structured in such a way that the Nash equilibrium is the same as before – with both parties betraying each other.

Why does this happen? There are several problems that lead to a Nash Equilibrium outcome of a double betrayal: 1) there’s an incentive structure that discourages cooperation, 2) the parties are only interested in themselves, and 3) there’s a lack of trust between them.

I’ll discuss reasons 2 and 3 in future articles, but for now let’s examine reason 1 – the incentive structure – from the prisoner’s dilemma and see how it applies to this Knowledge situation.

Misaligned Incentive Structure (From Prisoner’s POV)

If the warden was attempting to create an incentive structure that would encourage the prisoners to betray each other, he got it.

The reason for this is that they will individually get less jail time by betraying, regardless of what the other prisoner does. For example, if prisoner A stays silent, prisoner B will go free by betraying, but would get 1 year by staying silent. Or if prisoner A betrays, then prisoner B only gets 3 years by also betraying, versus 5 years by staying silent. In both scenarios, prisoner B is better off by betraying, and the same thing happens for prisoner A. This leads to the Nash Equilibrium outcome of both prisoners betraying.

Misaligned Incentive Structure (from ServiceNow POV)

The incentive structure in the ServiceNow Knowledge base is similar to the prisoners’ dilemma – the optimal solution to minimize total time involved is for everyone to cooperate and do the best job they can (write a good article, and check the knowledge base for answers).

Similar to the prisoners’ dilemma, the author has the incentive to write a sloppy article because regardless of what the readers do, he will spend less total time if he writes a bad article (if the readers check the knowledge base, he would spend 1 hour total on a good article, versus 50 minutes total on a sloppy article). Similarly, the readers have an incentive to just email the author, since they will end up spending less time total by doing so, regardless of the quality of the article that the author writes (1 hour and 20 minutes on the good article side, and only 50 total minutes in the bad article case). Assuming that the time estimates are reasonable, the incentive structure leads to the same Nash Equilibrium from before – with both parties betraying. Regardless of the specific time estimates of this example, it’s easy to imagine a scenario where both parties would have an incentive to slack.

How Can Knowledge Admins Avoid Bad Incentive Structures?

In the classic prisoners’ dilemma, the incentive structure is set up in such a way that can incentivize users to act in a way that’s detrimental to the overall health of the base. It’s important for Knowledge Administrators to recognize this pitfall, and ensure that appropriate steps are taken to remove these temptations. I’ll discuss two ways to fix this bad incentive structure – altering the incentive structure, and changing users’ perceptions of success.

1.      Change the Incentive Structure

This might seem obvious, but the best way to prevent users from falling into this pitfall is to change the incentive structure to reward the behavior that makes the base work properly. You can do this by rewarding good efforts, and making sure that poor efforts have to be corrected.

Reward Good Efforts

Make sure that authors and readers are properly rewarded when they do a good job. These rewards need to be on-going to make sure users continue to perform their duties effectively.

Rewarding good efforts can help fix the misaligned incentive structure. In the example above, the only rewards are in terms of time spent looking for the solution, or time spent writing an article. Additional incentives can be created to help motivate users to maintain a high quality knowledge base.

An example that a knowledge admin could implement would be recognizing authors that consistently produce high quality articles during yearly reviews. Quarterly rewards (giftcards, etc.) given to the authors with the highest rated articles would also help encourage good content.

Implement Systems to Improve Poor Content

This could be thought of as the opposite of “rewarding good efforts.” If you force an author of a sloppy article to rewrite the article, you are essentially punishing the sloppy writing habits. This will continue to fix the misaligned incentive structure – if the author has to spend extra time fixing a bad article, then maybe it would just be quicker to write it well in the first place.

How to Improve Poor Content

As far as improving poor content, CapTech suggested a number of strategies to a Fortune 500 client. Stay tuned for a future blog post about improving low quality knowledge articles!

2.      Change Users’ Perceptions of the Game

The other way to change the incentive structures is to change authors’ perceptions of the incentives. The assumption we’re using above is that users are only thinking about how to minimize the time that they individually spend in the knowledge base.   But what if you can change the users’ perceptions, and have them not be only focused on their own time, but of the total time spent in the knowledge base. This can make a huge change to the fundamental incentive structure. I will discuss how to make this shift in Part 2 of this series, which will be released soon.

Don’t Like the Outcome? Change the Game.

Throughout history, entrepreneurs have succeeded by changing the rules. When it comes to ServiceNow Knowledge bases, the rules of the game can be stacked against you. As a Knowledge Administrator, it’s important to recognize that the incentives in the ServiceNow knowledge base may be stacked against you. But you have the power to change the rules, and alter the incentives to encourage people to use the Knowledge base in a productive manner.

In the next post in this series, I’ll discuss how to shift users’ perceptions of the incentives of knowledge – to get users to think of the entirety of the knowledge base, not just themselves.


Note: this blog has also been posted on my company’s insights page. Check them out for more information and insights on ServiceNow and other technologies!