Let the Games Begin

By | Culture, Life at Daxko, Technology, Workplace | One Comment

Here at Daxko, we eat, sleep, and breathe member engagement. I mean, we literally wrote the book on it. So it’s no surprise that team member engagement is important to us as well. Studies show that employees who are highly engaged at work are much more productive.  In a meta-analysis of 263 research studies across 192 companies, employers with the most engaged employees were 22% more profitable than those with the least engaged employees.

One of my favorite ways that we promote team member engagement is through something called gamification. Gamification is the use of game thinking and game mechanics in non-game contexts to engage users in solving problems. Studies have shown that it stimulates creativity and directly improves engagement and learning. Here are three examples of how we use Gamification at Daxko to improve engagement, focus, and learning.

1. Teaching agile concepts and principles

As an Agile Coach for Daxko, I’m responsible for teaching new team members about our agile principles and philosophy. This is the core foundation of our engineering culture and fundamentally drives how we build and deliver software.

Some of the agile principles we teach team members include: breaking larger tasks down into smaller, more manageable ones, getting feedback early and often, and working in short iterations. I recently developed a game to help reinforce those ideas and principles using Lego bricks.

The game has two parts – the first requires participants to build a small house based on a list of requirements. Once the house is complete, they use test cards and roll a die to test different parts of the home and make changes based on the results. The second phase breaks the construction and testing down into smaller parts so that they test each section of the house as it is completed. The resulting improvements in efficiency and reduction of waste is obvious and the concepts we talked about earlier become much more tangible and concrete. Plus team members get to have a little fun using their imagination and playing with Lego!

Let the games begin1

2. Reflecting on how we are working

All of our software teams practice sprint retrospectives after each iteration. Retrospectives are a tool for us to look back at the last couple of weeks of working and review how things went. We talk about things that are working, things that could be better, and ideas that we have to make us work better as a team. Since we do this every two weeks, it can sometimes feel stale and boring. One of the ways we combat this is to change up the format and introduce different gamification techniques. One of my favorites is called the Sailboat or Speedboat exercise. Here’s how it works:

Draw a picture of a cloud with wind, a sailboat with an anchor, and an iceberg similar to the one seen below.

Let the games begin2The imagery here represents the following:

Winds = The things that propel us.

Anchor = The things that are holding us back or making us slower.

Iceberg = Things to look out for.

Have the team take time to think about each of these aspects of the project or sprint and write them down on post-it notes. Take turns placing the notes in the appropriate area of the image and discuss each one with the group.

Use dot voting to identify the things the team thinks are most important to address. We capture any action items that come out of the discussion and post them in a visible area in our team room.

3. Measuring the health of our teams

We identify closely with the engineering culture at Spotify. A few of us were fortunate enough to hear two of their agile coaches speak at Agile 2014. One of the things we have stolen borrowed from them is the squad health check concept. This workshop involves the team rating themselves on several “health indicators” using red, yellow, and green cards. The cards help facilitate a group discussion around each of the health indicators. The discussion is the most valuable part of this workshop. (That’s also why surveys don’t work well for this sort of thing.)

Much like retrospectives, this is a really useful tool for the team to help identify how they are doing. The difference is that the team is measuring themselves on specific dimensions such as: teamwork, quality, fun, value, etc. This means that they can identify trends and respond accordingly.

Let the games begin3.jpg


These are just a few examples of how we employ gamification techniques to improve team member engagement and outcomes. Here are a few resources if you’d like to learn more:

GameStorming – a toolkit for innovators, rule breakers, and changemakers.

A Guide For Retrospectives – Tips on how to organize and facilitate effective retrospectives

TastyCupcakes – Fuel for Invention and Learning

Innovation Games – Library of innovation games


Jason B. is a software testing professional that loves a good challenge! When he’s not working to make the world a more “agile” place, he’s probably out running waterfalls in his kayak.

Agile for Kindergartners; It Works!

By | Culture, Life at Daxko, Professional Development, Technology | No Comments

Last year I was introduced to the world of Agile and Scrum.  Well, not  really just introduced to it because the engineers at Daxko have been practicing this method of project management for some years now. So I was familiar with the concept or at least the “buzz” words of it for recruiting. But last year I actually learned about it. I shared a few blog posts of the journey of how the People Team decided to incorporate this project management style into our regular routine. You can the different posts about our journey and what we learned below.

The People Team and Agile?

Agile: We are People Team (HR) not SWE

So What Happened with Agile and the People Team?

Well, now I have taken another step towards the Agile insanity train. Ok, maybe not so insane but I had to throw something dramatic in there. I have made an agile task board for my 5 and 6 year old sons at home.

To some it might look like a regular chore chart, but it’s not. It’s different. It is the use of the agile philosophy that makes it different.

  • Break things into small accomplishable tasks that can be tracked – In oppose to hearing, “Your chores are to make your bed everyday, clean the playroom and clean your bedroom.  If you do this every week, you can get $5.” To a 5 or 6 year old, that’s a lot.  It’s not a big overcoming thing for the boys to see that all they have to do is move one sticker a day and it is done. Break it down.
  • Celebrate wins – It is actually exciting for me and my team of adults at work to move things over to the “Done” column when we complete tasks. How much more is it when my boys move their sticker over to a “Done” column with $ signs? Then Mommy or Daddy says “Good job!”
  • Keep it visual – This chart is located in the hallway next to our bedroom.  This is in a place that everyone has to walk by multiple times everyday.  It is very big and very colorful.

One other thing that I did was called it an allowance chart instead of a chore chart.  I like to keep things positive and encouraging.

Well, so far this chart has worked wonderfully and the boys are extremely excited about it. At the end of the first week, they rushed to set the chart back up and to get prepared for the next week.

Sidebar, just in case you were wondering, there is also a section for Conduct based on how they do in school that day (you know – Green, Yellow, Red or numbers, etc). If they come home on a good number that day they put a thumbs up sticker. If they come home below acceptable they put up a thumbs down sticker and deduct $1 from what they can earn in allowance that week.

Concetta L. is a bean counter turned social butterfly. She loves to laugh, sing, dance and sleep. Just trying to figure out how to do it all at once.

So What Happened with Agile and the People Team?

By | Culture | No Comments

I feel I may have left some of you hanging when it comes to the People team adopting the Agile project management style for our team projects.  So I kind of want to play catch up with you.

For those of you who may not know, back in February I rolled out the concept of Agile to the People team as a way for us to manage our projects.  As a team, we needed to adopt something that would allow for better communication, focused and completion of projects.  Basically our day to day would interfere with the ability to complete the projects that would take our team to the next level.

Over the roll out of the principles of Agile using Scrum, the team was tentative (to say the least), but willing to try this method.  Over the course of a month, we were able to modify the structure to meet the needs of our team. We even implemented some ongoing visual reminders and awards that helps us celebrate our accomplishments and keep us motivated.

It’s been great since we have been able to share the effects of Agile with others within our company.  Thanks to our Agile coach Jason B, we were able to assist him with his TMD on introducing Agile to non-technical teams.

Now that we have been using Agile for almost 6 months now, we realize that this has been a game changer for our team.

  • We have made some major accomplishments, as a team, that we have not been able to make in the past.  As common saying on the team with Agile is eat the elephant one bite at a time. Agile has allow us to focus on smaller tasks and keep the project moving instead of getting overwhelmed by the overall project and putting it to the side due to day to day responsibilities.
  • Our team was made to realize that we were not communicating effectively. Now, don’t get me wrong, we were communicating good enough and getting things done. We realized how much our individual roles interacted with each other when we started discussing projects, as a team, in our sprint planning session. We now understand what each other does, we are able to question each other and provide objectivity to decisions, and we are able to have that constructive conflict that is great for a team.
  • There have been times where we have gotten relaxed in the structure of our meetings and check ins. And we noticed. Agile does required a few structured meetings, which if you are not used to it, can get old after a while.  But we got a reminder from a Leadership Academy on having effective meetings that made us refocus.  After that, although the check ins were daily and sprint planning meetings were weekly, they continued to be an effective use of the team’s time.
  • Last but not least, Agile allows the team to clearly know what the priority is for the team from our VP down.  Because we somewhat operated in silos with projects and specialties, our individual priorities didn’t always line up with the priorities of each other of the assumed priorities of leadership. We are able to talk about capacity and priorities of the “team” and how we can get things done as a team to make the most impact.

I would recommend Agile for any team that is looking for a better way to communicate, prioritize and focus.  I definitely see this as a great process for a Human Resources team that consists of many Generalists.  Let me or Jason B know if you would like to explore this concept more.

Agile Retrospectives as Group Therapy

By | Culture | No Comments

Whether you’re a Daxko customer, potential customer, or job candidate, you might (or might not) know that most teams at Daxko operate with agile principles in mind. One of these principles, “Inspect and adapt,” has an interesting activity that teams can do to help them in their quest to continuously improve how they work: retrospectives.

The name of the activity pretty much sums it up—you gather as a team and talk about things that have happened. I imagine it’s a lot like relationship therapy, as it needs to be recurring, can be awkward or painful, but oftentimes leaves you with greater insight and specific strategies to improve the situation.

Recurring meetings

To make the most out of retrospectives, they need to happen more than once! Having “retros” (as we like to call ’em) at consistent intervals (say, one every two weeks) allows benchmarking. Have we improved or gotten worse since our last retro? What are we doing differently? You’ll have to figure out what interval makes sense for your team, but a rule of thumb is to have a retro after each iteration/time period of work.

Awkward/painful conversations

If you’re doing it right, a retro should bring up some potentially uncomfortable things. (The art to doing that diplomatically could be an entire blog post on its own.) Everyone participating in the retro should be candid and truthful, and sometimes that means pointing out where someone (even yourself!) had been a bottleneck in the project or could’ve handled something differently. It’s not easy to openly admit to a group of people that you might’ve messed up or to tell others that they might’ve messed up. It can also be uncomfortable to recognize any current or lingering tension. What’s important to remember in these awkward situations is that the conversation can still be productive provided that action items follow the negatives.

Equally important in a retro is the acknowledgement of a job well done. Retros are a great time to reflect on what went well during that time period—new processes that worked, a team member who helped make a task go by more smoothly, etc.

Kudos given during this time of reflection can help surface changes needed to be made. For example, let’s say the A Team had a webpage that needed to be built. This webpage included a space for marketing copy, but the marketing copy had typically been plopped on the page after the page was built and in place already. This time around, Mary (the copywriter) thought she’d get a head start on writing the copy so Tom (the software programmer) would have it before the webpage was actually built. Later, Tom gives Mary kudos for writing website copy early since it helped speed up the development and review process. Coming out of their retro, the A Team decided that from now on, Mary would have all copy ready for Tom before Tom started development.

Specific improvement strategies

Lastly, teams should leave retros with action items, or specific strategies to address the areas mentioned during the meeting. Was your team in so many meetings this time around that they didn’t get a lot of work done? An action item could be to reduce the number of meetings that involve the team. Identifying specific things to do to change the undesired state can help ensure change for the better . Retrospectives provide a channel for conversation about how to continuously improve the way the whole team works.

You can read more about agile at Daxko on the Culture Blog.

Astrid P. is an interaction designer who will one day design a better way to design a better way.