Sunday, July 14, 2019

Scrum is a Methodology, not a Buffet

Q. What’s something everybody does, but nobody does the same? A. Scrum!

In today's post we'll debate this question: Is it important to fully adopt Scrum as a software methodology, or is it sufficient to just use the parts that seem useful?

I’ve wanted to write something on this subject for years now, but I’ve hesitated given how explosively charged Internet debates on software methodologies can be. Let me state at the onset that I am neither a Scrum Worshipper nor a Scrum Hater: I wrote quality software before Agile existed and now I write quality software using Scrum. I value what we have gained with Agile methodologies, but I also bemoan what they've cost us.

ScrumBut: We Do Scrum, But Not All Of It

Without question, Agile Scrum has taken over as the software methodology of choice, just as Github has taken over as the software repository of choice. Scrum's pervasiveness ought to mean that when a developer who knows Scrum joins a software organization using Scrum they can hit the ground running. In my experience that's hardly ever true, and one of the common reasons is the lack of consistency in how teams apply Scrum.  

Over the last 12 years I've consulted with and worked with lots of teams that practice Agile Scrum. That includes 5 years as a national consulting practice manager, so I've had exposure to a great many customer projects beyond the ones I contribute to personally. When the customer controlled the process, the majority of those teams didn't really follow Scrum, they practiced ScrumBut: as in "We do Scrum, but not all of it." Do some online research and you'll find plenty of others reporting the same; ScrumBut is a well-recognized phenomenon.

Here are some of the things I’ve personally seen teams drop from their practice of “Scrum”:
  • We do Scrum, but we don’t do sprint reviews
  • We do Scrum, but we don’t do sprint planning meetings
  • We do Scrum, but we don’t do the daily stand-up meetings
  • We do Scrum, but we don’t have a product owner
  • We do Scrum, but we don’t have a scrum master
  • We do Scrum, but we don’t have a product backlog
  • We do Scrum, but the product owner assigns work to team members
Some of you reading this are Scrum champions who only work with teams that rigorously enforce Scrum and are shaking your heads. Perhaps it’s your job to see that Scrum is followed well. That’s great, but I assure you such teams are the minority. Understanding why and whether it's always a negative is important.

Why does ScrumBut happen? After all, Scrum is a lightweight methodology. It doesn’t ask much. It only has a few roles, artifacts, and ceremonies. I’ve identified four reasons:
  1. Human nature. If you’ve ever listened to a debate over a political issue or a point of religion, you’re well aware that even people who share common values can disagree endlessly on the finer points. Not everyone is going to weigh things the same way.
  2. Software is a vast realm. There are many kinds of software and many kinds of developer, with a wide range of skills, maturity, and experience. Developing a web site is way different from creating a video platform or working on an operating system. Expecting one methodology to work equally well across that spectrum is rather optimistic.
  3. Agile itself is partly to blame because its underlying message is often misinterpreted as “you don’t have to do everything”. It seems the effect of Agile trimming away practices deemed to be of secondary importance may have encouraged people to just keep doing away with things.
  4. Distrust. Older generations are more likely to place implicit trust in a system and give it a chance, but the younger generation is less persuaded.
Let's consider the case for doing full scrum (following the methodology) and the case for doing only some of it (buffet-style) with an honest attempt to be open-minded about the question. 

All or Nothing: The Case for Full Scrum

I'll fully admit my own inclination is to use full Scrum. The line of reasoning here is that Scrum is a methodology: that is, a system whose various elements are designed to support and complement each other. When you don't apply all of the parts, you're removing legs from the chair that holds you up. Dismantling parts of a system undermines the system. Will it still work? Maybe, but not as well as when it's complete.

Imagine you have a friend with an alcohol problem and you bring them to an AA meeting. Here’s what you would not hear: “We have a very successful 12-step program; which steps do you feel are right for you?” Of course that wouldn’t happen: the program is only effective if it’s taken as a whole, with all steps being done in the intended order. We recognize that it’s a system. There’s a second point to be made here: the person with the alcohol problem is not an expert on how to recover and is hardly in a position to design their own treatment. In the same way, a software methodology should be viewed as a system to be adhered to.

It needs to be acknowledged that even among those who do full scrum there are differences between how it is practiced. Some organizations overdo Scrum, becoming what is sometimes referred to as a Church of Agile. We should always keep in mind that the team does not serve the methodology: rather, the methodology serves the team. Like anything else popular in the computer world, Scrum is also subject to the hype cycle which accessorizes the methodology with inflated services, certifications, self-important titles, expensive software packages, condescending attitudes, and a sometimes crazy obsession with points and charts. In The State of Agile Software in 2018, Martin Fowler calls this the Agile Industrial Complex and calls for its dissolution. Full Scrum can be over the top if it is obsessed over and becomes the objective rather than the means.

If doing full Scrum is critical to project success, there ought to be some clear evidence that full Scrum tends to work and partial Scrum tends to fail. While I’ve encountered plenty of Scrum champions with that opinion based on their own experiences, I’ve yet to discover objective results that conclusively support this conviction. For all the personal examples you or I could cite, that’s not statistically meaningful. If I reflect on my own experiences, yes I’ve seen software projects fail where oftentimes a lack of discipline (including a poor understanding of Scrum) is an ingredient; on the other hand, I’ve seen projects succeed where ScrumBut was applied. 

Why Is It Useful? The Case for ScrumBut

Partial Scrum is far more common than Full Scrum by every measure I can make. I’ve noticed ScrumBut teams fall into two distinct categories: those who don’t know any better, and those who consciously choose partial Scrum. I’ll call them the Naive Scrumbutters and the Intentional Scrumbutters.

Naive Scrumbutters

The Naive Scrumbutters are those who don’t know any better. A great many teams and organizations will proudly tell you they are practicing Scrum, and in their minds they are. Sadly, they suffer from a superficial understanding of Scrum. We're holding a daily Scrum meeting, therefore we're doing Scrum

Scrum naivete is rampant. I’ve seen these kinds of activities go on regularly which indicate a poor command of Scrum principles:
  • Sprint planning is where the executive tells the team what they will work on that sprint
  • The sprint has started but the stories aren’t ready yet
  • The product owner decides in advance who will work on what
  • We have to get all of this work done this sprint because that’s the deadline
  • Software written this sprint isn’t tested until a later sprint 
  • We can’t wait for the end of sprint, we need to release software sooner
Naive ScrumBut occurs particularly often when a high-ranking person in the organization with a shallow knowledge of Scrum sets the ground rules; no one is willing to challenge them. It also results when roles are oversimplified or combined or omitted. Scrum works best when everyone involved understands how it is supposed to work, and much of its value is lost when the product owner or scrum master lack the understanding or willingness to perform their role properly.  

Naive Scrumbutters are the ones likely to have many project problems. They’ve removed too many of Scrum’s underpinnings, and they don’t even know it.

Intentional Scrumbutters

The other group, Intentional Scrumbutters, knows full well what Scrum entails, but have decided to leave out some of its precepts. This approach views Scrum more as a list of potentially useful practices rather than as a system whose parts reinforce each other. They treat Scrum like a buffet, taking only the items they like. Reasons given by organizations for skipping some elements of Scrum include the following:
  • Someone in control of the process thinks they know better.
    I’ve seen [what we do here] work time and time again. Trust me.
  • Someone in control of the process doesn’t see value in some of its elements.
    Our roadmap for the rest of the year is already defined. We don’t need a Product Owner.
  • Team members don’t see value in some of its elements.
    Why is a sprint review meeting useful? I don’t think it’s a good use of my time.
  • There are difficulties carrying out some of the elements.
    Everyone here has freedom of schedule, and some of the team live in other states or countries. There’s no way to realistically schedule a daily stand-up meeting.
  • Skepticism
    There’s no point in having a sprint retrospective, because nothing is ever going to change around here.
“Why is this useful?” is a question I am often asked by younger developers when I ask them to start doing Scrum ceremonies they are not used to—even about Sprint Planning and Sprint Review meetings. Well, that’s always a fair question to ask, but it reveals something about the person doing the asking; clearly they do not put trust in the system they’re being asked to follow. Perhaps they will after they’ve seen it work.

While many Intentional Scrumbutters are clearly making questionable decisions when they tinker with Scrum, it’s not always the case. I’ve seen Silicon Valley tech companies practice ScrumBut with spectacularly successful results, consistently producing quality software over and over. However, I believe these are the exceptions rather than the rule. These companies have very experienced engineering leadership and capable and committed developers across the board, and I suspect the omissions from Scrum are compensated for by other engineering practices. This article is worth a read: Why Scrumbut Shouldn't Be a Bad Word.

SlimScrum: An Alternative to ScrumBut

As we’ve seen, ScrumBut happens a lot. For a variety of reasons, some of them valid, organizations sometimes jettison elements of Scrum. This results in ScrumBut, which is dangerous because now the system is incomplete.

What can you do if you are part of such an organization and would like to practice full Scrum? Depending on your position and situation, you may or may not have the standing to make changes. If you can’t authorize outright changes, there is an alternative to ScrumBut which I call SlimScrum.

SlimScrum means you find a way to include all the roles, artifacts, and ceremonies of Scrum—but are willing to be flexible in how they are implemented. To my thinking, having all the elements of Scrum (even if reinterpreted somewhat) is far preferable to leaving some of them out altogether. Let's consider a few examples.

If it’s truly impractical to get everyone together for that short daily stand-up meeting, consider using Slack or an equivalent enterprise social network. In fact, I find it so useful for team members to list what they worked on yesterday / plan to work on today / blocks on Slack that I like to have it even when teams do have a daily stand-up meeting.

If long meeting times are given as a reason to not do full Scrum, consider how long sprint planning and sprint review meetings really need to be. Do you need a 4-hour sprint retrospective meeting if no one thinks anything needs to be discussed? I am not suggesting arbitrarily shortening these meetings, but I think there is room to adjust them based on how your team engages and whether anything useful is being accomplished.

Missing Scrum roles is perhaps the toughest omission to deal with. How do you make up for not having a product owner? If you’re unable to fix that problem in the organization but your immediate team is onboard with trying to solve it, have someone in sprint planning and sprint review meetings assume the role of product owner. Using a proxy can work if that person can reach out to stakeholders between meetings to stay informed. It’s not ideal, but it’s better than being directionless. You can do the same with the scrum master role.

In Conclusion

Scrum consistency is a widespread problem: you run into ScrumBut all over the place. We’ve identified some of the reasons for it, and looked at both the naive and intentional Scrumbutters. Naive Scrumbutters need to be educated about what Scrum actually is. Intentional Scrumbutters are advised to consider what they might be missing. Even if tinkering with Scrum works for you, it still puts a barrier in place for new hires trained in Scrum which is inefficient.

I urge teams to treat Scrum (or any methodology) as a system to be followed completely, not a buffet where you only take what you like. You’ll get a lot more out of the system if you give it a chance to work for you.

Saturday, June 22, 2019

Open Your Eyes to Technology Blindness in Your Decision Making

If you make or recommend technology decisions, you've probably seen your share of good and bad ones with both expected and unexpected outcomes. Technology decisions are tough, and one of the reasons is a kind of blindness we have about technology. In this post we'll examine some different types of technology blindness and what you can do to prevent them from steering you in a wrong direction.

Solving the Wrong Problem

"If I had an hour to solve a problem I'd spend 55 minutes thinking about the problem and 5 minutes thinking about solutions." ―Albert Einstein

Asking the wrong question can derail the decision-making process from day one. Imagine you work in auto sound systems and are asked to make the speakers louder. If you take the request at face value and start working on making your speakers louder, you could well be solving the wrong problem. Instead, you should probe into what the real problem is by inquiring what the impetus was for the request. If you investigate, you might discover the real issue is that the car has poor soundproofing (nothing to do with speaker volume). Or perhaps someone is hard of hearing and the solution to their problem is a hearing aid, not louder speakers. It's critical to understand the actual root problem and not be swayed by someone's suggested solution.

The XY problem is a well-known phenomenon where someone asks "How can I use X to solve Y?" when they should have been asking "How do I solve Y?" The emphasis on a proposed solution throws all the attention in the wrong place (X), the root problem doesn't get studied, and other potential solutions never get considered (quite possibly including the best solution). You want to understand the real problem at hand and not have a decision colored by an initial suggestion.

The XY problem is something we're all probably guilty of, but once aware we can stop it from continuing. The XY problem is particularly difficult to contend with if it comes from a high-ranking person in your organization that no one is willing to challenge. Sadly, you may at times run into the XY problem not out of ignorance but deliberately, because someone stands to gain something if decision X is made.

If you suspect an XY problem, approach it constructively by asking the right questions to get your group to understand what the real decision question is. From there, you can consider multiple solutions in addition to the one that was originally advanced.

Be sure you're asking the right question, and steer clear of the XY problem.

The Bright Shiny Object

"It is a mistake to suppose that any technological innovation has a one-sided effect. Every technology is both a burden and a blessing; not either-or, but this-and-that." —Neil Postman  

A bright shiny object is anything we're enthralled with. Whether as children or adults, when human beings are fascinated with something they look through rose-colored glasses. Whenever we're shown new technology with some obvious benefits, we tend to focus on the positive and not think very much about negatives. The history of technology is full of examples of things we've rushed to embrace, only to later discover they also come with consequences, sometimes disturbing ones.

The automobile provided many benefits, including freedom to travel; the ability to work and shop beyond walking distance; and they were fun and cool. When automobiles started to be widely embraced in the 1920s, the public was focused very much on those benefits. There were secondary benefits, too: mass producing the automobile led to jobs and manufacturing innovations like the assembly line. Despite all these benefits, there were also consequences but they went unrealized for a long time. The automobile also polluted; led to traffic jams and highway deaths; and dissolved the traditional practice of multi-generational families living close together.

Television's huge popularity has given us a multitude of ever-increasing programming for decades, some of it quite good. However, it too has negative repercussions. It's been a huge contributor to obesity; has been shown to have negative behavioral effects on children; and also can't be trusted to be truthful. In the book Amusing Ourselves To Death, author Neil Postman explores what television has done to public discourse and our ability to think and debate critically. Television's nature means entertainment and ratings are king; any other considerations such as truthfulness and accuracy of content are subservient to those top considerations.

Today we hear a lot about "fake news", usually associated with social media. When social media started getting traction, people were focused on benefits such as being able to stay in touch with friends and family far away; and re-connecting with people from your past. Other benefits followed: a relative could see pictures or video of that birthday or graduation they were unable to be there for; and we can now check lots of reviews before we decide to purchase something or go somewhere. Among all the good, we're only now becoming aware of the downside: social media lets people spin what they share; encourages addictive behavior through dopamine-rewarded interactions; distracts drivers (sometimes fatally); and channels our attention on things that go viral. Of course there is fake news on social media: the fundamental nature of these platforms promote this behavior, whether intended or not.

The good and bad effects of examples like these are obvious in hindsight but much harder to realize at the time you are confronted with a new technology. That's why it's so important to be on the lookout for them. When you consider any new technology or product you should evaluate it as fully as you can. Not having the full picture means you may have missed a significant negative or not accounted for its true cost.

Recognize that every technology is a double-edged sword that comes with consequences as well as benefits. Identify them so you are making an informed decision. If a technology is so new there isn't much known about its consequences, ask yourself if you're really willing to risk those unknowns. If your company culture encourages you to take risks or make big bets and you're looking to use a new or unproven technology, you should at least anticipate that there may be unintended consequences and have a fallback plan.

Get the full picture on any technology, product, or platform you're considering. Make an eyes-open decision that takes into account consequences as well as benefits.

Success Blindness

"If you can’t measure it, you can’t improve it." ―Peter Drucker

So, you've made a decision. Was it a successful one? You'd think the answer to that would be fairly obvious once some time has gone by, but you'd be surprised how often a decision's effects are less than clear. On more than one occasion I've watched leaders paint a decision as successful when there is no basis for that claim, and it's a sad form of self-deception. On top of that, some people just won't admit to failure and will lie about the state of things to their superiors.

Don't be deceived and don't be dishonest: know exactly where you stand and have the courage to honestly evaluate the success or failure of your decisions.

Success blindness is almost guaranteed if you haven't devised a way to measure the success of your decision. Without measurement, it's too easy to find something positive in the state of affairs and attribute it your decision without knowing if there's any correlation. Be aware that it's rather self-serving to come up with a success measurement after the decision has been put into effect, so be sure to address measurement early on.

If you want to get better at decision making, technical or otherwise, you need to get in the habit of measuring the success of your decisions. You made that decision in order to bring about a positive result, right? Then there should be a way to measure that result. If you're unsure how to measure the effects of your decision, you can learn how to measure well. I recommend How to Measure Anything: Finding the Intangibles in Business by Douglas Hubbard.

Overcoming Technology Decision Blindness

Solving the Wrong Problem, Bright Shiny Object Syndrome, and Success Blindness are common afflictions that plague technology decision making. Technology blindness is something we are all susceptible to; overcoming it requires acknowledging it. Start with yourself by taking a hard look in the mirror. Seek to uncover your own blind areas and decision biases. Then influence others to do the same.

Constructively ask the right questions in meetings and documents to focus on the real problems you need to understand and shed light on blind spots as you consider solutions. With awareness, you and your colleagues can make more successful decisions with confidence. With measurement, you can get better and better at it.

Saturday, June 15, 2019

Using Mind Maps for Brainstorming and Idea Refinement

Mind Mapping is a very effective technique for getting teams to brainstorm and refine their ideas. I'd like to share where I learned the technique and how I use it today.

My Introduction to Mind Mapping

The year was 2005, and at the time I worked for Microsoft on the product team that was developing "Indigo", later to be known as Windows Communication Foundation. We were a large team of 400, and I'd been invited to attend a meeting called by Oliver Sharp, our General Manager who led the overall team.

What followed was a fascinating meeting where I observed how to get people to brainstorm and refine their ideas quickly and effectively. It's too long ago for me to remember the exact details (nor would it be appropriate for me to share them), but I'll recount the basic way it proceeded with some generalized content.

We were slated to release WCF later that year, and Oliver wanted a program defined to focus on fostering customer adoption of the new technology. At this meeting we needed to take the raw notion of a "Customer Adoption Program" and turn it into something tangible. I and several dozen others had been invited to this meeting.

Oliver shared his screen, which appeared to show a virtual whiteboard. At the center was "Customer Adoption Program". And then he simply asked everyone to chime in. He wanted to hear ideas about what that should include. As things were suggested, he rapidly incorporated them into what I learned was a Mind Map diagram. If someone suggested the need for samples, a spoke went out labeled Samples. If someone else mentioned the need to support migration, a Migration spoke went up. Most suggestions, unless there was group dissent, went on the board initially. Some remained, while others were later removed or combined with something else.

It wasn't just adding spokes. Some spokes, upon being identified, led to offshoot ideas. As ideas were articulated, he asked refinement questions: was this idea right or wrong? what would it entail? Were we considering alternatives? His skillful questioning forced us to think things through and round out our ideas.

As more things were suggested, it was necessary to revise the diagram. After Announcements and Blogging were on the board, we realized these were both types of Customer Communication; so the diagram changed. The Mind Mapping software he was using (MindJet MindManager, I think) made these kinds of reorganizations and moving of whole branches around quick and easy. This allowed the mind map to keep up with the pace of discussion without being onerous.

As more spokes were added, conceptual grouping continued. Convention Sessions and Code Camps were events, so they were incorporated into an Events category; and once the category was up there, other types of events came to mind such as training sessions at local field offices. Samples, documentation, and migration guidance became Resources. Whenever a concept had to be inserted or branches had to be moved around, the Mind Map software made this effortless. Ideas were being shouted out left and right and concepts were forming and being refined quickly. Some items were dropped. Some were combined. Some morphed into their own category with sub-items.

It really was a marvel to behold how seemingly random ideas were herded and coaxed into a cohesive plan, because a skillful leader let the ideas flow from his team while in command of a powerful tool for organizing thought. When it comes to planning and ideation, I've tried to operate in exactly the same way ever since. Thanks Oliver!

How I Use Mind Mapping Today

Mind mapping is powerful, but don't get the idea it's something I do every day or every week. Although I do sometimes use mind maps to organize my own thoughts ("What questions might I get at this upcoming meeting?"), mind mapping really shines in a group setting. It's a technique I regularly employ when I need to need to lead a team through product design or annual planning or making a decision.

A mind map is not the end product in itself but rather a means to an end. You should think of it a device for organizing your thoughts and developing them. For example, I might employ mind mapping in annual planning but my actual deliverable might be a document or spreadsheet, not a mind map.

If you consider how a creative meeting would go without mind maps, you'll have to capture ideas in a document or on a whiteboard. That's far more limiting when it comes to developing ideas, and tends to make people hesitate to share ideas if they're not fully confident about them. In a mind map exercise, people are encouraged to share ideas and put them up there even if they're only half-baked at first. As the group considers and refines these ideas, the right things will happen to them and the half-baked ideas will become fully-baked. I suppose one could use post-it notes for this kind of exercise, but given there are very affordable software tools for this purpose I recommend using them.

Mind Mapping Tools

Today, there are many more choices for mind map software. I recently joined a new organization with a new team, and I took a fresh look at available tools. If you Google "mind map software" these days, you'll find there are many to choose from in addition to originals like MindManager. There are two basic categories: mind map add-ons and templates for general diagramming products; and software specifically designed for mind maps and other conceptual diagrams.

The first category (adds-ons and templates) is tempting because you can leverage a tool you already know well, such as Visio, MS Office, Google Docs, LucidChart or However, I've found this approach is too burdensome when you're trying to keep up with a brainstorming session. There tend to be too many clicks needed to add items and connections; and very limited support for inserting nodes and moving around whole branches to another area of the diagram. For example, I've been a PowerPoint user for decades, but I wouldn't try to use it for a mind map session: it would just be too cumbersome to insert new concept nodes and move things around. You really need something that can capture what's happening at the speed of a creative exercise which might include pivoting all your groupings and connections after a moment of epiphany. You also want to avoid a tool that will distract you from being a participant yourself. Personally, I think you're far better off with something designed to facilitate this kind of dynamic activity.

The second category (software designed for conceptual diagramming) is the better option and also has many choices. You of course should take advantage of free trials to evaluate some of them and decide which features you value the most. You may care most about unlimited canvas size, while someone else may care most about what kind of files can be attached to a diagram. Cost and license models vary: some of these tools are one-time purchases; others are subscription-based or even free. Some require an Internet connection, others don't.

For myself, I ended up settling on Coggle this year. Coggle is nominally free, but if you want privacy of your diagrams you're well-advised to pay the $5/month (or $50/year) for a subscription; that's not much for what is turning out to be a very usable tool. For this low price, you can invite others in your organization to co-edit your diagrams without having to purchase any additional subscriptions.

Here's an example of a mind map in Coggle, one that shows how a spell check feature for a (fictional) web site might be analyzed to get consensus on the best design. Things I value about Coggle include it's attention to usability, it's support for collaborative co-editing of your diagram with others, and that it doesn't overwhelm you with too many choices.

Coggle: Mind Map to Get to Consensus on a Site Feature Design Decision

Here's another example in Coggle, a personal one. I was discussing vacation ideas with my teenage son this morning, and here's our initial mind map. This map will no doubt change considerably when I add my wife and daughters to the conversation. Since some destinations appeal on more than one category (Hawaii rates on both Scenic and Fun Activities, Las Vegas rates on both Food and Fun Activities), this might require me to cross-link some items to multiple categories, but that could get messy. Or perhaps graduate to a different visualization or use a spreadsheet, the mind map having done its job to identify important categories and potential candidates. It's best to use tools like this where they shine, and to not force fit them into applications they aren't right for.

Coggle: Where to Go on Vacation?

In conclusion, mind mapping is a technique and toolset you ought to become acquainted with if you're ever in the position of hosting a brainstorming discussion. Compared to taking notes or just using a whiteboard, mind mapping both invites more ideas and equips you to refine those winning ideas and find consensus. The resulting clarity will be eye-opening.

Friday, May 10, 2019

Using Gamification to Motivate Development Teams

In this post I'll share some gamification techniques I've used to motivate software developers and improve team performance. For those not familiar with the term, gamification means using some elements of games in a non-game setting, such as developing any kind of software. It's all about adding some fun elements to the work that engage the team to rally around some activity and excel at it.

If you doubt that games are a big deal these days, just consider the statistics. According to Filmora, Over $115 billion was spent on gaming in 2018. While gaming is often associated with the young, 63% of gamers are 21-50 and 15% are 51-65. 46% of gamers are women. Some people earn their living by streaming their video game play, called esports. Last year, for the first time the Winter Olympics included an esports event, and some expect esports to become a medal event by 2024.

Why Gamification in Software Development?

Gamification techniques can, in theory, be employed anywhere there's a human endeavor—but it certainly helps if what you're doing already contains elements that lend themselves to gaming. Software development happens to be a great fit.

Gamification is all about motivation, and fun is a huge motivator. In software, like anything else, there are tasks that are naturally fun and other tasks that aren't so much fun. For example, most developers like working on features but dislike bug fixing. Features are fun, bugs aren't. What gamification can do is lend elements of fun and competition to those tasks that aren't already fun.

Managing a team of software developers can be like herding cats at times when what you need is everyone pulling in the same direction and pulling their weight. A good development manager is concerned with both team delivery as well as the care and feeding of team members. He or she will want to see their team reach a point of low friction and high performance, which requires working well together. It's in this area, team dynamics, that a software manager can employee gamification techniques to promote and improve cohesive team behavior. Some of these techniques are subtle but they can make a difference.

Software development is certainly a race to the finish, and I know of no better illustration than the classic 1959 film Ben Hur starring Charlton Heston. If you're familiar with the film, you might recall the scene where Judah Ben Hur first meets the Sheik and his four white horses, to whom he is very much devoted. Ben Hur observes the team racing and casually observes that the horses each have varying strengths, and the team would function better if certain changes were made such as moving a different horse to the inside of the track. The sheik is impressed with Ben Hur's prowess in team dynamics and pleads with him, "Can you make my four run as one?" Ben Hur agrees to work with the team, which goes on to see great victory.

In Ben Hur, "four run as one"

And so, a software project can be treated as a race; and an optimization task can be treated like a strategy game; and a difficult bug can be treated like a puzzle. There are many opportunites to apply gamification in software development. Let's look at a few examples.

Using Dashboards for Fun and Effective Metrics

Dashboards are fertile ground for gamification. Since many games display scores or stats, you can visualize software development metrics in the same way. Take bug counts, for example. You can show active open bug counts prominently. Even better, you can color-code them based on count, priority, severity, or whatever you choose to emphasize.

Showing Bug Counts wth Color Coding

In addition to raw bug counts I've found it useful to track how a team is trending on bugs, using the count new bugs found this week against the count of bugs closed this week. It's the ratio I'm interested in: if more bugs were found than were fixed, we're drowning (trending in a poor direction). If we're fixing more bugs than are being found, we're trending positively and our situation is improving. And if we're about even on these counts, we're just treading water but aren't really making progess. You can visualize these valuable statistics easily on a dashboard.

Bug Trend Count

If your dashboard allows it, the bug trend ratio could also be shown visually in other ways, like a seesaw or the artificial horizon found an airplane cockpits. The idea is to convey the team's direction dramatically (but not over-dramatically; everything can't be an emergency). And of course you can look at trends over time in charts and reports; here though we're thinkng about simple at-a-glance visuals the team can see every day about the current work. Whatever you choose to show, strive for clear measurements and a simple presentation: everyone should have a common understanding of what they're looking at and what they can do change the situation.

Putting scores and stats in front of the team is more than an attempt to make metrics fun and playful: it provides a feedback loop by which the team gets regularly reinforced about how effective or ineffective their efforts are. One of the most important things to learn about software teams is never mistake motion for progress. Useful visuals can help everyone on the team see that.

Making it Personal: Leaderboards

Another valuable gamification technique that also leverages dashboards is the use of leaderboards. I once worked with a team that was doing well on assigned feature work but dragged their heels on bug resolution; the bug backlog was larger than anyone liked and we weren't making sufficient progress against it, despite my weekly exhortations. It's somewhat natural for developers to prefer feature work to bug fixing, as the former is fun and the latter isn't. As a manager, I needed to ensure my team was fixing an appropriate number of bugs each week.

After some analysis of bug fixing activity, it was clear that we had a mixed bag in terms of developer focus on bugs. A few individuals were in fact addressing an acceptable number of bugs each week. Others did some bug fixes but not nearly the quota I'd established. And there were a handful who fixed no bugs at all. Even though a few were doing their part and more on bug fixes, the overall bug fix counts were far short of our goals. What was needed was a way to motivate every developer to do their part.

I hit upon the idea of showing bugs fixed each week, by developer, in the form of a leaderboard. Now it was crystal clear to the entire team at our meetings how many bugs each developer had fixed that week, ranked top to bottom by most bugs resolved. Something happens to you when you see your name displayed on a leaderboard like this: nobody wants to be on the bottom of the list, and the more ambitious will compete to be first on the list.

Bug Fix Leaderboard

Showing the bug fix leaderboard every day made a dramatic difference in bug activity and nearly all developers showed improved frequency right away. Like a sporting event, there were those clustered regularly near the top, middle, or back of the pack. When a dev, determined to break ahead, fixed a record number of bugs and rose on the leaderboard, that fact was pointed out and celebrated. Leaderboards probably aren't a good idea with a really small team but when you have half a dozen or more people they can be quite effective.

When employing gamification, you do need to be careful about the behavior you're encouraging and think about ways it might be abused. For example, a dev could rack up a large bug fix count by focusing on easy bugs of lower priority rather than top priority issues. Another way a system like this could be abused is the poor bug fix, where a dev appears to have resolved many bugs (looking good on the leaderboard) but in fact most of them end up getting reopened because they weren't fully fixed (or even worse, had side effects causing new bugs to be opened). A better metric would be truly closed bugs where the fix has been verified. You'll want to think through what you're visualizing and make sure it doesn't promote unintended behaviors.

Badges and Microcredentials

Years back, when I was a practice manager at Neudesic, I needed to train as many of my consultants as possible in a new area: cloud computing. Microsoft had a Virtual Technology Specialist position that partners like Neudesic could participate in, and when one of my consultants qualified I awarded them one of these physical badges. It's not that they actually wore these when going to clients, but these badges of recognition were something they could proudly display in their cubicle, and they incented others to have similar aspirations.
Today we have social media, and you can do the same thing digitally. If you use enterprise social media in your organization, and there is support for badges, then you can award badges to team members for good performance. Badges are a form of digital recognition; they're a way of patting someone on the back, figuratively, in full view of your organization. You can have a variety of badges that recognize such things as Excellence, Above the Call of Duty, Innovation, Grace under Pressure, Burning the Candle at Both Ends, Road Warrior, and so on.

Awarding a badge may seem minor compared to something more substantial like a good performance review or a raise, but they have the important benefit of being immediate and being widely witnessed by others. At my last place of work, I felt really honored when someone in the company awarded me a badge, and I know others felt the same when I awarded them one. It's a simple, easy thing to do; and they work.

Badges in Social Media

Badges can be used another way besides in-the-moment recognition; they can be used for microcredentials. A microcredential recognizes an achievement or status that a team member has reached. For example, someone who has shown significant innovation could receive the Innovator micro-credential. Whether the requirements for that are a single innovation or repeated innovation is something for the team/company to decide.

Whereas the aforementioned use of badges is mostly a matter of "someone catching you doing something right", microcredentials usually take some effort to attain. A badge is similar to a like, whereas a microcredential is more like unlocking a game achievement. You could use microcredentials for all sorts of things in a software team, for example Build Master, Dev Ops, Certified Expert, Master Debugger, or Published.

Example of Micro-Credentials

With badges and microcredentials, you want to avoid making things too easy: if everyone gets a "participation award", the value of the award is diminished and so is team motivation.

Puzzle Solving

Puzzle solving is a common task in software development that also lends itself to gamification. Whether it's finding the best approach in your design, optimizing an implementation, or diagnosing a bug, those puzzle-solving tasks become a bit more fun if treated like a game.

Another favorite film of mine is Apollo 13. There's a scene in that movie where the astronauts are running out of breathable air because three men are trying to survive in a lunar module intended for two people. Engineering is tasked with finding a way to make the square air scrubber cartridges from the command module work in the lunar module which used round cartridges; effectively, a square peg had to be made to fit in a round hole. Moreover, the team could only use the items the astronauts had available to them on board.

Apollo 13: "The people upstairs handed us this one and we gotta come through."

What I just described was crucial work that if not addressed would have meant the death of three people. But the work can still be formulated as a fun puzzle and I'm sure the engineers took delight in the solution, which involved duct tape, part of a space suit, and cardboard.


For big engineering challenges that are above and beyond normal work requirements, consider prizes. That might take the form of throwing out a challenge across the company and choosing a winner out of the submissions. Doing this allows more people to get involved than assigning the problem to a single team and you get more fresh ideas that way. Innovation just might come from a surprise corner of your organization.

Offering prizes for solving engineering problems is not new. Charles Lindbergh flew solo from New York to Paris to win the $25,000 Orteig prize in 1927. More recently, the XPrize foundation has been rewarding innovators in private space exploration. Rewards can work just as well on a smaller scale within an organization.

Frequent Demos and Feedback

I encourage my teams to do frequent show-and-tell. Even if we're doing Agile Scrum, which is supposed to end with a demo at the Sprint Review, I like to see demos regularly—at least once a week. My selfish reason for this as a manager is to have an opportunity to give feedback and provide any needed course control. However there's also a gamification aspect to frequent demos: having developers regularly show off their work is a form of competition.

I know that I work better and get more done when I am encouraged along the way with constructive feedback. Note that I said constructive feedback, not undeserved praise. Regular demos are a great way to encourage mutual constructive feedback. It's not only enjoyable, it results in better software. Whether demos are an official part of your software methodology or not, I'm a big believer in them.

If your workplace has any notion of setting aside weekly time for developers to play around on their own projects (the idea behind Google's "20% projects"), that's also a great thing to publicize with demos to the team. It gives recognition, the group feedback is invaluable, and it subtly reinforces competition across the team which raises the bar across the board.

Mundane Tasks

Every once in a while I find I have to do something that is very, very mundane and repetitive. It might be promoting a bunch of tasks to another sprint, one at a time. It might be that a long list of statements or data elements in a code editor all need to be massaged in some way.

Sometimes tasks like this lend themselves to automation and sometimes they do not. At times I catch myself and say, Wait! I can write a small program or script and save myself a lot of time. And that's great. But when I can't do that, it's back to the onerous, seemingly never-ending repeated task. I used to just power through such tasks, but more recently I've found ways to make even this kind of work somewhat fun. When I'm in the moment of doing tedious-but-necessary repeated tasks, I can sometimes treat them as a game. What combination of keystrokes or clicks in the editor updates the next statement with the fewest number of interactions? What combinaton of keystrokes is most balanced across the keyboard? Gamification can be applied in many places if you look for it and are sufficiently motivated. It's a form of "Whistle whle you work."

Can Gamification Backfire?

One potential result of gamification is that your team will play the game. The Hawthorne Effect is a phenomenon in which participants alter their behavior as a result of being observed. That is actually what you intend: you're encouraging your team to engage in order to "win"; the gamification's goal is motivation, engagement, competition, and a change in behavior or performance.

However, it's also possible participants will try to win in less honorable ways by gaming the system itself. Consider our earlier example of leaderboards for bug fixes, where the most bugs fixed each week gets you to the top of the leaderboard and the bottom is a place of shame. In addition to the potential abuses already mentioned, anyone with project experience knows that one bug can often be logged as multiple bugs and vice-versa. That means these kind of metrics are susceptible to manipulation when there is bias. When setting up gamification, you'll want to think through potential abuses beforehand and take measures to thwart them; no one enjoys a rigged game. In the case of bug tracking, you might lay down some specific rules about how bugs are to be logged, avoiding duplication, and what the criteria is for claiming they are fixed... before you introduce a leaderboard.


Making work fun leads to happier workers and a better work product. In software development there are multiple opportunities to apply elements of gaming in the course of project work. Today we've examined a few from my own experience.

If you've never tried gamification, give it a whirl. You might be surprised how effective it is to inject a little fun at work. By the way, there's no need to inform a team you're employing gamification techniques; just start to use them and observe the changes in behavior.