Staying competitive in today’s fast-moving digital economy is easier said than done. Operating in a digital environment requires a significant shift in company culture and an agile software environment that accelerates time to value. Creating a DevOps environment helps companies keep pace, but it requires a workforce that is empowered, excited and motivated.
Gamification offers a unique opportunity to continuously engage your workforce by applying game-design elements and game principles into a corporate setting, making work more fun. Companies can develop a team-oriented Pod model that incorporates gamification to improve employee engagement and productivity, enable team members to work more efficiently, accelerate the learning curve and deliver more sophisticated products to market faster.
When I joined Cognizant Softvision as CEO, I wanted to empower our teams and promote a continuous delivery mindset by developing a delivery model that was customer-centric, differentiated and unique to each client without being prescriptive. Thus, Game of Pods was born.
The global, Game of Pods gamification program is designed to provide timely and superior customer service. At a high level, Game of Pods inspires and measures team performance and delivery while encouraging and monitoring individual performance. During competition, the Pod and its members are recognized and rewarded for their collective and individual contributions with badges and trophies.
We typically focus on the output of each pod, rewarding collective behaviors and achievements that help the pod reach higher efficiency and quality targets. Collective badges are awarded to the pod while personal and peer-to-peer badges are awarded to the pod members. Pod badges are earned as a team and are focused on the health of the project, performance of the pod, quality of delivery and alignment with client objectives. A leader board displays the badges each pod earns, their experience points and their trophies. Pod and individual recognitions are celebrated over email and across Facebook Workplace, and shared with all employees.
While perhaps not as intense as “Game of Thrones,” Game of Pods is the epitome of gamification in action and enables organizations to reach a higher level of efficiency and professionalism while challenging employees to achieve personal goals in a fun, team-oriented process. In addition, Game of Pods offers other benefits such as:
A flexible model that can work in any client environment.
Team empowerment that incentivizes teams and individuals to achieve more.
An approach that encourages diverse thinking that recognizes and rewards teams and individuals for improvement.
Game of Pods is most effective in organizations that embrace an agile mindset and understand the need for flexibility in today’s fast-moving environment. While gamification has come a long way, successfully incorporating it into the workplace can be challenging. However, integrating gaming into your organization can empower and excite employees, motivating them to overcome obstacles that might otherwise stand in the way of success and sustainable innovation.
From their inception, new agile digital disruptors have realized the importance of centering their business objectives around value and technology, making it vital for traditional incumbents to follow suit. If waterfall organizations ignore this challenge, their ability to innovate and react quickly to market changes and new customer demands is threatened. To change and succeed, the active involvement from the C-suite is essential to instill a cultural shift, placing value and people (employees and customers) at the center of any transformation.
Sounds easy, doesn’t it? Well, actually, it is.
At the heart of any transformation, there are common themes among agile organizations that, if implemented correctly, can have a major impact on productivity, innovation and the ability to grow market share, while enhancing the customer experience.
Be Value-Driven
Being value- and purpose-driven should be at the center of any organization wanting to be more agile, with a strong focus on the customer. To serve the customer, your organization, team and individual purpose must be explicit and aligned to one another. This ensures that every team member is directing their energies for the same goal to unlock the full potential of the business.
On the surface, you may think this is already happening. Some boards are setting objectives related to the customer or efficiency, but too often this message gets diluted due toaninconsistent approach to determining value and prioritization. Often, decisions are not based around customer value because customer thinking isn’t extended throughout the value chain. Frequently, when decisions are taken in isolation, work that could offer true customer value is missed altogether. For example, fixing certain tech debt is often prioritized without the consideration of customer value, which contributes to waste. Value may be lost due to legacy processes, such as planning, budgeting and forecasting, which can slow organizations down.
A lack of feedback loops and continuous planning can also impact business velocity, with the board needing to listen to product teams, as they are closest to the customer. This ensures that any reprioritization by the board is based on value, which is then filtered down once again, giving the product teams confidence to make decisions that will positively impact the customer. Traceability is increased further by implementing a story hierarchy, allowing everything from initial concepts, features and detailed user stories with acceptance criteria in a structured, easy-to-follow way.
Do
Ask what the value of any initiative is, even at the feature level, making sure it aligns with the organization’s objectives.
Create true transparency of organizational alignment via a consistent hierarchy of work.
Understand and organize around your value, helping teams relate to the customer and your goals. Too often teams are functional or system-based and don’t appreciate the end user experience, making systems thinking harder to achieve.
Don’t
Prioritize based on effort, which is a typical waterfall anti-pattern. Small, easy, quick wins will only reduce the capability to deliver true value.
Set up projects to deal with regulatory change. Consider these as any other non-functional requirements and add to the product teams’ backlog.
Organize in functional silos with work having to be passed between them to be completed.
Create Teams Around Products
In the world of agile, teams siloed by function rather than products don’t work. They’re too removed from the customer, require process hand-offs and often have competing objectives, resulting in work not focused on value. Small product teams stay close to the customer and quickly adapt to sudden market changes and differing customer demands. When done well, these teams are consistently more productive, morale is higher and better-quality products are released to market faster, with a lower risk of failure than traditional methods.
To do this, teams need to be carefully constructed with the right multiskilled people who complement the product, including non-IT roles, such as sales and marketing. They should ideally be no larger than 10 to 12 people or “two pizzas” (see Brooks’ Law), which makes them highly productive and accountable, empowered byclearer visibility and effective collaboration. Organizations with large monolithic systems will find this challenging due to the amount of responsibility placed on the team. Breaking these down into loosely coupled microservices can help by reducing the scope of accountability to a manageable size.
By having teams work this way, products can have funding associated to them, with product teams directly mapping to this. This makes it easier to track ROI, which is a better metric to measure output compared to capex or opex. As a result, legacy reporting needs to change, too; the metrics you really need are cycle time, right first time (quality) and customer experience. These are then used by product teams to understand how they are contributing value. All these metrics can be generated automatically and made available through dashboards; gone are the days when PMs and PMOs need to chase developers for updates.
Do
Value teams and individuals in value creation roles and remunerate them accordingly, considering product ROI. In particular, rockstar engineers should be able to increase ROI, and should be retained at all costs.
Break monoliths down into microservices. These are smaller in scope and more manageable for a single team.
Don’t
Set up project teams, which by nature are short-lived and reduce accountability. Empirical data shows that stable teams are 60% more productive and 60% more responsive to customer input than teams that rotate members.
Track value through project accounting metrics–opex/capex split doesn’t help make decisions, it only creates management overheads that demotivate people.
Create an Engaging Working Environment
Globally, two-thirds of employees are not engaged. This means employees turn up for work but do not apply themselves and offer minimal effort. By having an agile mindset, implementing a set of principles based around value that everyone works to, gives employees the confidence when making decisions. Even if the outcome isn’t exactly what was expected, having a fail-fast attitude can allow continuous learning and improvement to flourish—the only way to evolve is to fail. It also helps create a culture where engaged employees feel valued and psychologically safe.
With an engaged workforce, people collaborate more, helping knowledge and skills to be shared, boosting innovation. This notion is supported by the Medici Effect, where the greatest innovations are created by the “intersection of ideas, concepts and cultures …” This environment doesn’t just have an impact on innovation: According to Gallup Business Journal, engaged employees can be directly related to increased revenue. That isn’t all: Compared with disengaged teams, engaged teams show:
24% to 59% less employee turnover.
10% higher customer ratings.
21% greater profitability.
17% higher productivity.
28% less shrinkage.
70% fewer safety incidents.
41% less absenteeism.
Leaders should make space and time for diverse new ideas to emerge but must maintain an overall sense of purpose. It is their responsibility to help people resist the urge to converge quickly on a solution without feeling they lack direction.
Do
Empower your people by trusting them to do their jobs, which in turn will create value for the customer. As Richard Branson said, “I have always believed that the way you treat your employees is the way they will treat your customers.”
Embrace failure and learn from it. The fastest way to innovation is through experimentation and learning. Delivering in smaller increments reduces the risk and investment and gives results quicker.
Don’t
Assume you have all the answers. Allow your employees to develop a collaboration of ideas to identify one possible solution to a product or process design challenge and find seven possibilities.
Expect innovation to happen in a vacuum. It’s not the responsibility of a few individuals but rather one big team. Value new ideas from your employees and create an environment where innovation can flourish and is rewarded.
Outside-In Focus
Although trust in your employees and understanding their motivations promote increased productivity, if organizations ignore their customer pain points and don’t have the ability to adequately respond to customer feedback, all other efforts will be in vain. Leaders need to consider what is happening outside the organization and be aware of customer demands, as well as market trends and behaviors.
In one of the most recognized cases, Blockbuster’s demise, many consider digital disruption paved the way to administration. In reality, it may well have been the company’s difficulty to innovate quickly enough compared to more nimble competitors. Blockbuster was savvy enough to see the rise of Netflix as a threat, but internal legacy processes made it more difficult to react. When it did act, its traditional way of working led to a proposed solution costing circa $400 million, which led to investors struggling to see ROI, so deemed it too risky.
A more agile organization could have responded quicker and with smaller increments (MVP), making its overall solution cheaper. Further analysis would have also identified that the cost of technology advancement would decrease and support services would evolve. Being set up as an agile organization and assessing outside influences, Netflix had also foreseen the move from the traditional VHS-versus-DVD market to what customers really wanted: video on demand.
This is no longer a choice; all leaders must be aware of outside influences (PESTEL) and emphasize the use of consumer analysis and encourage their employees to put themselves into the end user’s situation. By doing this, agile organizations can adapt to market forces and customer feedback quickly, helping to prioritize the backlog and provide value.
Do
Take feedback from the customer early, feature toggling and canary testing are great ways of enabling this.
Constantly research, analyze and understand the effects outside influences can have with business and customer alignment, and the impact on value.
Respect your competitors and the new kids on the block. They may have seen something you don’t.
Understand how technology can and will change consumer expectations and habits. Evolve your products accordingly.
Don’t
Rely on past successes to survive. Phrases such as, “We’ve always done it this way,” and, “We’re too big to fail” should never be spoken.
Dismiss information (shoot the messenger) because it’s a tough pill to swallow and will require significant change within your organization.
If the above organizational attributes are not realized, the chances are that your business is not agile, so a shift in mindset is necessary to establish a new way of working. This will only happen if the CEO leads from the front, embraces agile personally and creates an engaging working environment where work is prioritized by value and people (employees and customers). Then, and only then, can innovation thrive, boosting productivity and helping your business to react fast enough to changing market forces and remain competitive.
Facing challenges is an inevitable part of life, but how we deal with them can make a big difference. When problems show up, it’s important to focus on the things that unite us—it’s better to have a common enemy than fight internally. Experience in complex software development has taught me that it’s crucial to stop, think and act at regular intervals.
The feedback loop is the concept on which the agile mindset is built. Instead of having a project that is one year long, we divide the project into smaller mini-projects of two to four weeks. As the saying goes: There is only one way to eat an elephant–one bite at a time.
To inspect and adapt quickly, I recommend a time frame of just two weeks. During these two-week sprints, the team must work hard to achieve the goal. At the end of each two-week period, the team meets to inspect progress and creates a plan for improvements during the next sprint.
The purpose of the retrospective is to:
Inspect how the last sprint went with regards to people, relationships, process and tools.
Identify and order the major items that went well and potential improvements.
Create a plan for implementing improvements to the way the team performs its work.
These retrospectives can be general or they can be focused on one issue that occurred during a sprint. Sometimes a retrospective is about de-escalating or resolving conflict and tension. If the sprint didn’t go as planned, the facilitator needs to be cautious about how they run the retrospective. They need to keep in mind how they say certain things, because team members might already have low spirits coming into the meeting.
I stay away from using harsh judgments, blaming specific members or showing my frustration. The goal is to create positive energy for the retrospective. Facilitators should motivate the team to have fun while they participate in the retrospective. I like to have high energy, be positive and try to get the others on the same boat.
As a scrum master myself, I was shocked to find out that only 81% of scrum masters hold retrospective meetings. The retrospective is an essential part of any given sprint and provides valuable information on how to improve.
Preparation
Before the retrospective meeting, I think about the format and tools. If you work in a distributed team, like me, a digital whiteboard is recommended. Using the digital whiteboard, we can have a retrospective no matter where we are in the world.
Here is my process for a zombie retrospective meeting. It’s divided into three steps: check-in, input and output.
Figure 1: Zombie Retrospective board.
Step 1: The Check-In (15 Minutes)
The check-in stage is kind of an ice-breaker. It should be fast, like the starter before the main dish—which in this case would be the deeper and more constructive discussion. Check-ins are treated as an exercise at the beginning of the retrospective to gather information on the just-completed sprint. One nice starter for more in-depth discussion is the happiness index: a quick way to check-in with the team and to see how everybody experienced the last sprint.
I ask the question: “On a scale of 1 to 5, specify how happy are you with the last sprint? No.5 is super-happy, and 1 is totally unhappy. Put the sticky note with one keyword next to the number on the whiteboard.”
Figure 2: Icon made by Freepik from www.flaticon.com
The Scale Is:
5 = Super-happy! Don’t want to change anything!
4 = Pretty happy, but there are some things that need to be fixed.
3 = I can live with this, but there are many things that need to be fixed.
2 = Not feeling so good about this right now.
1 = Totally unhappy, I want out.
I give the team three minutes to five minutes to gather the input, then we discuss the issues. It’s a perfect moment to turn the problem into opportunity. You can use solution-focused questions, such as:
What needs to be done to raise your happiness index?”
Let’s imagine we have an ideal world, what would it look like?
How would you like to have it?
Example:
The team members identified that they are moderately happy because they spend a huge amount of time preparing for the release. The work is boring and repetitive. I then turn the problem upside down and ask how we would like to have it. The team then starts with something they want.
Goal: As a team we want to have automatic regression tests, so that we can have faster releases and use our time for value-added work.
Next, we define action items that will help us achieve the goal—we plan to invest time and implement the automated tests. The product owner will be responsible for managing the product backlog in a way that we would achieve the goal within six months.
The scrum master needs to keep in mind which team members are more open to sharing their opinion and those who are more reserved. Shy employees may have lots of great input, but if they don’t feel comfortable sharing it, they will simply sit back and listen. It’s up to the scrum master to understand the team well and know which team members may need an extra push to be more vocal, to collect the input from the colleagues that are more reserved. The first step is to create an inclusive workplace with a team culture of trust, openness and transparency. You want to reach a point where everyone feels like they’re really a part of the team, and know how their efforts contribute to the team’s success. It’s important to remember the importance of tone of voice and body language and the positive influence this can generate.
Step 2:Team Input (45 Minutes)
There are plenty of techniques to collect input from the team during the retrospective. When I prepare the whiteboard for a retrospective, I look into the different techniques and choose the one that I believe is most fitting for the current context. When we face prevalent problems and challenges, I particularly like the zombie retrospective.
Figure 3: “The Zombie Retrospective” by Agata Matynia. Image representing the zombie retrospective used to support the team input stage. This tool helps teams to visualize problems as part of the journey to aid creative solutions.
With this poster, I explain the following to the team: When a virus turns the human race into bloodthirsty mutants, we need to save ourselves from the zombie attack. We need to think clearly, so our discussion would be split into three groups.
The zombies in the illustration represent the problems that we have.
The blocked chair represents the actions we can take to stop the problems affecting us.
The last place is our hiding place. The TNT explosives, gun and hand grenade represent the team strengths.
Once the team has finished contributing their input, we then go through every idea on a case-by-case basis and discuss it. This stage should take a maximum of 45 minutes.
Following discussion, we then move on to the final stage of the retrospective. This step takes all the input and turns them into concrete, measurable goals with action items, responsible people and clear timelines.
Step 3: Team Output (15 Minutes)
The output stage outlines the goals the team would like to achieve the actions they will take, who will do it and when. The tasks are handed out to the team, and the scrum master needs to delegate people to specific areas with deadlines to ensure that things get done. Otherwise, everyone will agree that something needs to be done, but nothing will be changed.
I use the following format to achieve this:
Goal: The end result the team wants to achieve.
Actions: The action points that need to be done to achieve the goal.
Who: The owner of the goal.
When: The specific date.
Example:
Goal: As a developer team member, I want to gather analytics on how the mobile app is used so that it can focus on things that matter.
Action point: Deciding what information to gather and who will do it.
Who: Anna is the owner of this topic.
When: In the next sprint.
The retrospective at the end of a sprint should never be left out. It allows for the continuous improvement of people, relationships, process and tools. It makes the team great.
Optional Step: Inspect and Adapt the Retrospective in the Plus/Delta Format (10 Minutes)
From time to time, it is a good idea to evaluate the retrospective meeting. The goal is to be able to learn from the current retrospective to do it better next time. For this, I recommend using a quick, simple technique such as Plus/Delta to make improvements.
In this final step, the team identifies the strengths of the retrospective and what changes can be made for the next one. I ask the team to use the sticky notes to share their thoughts.
Plus: What can the team change or add to bring more value to the retrospective? How we can repeat it?
Delta: Is there anything that we should change in terms of how we run the retrospective as a team?
The answers to these questions can give scrum masters valuable feedback on how to bring the team together, solve problems more efficiently and make the best use of the time spent in the retrospective. Up until this point, team members have only been discussing the previous sprint, so giving them some time to reflect on the meeting itself sometimes helps them unwind.
More Ideas to Spice Up Your Next Retrospective
The retrospective meeting is a great opportunity to inspect and adapt. If, like me, you would like to run it every two weeks, you will have about 26 of these meetings in a year. The zombie retrospective is great, but you should avoid using the same approach every time. Get as creative as you like—there are many variations and possibilities worth exploring.
For check-in, I also like to utilize pain scales, a common communication tool used in a variety of medical contexts and settings. Trust me, it also works perfectly in business. Try the LEGO pain assessment tool as a starter.
