Using Kudos Cards to Recognise and Motivate Your Colleagues

Using Kudos Cards to Recognise and Motivate Your Colleagues

We’re living in a world where economy has been constantly affected due to one thing after another. There have been natural calamities such as floods, Bush fires, typhoons, earthquakes and as if those things weren’t enough, we are now dealing with a virus that doesn’t seem to stop creating havoc. 

A suffering economy means that people’s livelihoods have been affected. Mostly in an unfavourable way unfortunately. That also means that our motivations have taken a hit too.

Those who are still working might be dealing with anxiety, stress and panic and they may not even know about it. In such circumstances where people are dealing with heightened emotions, keeping their motivation high becomes difficult and even more important. 

What can we do so that we can help our colleagues, peers and friends motivated?

The Factory School of Thinking for Reward and Recognition:

Traditionally, organisations have been using monetary awards for rewarding or recognising employees. The old school thinking has been that if someone has demonstrated good behaviour, or has done some good work, offer them some money and they will be happy. The management also believed that if one person got a reward, that would motivate others as well.

Contrarily, the monetary awards often made a situation worse. That created a rift among employees. It seldom happens that everyone celebrates one person’s success. In some cases, one person’s win is also seen as everyone else’s loss.

We humans have tendencies to laugh at others’ misery. Don’t believe me? Remember the last time you laughed at someone who slipped and fell. That might even be in a TV show. Schadenfreude is a real thing unfortunately.

What Should Companies Do? 

Motivating employees and keeping their morals high is not an employers job only. Since we are all in these troubled times together, each one of us has to do our bit to improve our work practices, keep our work enjoyable and keep our colleagues in high spirits. 

How do we do that?

There is a simple and effective way of doing that and that is called Kudos cards! These are also known as Hero cards but let’s stick to ‘Kudos’.

Paraphrasing Management 3.0, Kudos cards are a written and public expression of appreciation and recognition of a team member for something that has contributed to the team.

As an employer, what you can do is either buy a deck of cards for your teams or provide them with a virtual or online version of Kudos cards. That would be a very little expense for a large gain. 

Kudos Cards: An Effective Way to Increase Intrinsic Motivation:

Jurgen Appelo is the creator of Management 3.0 methodology, which is a way of modern management thinking. This is what Management3.0 says about Kudos cards

Kudo Cards are simple cards that play the role of a physical token of appreciation. The cards can be placed in a box, and every now and then the Kudo Box is emptied and the workers celebrate those who had received a card.

Kudos cards are simple notes that focus on one and only one attribute. For example, they may show “Well Done”, “Thank You”, “Great Job”, “Congratulations”, “You’re Awesome” etc. Who wouldn’t love being recognised as a badass by their colleagues?

In their physical form, they look like this:

If you and your colleagues work remotely, consider using an online version of these cards. These cards are available for free download from the Management 3.0 website. There are several other websites that allow you to do it for free or for a small fee, for example Kudoboard (https://www.kudoboard.com/).

If you use Trello, Microsoft teams or Slack, they can also be very effective tools for Kudos.

One of my teams created a separate channel in Slack for Kudos and another one used Microsoft Teams Planner for that purpose. In fact, I found that using Slack was a fantastic idea considering that it was constantly in use. 

You can also create your own card in PowerPoint or other drawing tools. The idea is that since the receiver feels appreciated, it is highly likely that they would prefer keeping the card as a memoir. In one of my teams, we used to stick the physical cards to the wall (please see the photo). However, some people decided to take them home because they were proud of their achievements and wanted to show the cards to their friends and family. Isn’t that nice?

Why use Kudos cards: 

I have been using kudos cards for a while now and what I have experienced is that when team members do recognition of each other, the feeling is much more stronger and the positivity lasts longer. It is completely opposite to what I have observed with management rewarding employees on special occasions.

When team members recognise each other, they feel appreciated. They believe that the recognition is honest because that is based on the work or the deed they have done. It is all fact based. Another good thing about mutual recognition is that they don’t have to wait for a ceremony. There is no need for a quarterly or annual function. Employees take care of their own happiness.

Some observations about when to use Kudos Cards:

First of all a word of caution. Don’t use Kudos cards too much because then they’ll lose effectiveness. Also, you should only give a kudos card to someone who has done something right in terms of contribution and you really want to recognise their effort. These cards are for genuine and honest recognition. Without honestly they are worthless.

What I have experienced is that each team creates their own timeline, space and frequency for recognising each other’s work. 

In one of my teams, they used Scrum events like Sprint Review and retrospectives for recognising their colleagues. Another one decided to use every possible opportunity to use them. It totally depends on the team.

Luis Goncalves has written a post about how Agile teams can use the cards in Retrospectives. Read it here.

What might be useful for a team is add something about Kudos cards or regularly recognising team members in their social contract. If you do not know how to create a social contact or a working agreement, visit this page. Since teams do or should refer to their social contract frequently, that should remind them of using the cards regularly.

In conclusion, I believe that Kudos cards are a very effective way of appreciating your colleagues. These cards help improve team bonding, generate positivity, enhance collaboration and peer to peer relationship. There’s no rule for not using them for recognising your boss or an employee through them, but you’re the best judge for their usage and your context. In difficult times, we have a responsibility to support our colleagues and peers. Why not use Kudos cards for that.

If you have used Kudos cards effectively, let me know by adding a comment. 

How to create a social contract that works

How to create a social contract that works

Good Agile teams are self- organising where all ideas matter, everyone contributes and everyone is heard! 

For becoming a high-performing and self-organised team, a lot depends on how team members work together and how good of a shared understanding they share. In complex Agile working environments, it is not easy to rely only on technical skills and attention should be paid on creating cohesion. This is where social contract comes into picture.

 A social contract (also known as working agreement) allows Agile teams to define and agree on the acceptable and non-negotiable behaviours.

 In this post, we’ll look at following points:

  • What is a social contract or a working agreement?
  • Why do you need a social contract?
  • Who creates the Social contract?
  • How and when to create a Social contract? 

What is a social contract or a working agreement

A social contract is not a legally binding agreement. Instead, it’s a socially binding one. What that means is that each person in a team agrees and adheres to certain behaviours that the team mutually creates. Social contracts are unique to a team because each team has people with different personalities, idiosyncrasies and objectives.

Below is an example of a social contract: 

 You can also add other, more specific topics in your social contract. One of our contracts included these:

  • No open laptops in meetings
  • Meetings are not scheduled between 3-5 PM
  • No mobile phone in meetings or team discussions
  • Update cards daily on the wall (later we edited that to include MS Teams and Jira)

An important point to note is that social contracts should not be created and used as a box ticking exercise. Instead, they should be adhered to and revisited as often as required. If you’re a physically co-located team, place the agreement somewhere where it is visible to everyone. If you’re all working remotely, make it a part of your shared area where it is easily accessible and visible.

Why do you need a social contract

 Long time ago, we had a developer in our team who used to disappear during the mid-day when most of the teams were on lunch break and used to return after nearly an hour and half. Not only that, he used to leave early to pick-up his child from the day care centre. It was a concern for most because there was enough dependency on this developer and his unavailability was affecting others.

What would you do if you were being affected in this team?

Our team decided to use the social contract to remind everyone of their commitments.  In one informal meeting (it’s important to note that such discussions are more effective when not done in a formal setting), while chatting with each other team members asked him about this developer’s long breaks. It turned out that he was utilising his lunch break for visiting a gym and wasn’t aware that others were being impacted by his absence.

Because of a social contract where all were free to respectfully share their views, we were able to avoid what could be a difficult discussion.

What I have experienced is that social contracts help build psychological safety, openness, shared understanding, trust, congruence and a sense of accountability.

Who creates a Social contract?

Many teams have their social contracts created by someone in the management or the human resource (I guess calling it People & Culture is better) teams. Well, that’s not how a team contract should be created.

 For a team to become self-organising in a real sense, it is important that they define their own ways of working and guidelines. When the team creates their own standards, they will own it and will be committed to it. Creating and owning something collectively also helps teams establish better relationships with others.

  

How and when to create a Social contract?

A team should create a social contract when it is forming. However, many teams constantly grow and there may not be a single, common beginning for all team members. In that case, the core team or the group of people who join the team in the beginning should create a social contract. This core team should also ensure that every time a new team member joins them, they are given a walkthrough of this contract by other team members. They should also feel safe in reviewing and contributing to this contract. If that happens, the social contract will work in favour of the team.

 

Tips on how to create a social contract:

  • Get together as a team. If teams are located remotely, ensure people are able to turn their videos on. For such an important discussion, it is vital if team members can see each other.
  • Collectively choose someone who can facilitate the discussion. Social contract discussion can generate debates and having a good facilitator will help everyone stay on track. A facilitator will also help in ensuring that all get a chance to speak up. The facilitator does not have to be a delivery leader, a scrum master or a coach.
  • You may ask each team member to write what they expect from everyone in the team
  • If the team is located remotely, use a tool like Whiteboard Fox or Miro to collect ideas.
  • As a team, decide what common behaviours the team accepts as a minimum. 
  • Agree on what are non-negotiable behaviors.

Social contracts are mutual agreements and they should be enforced by the team. They are not pretty posters that teams use to appear Agile. These agreements are to build trust and to reinforce the feeling that a team is empowered and is in control. They also show that the team does not need to be controlled or commanded by someone in the organisational hierarchy.

It is also worth noting that these agreements do not replace organisational policies. Those policies are the boundaries within which teams function. Instead, working agreements are there to enhance the cultural aspects of an entity.

Do you have a social contract with your team? What is your experience from using it? 

Additional reading: 

If you are curious about the term Social contract and where it came from, a good starting point is Wikipedia. It is quite interesting too.

Although not directly related to Agile delivery, the text on Wikipedia speaks about the social contract theory or model as defined in moral and political philosophy.  One can argue that the statement below indirectly applies to how we behave in teams: 

“Social contract arguments typically posit that individuals have consented, either explicitly or tacitly, to surrender some of their freedoms and submit to the authority (of the ruler, or to the decision of a majority) in exchange for protection of their remaining rights or maintenance of the social order.” 

To learn more about the Social Contract Theory, visit these links:

https://www.iep.utm.edu/soc-cont

https://politicalsciencelessons.com/social-contract-theory-by-thomas-hobbes/

https://www.reference.com/world-view/thomas-hobbes-social-contract-theory-1c0d40a2e08398e2

 

 

It’s not Agile that fails organisations. It’s the organisations that fail at agility

It’s not Agile that fails organisations. It’s the organisations that fail at agility

Agile has been touted by people (who understand it) as an approach, a value centre, a mindset and philosophy. Those who understand, have been observing some interesting posts and discussions going on social media that claim that Agile has failed in their organisation.
If we regard Agile as a tool that a team or organisation might choose to use, then perhaps we can understand the failure of Agile for that organisation. That’s be similar to any other tool that an organisation might use.  Sometimes tools work, sometimes they don’t! Understood! A hammer can certainly fail a carpenter if it breaks during carpentry work. But, if the carpenter does not know how to use a hammer, it is not the hammer’s fault, or is it? (Just too be clear, this analogy does not represent Agile as a tool).
Let’s not jump too prematurely to any conclusions. Instead, let’s try to cognitively analyse if there is a problem here. Jerry Weinberg’s Rule of Three* states that if you can’t think of at least three different interpretations of what you have received, you haven’t really thought enough about what it might mean. Another version of this rule that my friend Jari Laakso suggested was, “If you can’t think of three things that might go wrong with your plans, then there’s something wrong with your thinking.”

When someone says that Agile has failed them (in other words, their Agile way of working was not successful), the actual problem might have been:
They don’t know enough about Agile and they tried to “do Agile” rather than “be Agile”.
They thought that they knew about Agile and implemented it the way we knew it. What they did didn’t work. (Rajesh’s note: you don’t implement Agile in the same way you don’t implement truth.
They thought Agile was predominantly about specific practices and conventions: using post-it notes, having daily standups, having sprints and not much else. Despite those they couldn’t deliver anything.In some contexts, any (or all) of these cases may have been a key contributor to the failure of Agile.
What troubles me is that many people who blame an approach or a methodology, do not in fact try to first understand that approach or methodology.** There was a mention of waterfall methodology somewhere and most people in the discussion did not know about waterfall’s origin. Someone mentioned Winston Royce and disappointingly it turned out that even that person had selective take of the paper and decided to conveniently forget about the last few sections of Royce’s paper which are very important.
More often than not, Agile methodologies are implemented incorrectly. Some implementers don’t realize that there are Agile values and principles (Jari reminded me about ScrumButs). Some have not taken time to look at and understand the Agile manifesto. Many Scrum Masters never looked at The Scrum Guide. Some didn’t even know it even existed. I have done this experiment of asking anyone who mentions Agile whether they have actually read the manifesto. A large number of those had not. Many of those who had read the manifesto, did not try to  understand it well. Sadly those who understood it, could not implement what an approach as outlined by the Manifesto, because their organisations weren’t ready.
It is indeed often easier to blame a methodology or an approach. Agile adoption and implementations of related frameworks can fail for many reasons. What is important is to investigate what went wrong and whether that could be avoided. Even more important is to understand an organisation’s culture and whether the organisation and the approach are good fit for each other. Jerry says in his second rule of consulting, “No Matter how it looks at first, it’s always a people problem.” A good Agile coach might be able to help bring a mindset change if not the culture change.

So, as often the case may be, Agile hasn’t failed you, you may have failed Agile.

 

* The Secrets of Consulting: A Guide to Giving and Getting Advice Successfully

 

** http://www.slideshare.net/EmielVanEst/did-toyota-fool-the-lean-community-for-decades

Why improving culture can bring dramatic results

Why improving culture can bring dramatic results

 

It is not surprising that at many organisations, mainly in difficult cultures, management teams increase their focus on individuals and teams when things do not work out. They believe that to resolve any issues or to improve a situation, they need to fix people. While in some cases people related issues might need to be resolved; in many more cases leaders should focus on  improving the systemic issues and the culture of the workplace.

 As a delivery professional, and specifically as an Agile delivery professional, you will face situations where things will not be working out for your teams. There can be many reasons behind those issues, but pay special attention to systemic and culture issues. This post helps you decide whether to be a part of the problem or be the wise person who offers solutions.

 Have a look at this famous quote by Alexander Den Heijer*

 “When a flower doesn’t bloom, you fix the environment in which it grows, not the flower.” 

 What this quote symbolizes is what happens at many workplaces. We see that when a problem appears, the management teams get so involved in the lower level details that it becomes harder for them to see the forest for the trees. In other words, they can’t see the bigger picture. This results in either applying short term fixes or fixing the wrong problems.

 It is true to an extent that many managers find it rather simple to find faults in the teams. Local fixes are easier to apply and they can be shown as quick wins. These quick, local fixes are the low hanging fruits and they are quite attractive because they make managers look good in front of their peers and superiors. It’s amusing how culture of a workplace can affects people’s behaviours.

 It is hard to identify and detect systemic issues. When managers have a narrow view of things, when they are not trained in looking at the bigger picture and think critically, they tend to ignore the signs that the system might be showing them. The issues might be with systems, suppliers, other managers, expectations, equipment, skills or any other things.


Challenges for organisations and delivery folks:

 The challenges that organisations and teams face in solving long term problems are:

 – attractiveness of applying the quick fixes
– incompetence of managers in identifying the right problems, and
– ambiguous nature of systemic issues

Below is an example from my personal experience how management ignores systemic issues and focuses on low level details.

I was once invited to a financial institute to do an assessment of how the Scrum Masters were performing there. The person who commissioned the work told me that the company wanted their teams to improve. Through this assessment, they wanted to see which areas needed further support or training. But, being a sceptic, I was curious to know whether the management was genuinely interested in helping their teams improve or this assessment was a ‘performance review’ in disguise. I didn’t know whether this activity was also going to be used as a ‘right sizing’ tool.

 My assessment process included interviewing various people to get a holistic sense of the working environment. After meeting the scrum masters, program managers, product owners, peers and colleagues, I noted that there were many improvement areas. One of them was additional training for scrum masters, but there were many others which were more work-environment related. What was interesting was that these folks had no control over the issues affecting their work. Most of the problems that were slowing the teams down and impacting product delivery had nothing to do with these scrum masters. Almost everything was an organisational issue. 

When I sent my report to the person who commissioned the work, she completely ignored the recommendations related to the organisational issues and decided to action only what was written about the team members. 

As expected, nothing actually changed for them.

 

What should leaders focus on?

 Local sub-optimisations can only produce sub-standard outcomes. If you are an executive or a delivery manager, don’t spend much energy on improving efficiency and productivity of individuals (or individual teams). Those things have limitations. Although you do need to solve the immediate issues. Once that is done, Instead, try to understand the dynamics of your systems. If you face a challenge, pay attention to how your overall system is behaving. 

 Can you pick different sentiments in people’s attitude? Do you see that vocal team members have stopped talking? Are teams reluctant in experimenting? Have the number of sick days increased? Have people stopped challenging you or offering suggestions? Has productivity dropped? Is the work produced by teams appear to be of lower quality than it was before? Do you notice a lack of collaboration and cohesion among all levels of people and teams? Have people started keeping record of interactions ‘just in case’ if they had to ‘prove’ something? Has the learning stopped?  

 The list of questions can be very long. All of these questions are the symptoms of larger problems.

 It takes time and effort to understand the patterns and behaviour of a system, but the results, impacts and effects are often better & long lasting.

 How to identify and action systemic issues:

 As a delivery professional, it is imperative for you to learn and experience practices and techniques for systemic issues. Initiatives, projects, assignments and products can vary in size and complexity. You will have to choose the right tool for the right context. I have provided some suggestions below. 

 Systems mapping: Most initiatives have dependencies and interdependencies on a variety of things. These include people, processes, vendor suppliers, equipment, government compliance and regulations, technology, market forces etc. 

 It is a good idea to create a systems map to understand the breadth of your solution. Specifically for large initiatives with multiple touch points, creating a systems map is vital. Once a basic map is ready, other team members can add details that you might have forgotten. Systems maps help leaders see the forest and not just the trees.

 Group mind mapping: You can start your project with a mind mapping exercise with the core members of your team. A mind map not only helps you develop your ideas, it also helps you reveal the potential outcomes or problems. 

 Brainstorming, decision making and problem solving techniques: I have used techniques such as Lotus Blossom for decision making and problem solving. Lotus blossom is a structured way to explore areas which are high stake and require deeper thinking.

 Collaboration techniques: To improve the culture of your organisations, you should apply team collaboration techniques that improve coordination and psychological safety. Once your team members feel safe to speak out and share ideas, you will notice the substantial benefits for your projects.

 You might already know many of the suggestions I have provided in this article. My job was only to give you a nudge and hope I have done that through this article. What has been your experience at applying practices that have helped you improve the culture of your team or the workplace? Please share your ideas in the comments below. 

* Alexander Den Heijer is a well known motivational speaker and the author of Nothing you don’t already know: Remarkable reminders about meaning, purpose, and self-realization