So why don’t we recognize employees more?

As a manager, you want to keep these top performers and let them know about the great work they are doing.  Recognition motivates employees and gives them a sense of accomplishment.  They are more likely to do more and stay with the company. It’s also a way to show other employees what success looks like.

Giving recognition is easy and can be budget friendly.

3 Easy Ways to Recognize Employees:

1. Thank you cards with lapel pin

As an employee, I appreciated receiving a nice thank-you note from my manager or leader in the organization.  It was the simplest way to show appreciation and I felt great that they were noticing my work. I was making a difference and wanted to do more.

A modified version of a thank-you note is an appreciation card with a lapel pin.  The pin acts as a token of appreciation and can be worn on a lanyard with the employee’s badge, displayed at their desk, or put onto a laptop bag or backpack.  Here is one that Agile Inspirations offers on Amazon.

2. Recognition Wall (aka Big Ups or Snaps)

When my team had low-morale and felt a lack of recognition from the organization as a whole, I implemented a recognition wall, something I called ‘Big Ups’.  Big Ups was the motion of ‘raising the roof’ to show appreciation, something like ‘Snaps’ from the movie Legally Blonde.

Since the wall was highly visible, anyone who walked by the wall felt compelled to stop and read the kind words we had to thank and appreciate the good work being done.  This created more visibility into the team’s efforts and what they did day-to-day to make a difference.  Sometimes there was some humor sprinkled in for some additional fun and laughs.

Materials needed: a wall or whiteboard, sticky notes, and markers.

Have sticky notes and markers available for your team near a wall.  When someone sees another person on the team going above and beyond, increasing sales, saving an account, being proactive, etc., write a note of appreciation and post it on the wall.    For example, Anne mitigated a critical issue on a project and was proactive to fix the issue in a timely manner.  As a manager, you may not have known about this accomplishment, but Brian who sits next to Anne does and writes a sticky note and puts it on the wall.  Anne is recognized for her efforts that others may not have seen.

3. Awards for the next all-hands meeting

A higher visibility way to recognize employees is to implement certain awards such as Innovation, Leadership, Teamwork, Quality, Customer Focused, Above & Beyond, etc. or values aligned with the company.  This provides recognition to a larger audience.  For example, in one organization, teams worked in different locations and aligned with different business units.  Recognition at an all-hands was a great way to show appreciation for the teams across the organization.

An easy way is to send a survey using Survey Monkey or Google Forms and have employees nominate peers that they see demonstrating the values in each award and write a little blurb on why. After the deadline to submit nominations has passed, the results can be determined by popular vote or by management.  Carve out time in the next all-hands meeting to announce the winners.

The bonus is that there is feedback for all the other nominees and this can be shared later in a one-on-one meeting.  It’s also great to use for annual reviews.

Do you have other ways you recognized your peers or employees?  Let us know!

The post 3 easy, budget friendly ways to recognize employees appeared first on Agile Inspirations.

When a group of people gather for a large amount of time, we want to make the working session as efficient and relevant as possible.  Using concepts from Scrum, you can create a truly effective and engaging session.  Here are some guidelines and tips for running a working session in an Agile way.

Preparing for an Agile Working Session

Materials Required:

A wall, whiteboard, or easel pad

Sticky Notes Note: 4″ x 4″ pads work best

Pen

To Do:

1. Have a list of agenda items and/or topics. You can start with your own and also ask the group what they want to talk about.  Tip: Sometimes sending a survey with topics and having people vote can also help prioritize topics.
2. Prepare a few slides on the purpose of the working session and intended outcome.
3. Try to outline the agenda items and timing around them. Remember to include breaks, meals, and time to regroup or summarize.  Also, have time in the beginning for introductions, goals, and ground rules.
4. Write each topic on a sticky note and create an Agile board of ‘To Do,’ ‘In Progress,’ and ‘Done.’
5. All topics should be in the ‘To Do’ column of the Agile board.

During the Agile Working Session

1. Make sure your Agile board is ready.
2. Start the meeting with introductions and discuss ground rules and goals.
   • Ground Rules – These are guidelines for the meeting such as:
     • Be open
     • Participate
     • If a topic and/or question has been discussed for more than 5 minutes, then we’ll add it to the parking lot
     • Tip: It’s good practice to ask the group to see if they have more ground rules to add. Another way is to have the group write additional rules on post-it notes and place them on the wall.
   • Goals
     • This should be the agreed upon outcome(s) for the meeting
     • Tip: It may be a good exercise for everyone to write down on post-it notes what their goals are and post them on the wall. This way everyone can participate.
3. Running the meeting in an Agile fashion
   • With each topic on its own sticky note, pick one note and let the group know this is the topic being discussed and put it into the ‘In Progress’ column.
   • As a group, agree that the topic is ‘Done’ when everyone gives a thumbs-up which means that the topic has been discussed to satisfaction. If there is a thumbs down or thumbs sideways, then the topic still needs to be discussed or there are additional questions.  Tip: If a topic has been discussed for more than the allotted time, consider putting the topic into the parking lot.
   • Put the topic in the ‘Done’ column when you get thumbs-up from everyone.
   • Go through each topic in this manner.  Tip: Add stickies for Breaks and Meals. 
4. At the end of the working session, thank everyone for coming and for the progress made. Recap the topics and parking lot items.  Capture action items, owners, and ETA.
5. Go out and celebrate!

After the Agile Working Session

1. Send out meeting notes. Tip: Sometimes it’s good to designate someone to take notes during each topic and possibly rotate note-taking responsibility.  Usually, it is not a good idea for the facilitator to be the note-taker as well.
2. Create action items and start following up with owners.

When using Agile for a working session, it engages everyone and ensures participation.  By seeing all the topics discussed, the group will feel quite an accomplishment. You will also see a more lively meeting with a more effective outcome.

The post How to Facilitate an Agile Working Session appeared first on Agile Inspirations.

When I see a highly effective Agile team working, I think of High-Performing Teams.  The way I define a high-performing team is:

A group of people with diverse backgrounds, aligned with and committed to a common purpose, who consistently show high levels of collaboration and innovation, that produce superior results.

Let’s break this down a little bit:

“A group of people with diverse backgrounds”

To me, diverse backgrounds does not have to mean different ethnicity or gender, it could also mean different education, religion, political views, places we’ve been, and other aspects that shape us to who we are.  I find that when I work with a diverse group of people different ideas flow, there are different perspectives, and many times they are better than anything I could have thought of on my own.

“aligned with and committed to a common purpose.”

It’s important for a group to be aligned and working towards the same goal.  When there are different agendas in a group, it leads to confusion and chaos.  And likely will not produce the results expected.

“who consistently show high levels of collaboration and innovation.”

This is related to communication in a few aspects.  These aspects are listening, expressing ideas, resolving conflicts, and being vulnerable.  These things lead to collaboration and innovation. Sometimes when you see the end result of a product, you know if a team worked well together or not.  This can be seen by the quality of the product, does everything fall seamlessly in place, are there very little defects, does the product work as expected or even exceed expectations.  If so, this was a high-performing team that created this product.

Characteristics of a high-performing team

When I see a high-performing team, these are the characteristics and actions of that team.

1. Mutual trust
2. Alignment around a common objective/goal
3. Lively meetings and discussions
4. Ability to manage conflict
5. Make high-quality decisions
6. Leadership involves and engages all team members
7. Puts team above self

To help picture a high-performing team, sometimes I like to picture the opposite or a dysfunctional team.  A friend suggested I read this book when I found myself questioning why the team I was working with felt so difficult and hard.  The book is called: The Five 5 Dysfunctions of a Team: A Leadership Fable by Patrick Lencion

5 Dysfunctions of a Team

In the book, there’s a pyramid of the 5 dysfunctions and how each one builds up on the other to create a dysfunctional team.

Dysfunction #1 – Absence of Trust

The foundation of a team is trust.  Trust is more than believing that someone will do what they say they will do. It’s also about being vulnerable.  Being vulnerable is being able to admit you were wrong, be able to ask for help, and be able to say I don’t know.  It’s also about showing up and being able to disagree.

Dysfunction #2 – Fear of Conflict

When a team member is afraid to speak his or her opinion because of repercussions, this will spell trouble for the team. Having conflict is natural and it needs to be addressed. I’ve seen this when there is one person on the team that has a strong personality or has the loudest voice.  Sometimes we shy away from disagreeing because of the uncomfortable situation this may create and decide to follow this person anyways.  But what happens when this person is wrong?  Could that be more disastrous for a team?

Dysfunction #3 – Lack of Commitment

Have you been on a team and it seems like someone has ‘checked out’? It seems like he/she is not aligned with the same goal as the team.  This can lead to people feeling like some are not pulling their weight and wonder if he or she should put their best effort into the project. Quality may slip, some team members may have a different agenda and different goal they are trying to attain and before you know it the team falls apart.

Dysfunction #4 – Avoidance of Accountability

If the team can’t keep each other accountable, this leads to underlying issues that will come up. People should deliver what they say they will or let others know why they can’t. If this doesn’t happen, it also leads to resentment.

Dysfunction #5 – Inattention to Results

Last, if the team doesn’t care about the results, how will things improve or get better? This leads to complacency and the best work or superior results will not be delivered.

In a high-performing team, none of these dysfunctions exist or the dysfunctions are addressed.

The post High-Performing Teams are Highly Effective Agile Teams appeared first on Agile Inspirations.

Servant Leadership is a term that comes up from time to time in talking about
Agile. What is Servant Leadership?

“The servant-leader is a servant first… It begins with the natural feeling
that one wants to serve, to serve first. Then conscious choice brings one to aspire to lead.

 The best test…is: Do those served grow as persons? Do they, while being served, become healthier, wiser, freer, more autonomous, more likely themselves to become servants?”

— Robert Greenleaf

In other words, it’s not about the leader, it is about the team.

Many of us have experienced a more traditional approach in leadership in which the leader tells the team what to do and the team does it (i.e. Command and Control leadership). Does this mean that in Servant Leadership the team tells the leader what to do? Yes and no.

Command and Control vs Servant Leadership

A good metaphor to compare the difference between Command and Control Leadership and Servant Leadership is a factory vs R&D lab. In a factory, there are widgets that need to be made in a certain way, and the goal is to produce these widgets as a fast a possible. Things are controlled and more like a machine. Typically, there is one boss to direct and ensure the factory is running smoothly. This is a Command and Control approach.

In a R&D lab, a team is experimenting, trying to figure out what works and what doesn’t. There is no set way to produce yet. Things are very uncertain and to improve after each experiment the team needs to work together and discuss what to change or keep the same. Typically, a leader facilitates this and removes impediments to keep the team moving forward. This is a Servant Leadership approach.

Comparison Table

Below is a comparison of Command and Control and Servant Leadership in different dimensions:

Servant Leaders and Agile

As companies face changing priorities, Agile development practices have become more important to help an organization succeed. Things are not as certain and do require some ‘experimenting’. In this environment, Servant Leaders act differently than a Command and Control leader.  A Servant Leader listens, facilitates, and encourages his or her team. On the other hand, a Command and Control Leader takes control and tells his or her team what to do, sometimes dividing the work among the team without telling the whole picture.

The Servant Leader creates a culture of innovation, collaboration, and agility. Of course, there are times when Command and Control Leadership is needed, an example is when ‘the house is on fire.’ In this instance, if there is an emergency or issue that needs immediate attention, it is better to have a leader that can tell the team what to do in order to respond quickly.

So, which leader would you rather work for? I can say from my experience, I would rather work for the Servant Leader. This leader makes me feel valued, my ideas matter, and I’m contributing to the team. At the end of the day, I just want to feel like I belong and I’m contributing.

The post Servant Leadership in an Agile Culture appeared first on Agile Inspirations.

What is Radical Candor?

There are four ways of giving feedback and this can be pictured as quadrants where one axis is the degree in which someone challenges directly.  And the other axis is the degree that someone cares personally.

Ruinous empathy is where someone cares personally, but does not challenge.  This person is too nice and essentially does not give any useful feedback. Without any constructive feedback, an individual most likely will not change his/her performance or worse, the individual may think he/she is doing a great job and continue.

Manipulative Insincerity is where someone does not care personally and does not challenge directly.  This person would say something to your face and then another thing behind your back. It could create a toxic environment and feedback may not be taken seriously.

Obnoxious Aggression is where someone challenges directly and does not care personally, this person could sometimes be viewed as an a-hole or someone that gives mean feedback. There may be truth in what is said, but the delivery could use work and would likely fall on deaf ears.

Radical Candor, the preferred approach, is where someone cares personally and challenges directly, this is constructive feedback. It’s an effective approach in changing performance.

This scenario below may help in understanding each type.

Scenario:

• There is a software upgrade project which will impact many cross-functional teams since they use the same system in different ways.
• The software needs to be upgraded because the company will no longer receive support on the current version.
• The Product Owner (PO) for this project has set-up a kick-off meeting with leads from various cross-functional teams.
• On the day of the kick-off, one critical Team Lead does not show up and does not let the PO know ahead of time that he would not attend.

Key Players:

1. PO for the project
2. Team Lead that did not show up
3. Agile Manager that is the direct manager for the team lead.

What would you do as the PO for the project? What do you do as the Agile Manager for the project?

Outcome #1:

The Agile Manager and PO discuss and agree the Team Lead should either have attended the meeting or sent a decline out of courtesy/respect.

Instead of saying anything to the Team Lead, the Agile Manager decides to talk to others about the situation and talks poorly about the Team Lead for lack of respect.

→ This is Manipulative Insincerity.

Outcome #2:

The Agile Manager does not agree with the feedback from the PO and becomes defensive.

The Agile Manager says nothing about the kick-off meeting to the Team Lead and tells the Team Lead that he/she is doing a great job.

→ This is Ruinous Empathy.

Outcome #3:

The Agile Manager actively listens to the PO and will take action.

When the Agile Manager sees the Team Lead, the Agile Manager starts yelling at the Team Lead to attend all meetings in front of others.

→ This is Obnoxious Aggression.

Outcome #4:

The Agile Manager actively listens to the PO and will take action.

The Agile Manager talks to the Team Lead 1:1 and discusses the kick-off meeting that was missed. The Agile Manager provides context on why it’s important to attend meetings or let the organizer know he/she cannot attend.

→ This is Radical Candor.

From the four outcomes, Radical Candor has the most effective result and is the best approach.  It could take some more time or action, but it is worth the effort.

The post Radical Candor for Agile Managers appeared first on Agile Inspirations.

Exercise 1: Making a Fruit Salad

Your team has been tasked to make a fruit salad and these are the types of fruits that need to be cut and prepared:

• Pineapple
• Banana
• Grape
• Orange
• Strawberry

Compare these fruits and estimate the relative size of each fruit.  List from smallest size to largest size.

Talking points after the exercise:

• If the team was tasked to determine how long it would take to cut each fruit, would it have taken more time to estimate or not?
• If there are multiple teams doing this exercise, look at the result for each team, are they similar?
• Would it be easy to add another piece of fruit such as Apple to the list and be able to estimate the size?

Exercise 2: Animals

Compare and estimate the relative size of each of these animals using the Fibonacci series (0, 1, 2, 3, 5, 8, 13, 21, 34, 55).  Guideline Dog = 2, Horse = 5.

• Lion
• Horse
• Cow
• Tiger
• Zebra
• Pig
• Elephant
• Rat
• Sheep
• Dog
• Snake

Talking points after the exercise:

• Were there disagreements on sizing and how did the team resolve them?
• Were some animals similar in sizing? Did the team use a technique to group animals of similar size together first and then determine the number in Fibonacci (size)?  If not, would this technique be useful?
• Would it be easy to add another animal such as Cat to the list and be able to estimate the size?
• If there are multiple teams doing this exercise, look at the result for each team, are they similar?

The post Agile Estimation Exercises for Your Team appeared first on Agile Inspirations.

Types of estimation

1. Time Estimation
   • This estimate is typically given as a unit of time (i.e. days or hours).
   • To get ‘accuracy,’ the team needs to get into the details, which could lead to a large amount of waste.
   • Different techniques: 3 Point Estimation, Top-Down Estimation, Bottoms-Up Estimation, Parametric Model Estimating
   • Typically done up-front for a project and done once.

2. Relative Estimation also known as Affinity Estimation
   • The estimate is based on a function of 3 factors: effort, complexity, risk.
   • Based on size or comparing and uses a value or point system such as:
     • Fibonacci: 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89
     • Power of two: 0, 1, 2, 4, 8, 16, 32, 64, 128
     • T-shirt: XS, S, M, L, XL, XXL
   • Can be done quickly which reduces planning time.
   • Is done continuously throughout the project.

As humans, we’re typically better at comparing things than giving the amount of time something will take.  For example, in a team, team members will more likely agree on the size of something than agree on how much time something will take.  This is important in Scrum when the team needs to iterate rapidly and needs to adapt to changes. Relative Estimation is better because over time it produces more accurate estimates and release dates.

Relative Estimation

In Relative Estimation, the intended outcome is to quickly estimate stories as a team effort.  It is meant to drive conversations.  Note: It is NOT a commitment.  In the long-run, this technique becomes more accurate than time-based estimation as the team is estimating continuously and improving along the way.

In a scrum team, the estimations should be made by the team members doing the work, not by the people who want the work done.  The below highlights the different scrum roles and actions.

Product Owner:

• Available to clarify stories.
• Does NOT estimate.

Scrum Master:

• Facilitates the process.
• Does NOT estimate.

Team Members:

• Discuss stories and estimates the backlog.
• Estimates are forecasts NOT commitments.

Agile Estimation Strategy

When starting, the team members should agree to a baseline.  This can be done by taking one user story and assigning a value to it.  Then other user stories are compared to the baseline to determine if the size should be smaller, larger, or the same.

Here are two types of Agile estimating strategy:

1. Estimating stories individually (one-by-one)
   • Layout all of the user stories.
   • Team members should select one story to be the baseline and assign it a value.
   • Then each subsequent user story should be compared to the baseline to determine if the size is smaller, larger, or the same.

2. Estimating stories in groups
   • Layout all of the user stories.
   • Team members should group stories into similarly sized piles of related activity.
   • Then estimate size for each pile.
   • This is a fast way to estimate a large number of stories.

If your team is just starting out and wants to practice, try these Agile Estimation Exercises for Your Team.

To help with estimation, Agile planning cards can be purchased on Amazon here.

The post Agile Estimation and Different Estimation Strategies appeared first on Agile Inspirations.