Measuring Team Happiness

/

Recently I was in the assessment phase for a client. The group I was focusing on was considered highly productive but as a result there were concerns about burn-out. To help determine the potential, a key component of the assessment was focused around team happiness.

Measuring team happiness, if done at all, often takes the form of simply asking "are you happy?" and getting the response from 1 (not happy) to 5 (very happy). This may take the form of a survey, but often is done at the retrospective.

“Happiness is an inside job”
— William Arthur Ward

Although better than nothing, there are several issues with this approach. First off, no matter the method of collection, giving your answer in front of others will influence the answer you give.  There are many causes, from a lack of safety to a tendency to skew to the norm. This can happen consciously or unconsciously.

Another issue is that, although the simplicity is one of the reason people like it, the question is really too simple to get meaningful, actionable information.  Is it the workload, the environment, the teammates, a supervisor, pay, benefits, or a source outside the workplace?  This can make it impossible to try and take action in a meaningful way.

“Action may not always bring happiness; but there is no happiness without action.”
— Benjamin Disraeli

Below are a set of questions that I think help narrow the focus a bit more.  I try to keep it to only five questions and will rotate in alternatives based on the current situation.

  • I enjoy the work that I do
  • I am able to maintain a healthy Work/Life balance
  • I am able to contribute to my team in a meaningful way
  • The work that I do is valuable to my company
  • I have the support I need to do my job

Alternatives

  • I am challenged by the work I do
  • I have a clear understanding of my team's goals and priorities
  • I have the time necessary to complete my work to a high level of quality
  • I have the resources necessary to complete my work to a high level of quality
  • I enjoy coming to work
  • I have the time and resources to meaningfully improve my skills
  • I am happy with my job and the work I do

Using these kinds of questions can help you narrow in on what you may be doing well and where you may be failing.  Note that the questions are not overloaded, such as: "I enjoy the work that I do and feel challenged."  There are two possibly conflicting statements here.

Also all of the questions fit a single format, a "Strong Disagree - Strongly Agree" scale of 1 to 5.  This allows the person answering the questions to complete all 5 in just a few seconds without having to cognitively reset to a new question format.  If you intend to ask the question on a regular basis (per Iteration or release), you want something they can complete quickly with minimal hassle.

“Happiness is not a matter of intensity but of balance, order, rhythm and harmony.”
— Thomas Merton

There are lots of blogs and articles out there on this topic, before rolling out a Happiness metric, be sure to do some research and find what works best for your team.

Agile Games Podcast Episode 4

/

In this episode we interview Sue Johnston, an Agile Coach Trainer. She tells us about how she got her start with Coaching, Games, and Agile (in that order). She also tells us about her recent experiences at Play 4 Agile.
itsunderstood.com/ @itsunderstood
agilegamespodcast.com/ @workagile @laurapowers
 

NOTE: Apologies for the audio quality, we're still learning! New gear is on the way and we should be getting it fixed soon!

Finding your place on the Agile Spectrum

/

Agile adoption is a spectrum. Even within a company there are usually teams that are more advanced or collaborative than other teams.  Moving from one end of the spectrum to the other is not easy or cheap. It takes dedicated, sustained effort and skilled practitioners who are able to experiment, measure, and adapt practices. It takes a mindset that understands their will be missteps and failures and that every change involves a J curve.

Too often I hear about companies that are interested in going Agile or may have already implemented some practices and now want to implement the "Spotify model" or copy the "Toyota way". While admirable in their ambition, I have yet to hear of a company that has done it successfully. Why?

The biggest hurdle to applying something that was successful at another company is the fact that you are not that other company. This isn't bad, it's just that your employees, culture, managers, executive team, experiences, and products are different. This is particularly true when looking to take the practices of a manufacturing company, such as Toyota, and apply it to software development.

Next is the fact that no company that is currently successful with their Agile or Lean practices started out with those practices. Each organization went through periods of pain, followed dead-ends and found tweaks that eventually led to their success.  

Even once they are successful, these are organizations that continue to tweak beyond what has been documented. In fact, they may very well have abandoned, at least in part, some of what they once promoted.

Not all companies can be Hunter Industries running Mob Programming teams that work all day every day. Even for Hunter it can be a struggle at times, but what you can do is start to discover the little tweaks and the continuous improvement that works for you.

Try a Mob during a hackathon or when tackling a tough problem, start a tribe for your Scrum Masters and see how it feels, or review your planning to see if there is waste in the process that can be eliminated. Find your place on the Agile Spectrum without worrying that you need to be the Agile envy of the world, just try and be a little bit better than you are and then do that again.

2015 San Diego Agilist Award

/
Paul Wynia (middle) receiving 2015 San Diego Agilist of the Year award from Gary Moore (left) and June Clarke (right)

Paul Wynia (middle) receiving 2015 San Diego Agilist of the Year award from Gary Moore (left) and June Clarke (right)

On June 17, 2016 at Scrum Day San Diego, I was honored to be awarded the San Diego Agilist of the Year 2015 award. This really meant a lot to me but, as with anything involving Agile, it's really all about the team. In this case it's the SoCal Agile Community.

Paul Wynia thanking the community

Paul Wynia thanking the community

Without the support of those in the San Diego and Southern California Agile community who put together all of the amazing events we have down here, I would have nowhere to speak and no one to speak to. This is very much a team award for all those I am lucky enough to be involved with.

I have also been lucky enough to get great support at a personal level from some amazing people with amazing Agile minds. These are the people who challenge my ideas and push me to be better, who give me new perspectives, and who help me grow and develop. Thanks to all of you so much! It's been an amazing journey and I know I have so much more to look forward to!

if I forgot to mention you on the word cloud, my apologizes!  I did this quickly the night before and I'm sure missed some really important people! (Pam Fox, Allan Schougaard, and Aaron Griffith for starters)

if I forgot to mention you on the word cloud, my apologizes!  I did this quickly the night before and I'm sure missed some really important people! (Pam Fox, Allan Schougaard, and Aaron Griffith for starters)

The Role of Managers on an Agile Team

/

On a recent episode of the Agile Coffee podcast with Agile Coach Vic Bonacci, one of the topics was about the role of Managers on an Agile team. This is a question that I've heard before at Agile Coffees and Open Spaces. I've heard passionate statements about the end of command and control, flattening organizations, and the outdated concept of middle management.

While there is value in exploring these ideas and it is certainly true that the role of a manager in an Agile environment is different than in a traditional one, I think there is a different way to approach this issue that's worth exploring.

As an experiment to discover potential value, let's twist this question a bit. Try asking "who is the best manager you've ever had?" Once you have an answer to that, then ask "what did they do that made them the best?"  

Hopefully we've all had that manager that helped us find our passion, provided a sounding board, knew how to navigate a tricky political landscape, or found ways to challenge us with new opportunities. I know I've had some great managers who have helped me succeed at different stages of my career.

Now how do we take those traits, skills, and abilities and find a a way for that individual to add value inside an Agile organization? Are they still a manager or do they take on some new role that maximizes their value in a different way?

Conversely you can try asking "who is the worst manager you've ever had?" and "what did they do that made them the worst?" to determine what you don't want. The problem with this line of questioning is it can quickly devolve into war stories that try to one up everyone else's. We've all had bad managers but I think this is a case where turning up the good is a more valuable use of everyone's time and energy.

Please feel free to reach out and let me know your thoughts!

Finding meaning in the Agile Manifesto

/

Whenever I'm starting with a new group, whether they are currently using Agile practices or whether they are looking to move in an Agile direction, one of the first things I do with them is a review of the Agile Manifesto. The purpose of this exercise is to understand how much of an Agile Mindset has been incorporated or already exists in the group or whether they've just adopted some practices without a good understanding of why.

Utilizing concepts and techniques popularized by by Sharon Bowman in her book: Training from the Back of the Room, I start by showing the group the Agile Manifesto. I read out loud each item but don't explain the meaning. Next I then have the group self-organize into four even sized teams giving each team poster paper and colored markers.  

The teams start by each writing one of the Manifesto items across the top. Then each team creates a definition of what they think it means, giving examples of how it applies to their work. Finally they give a rating on a scale of 1-10 on how well their group currently meets this definition (1 = not at all, 10 = we live and die by this).  

This usually takes about 20 minutes to complete, as the teams are creating their posters I move between room helping to guide and asking probing questions. A typical question I often get from teams is "is it X vs. Y?" Use this as an opportunity to discuss situations where Y can still provide value to their team, but how X can help their team achieve even greater Agility.

As the teams finish, I have them tape their posters up on the wall and choose a spokesperson. The teams will now present their posters to the rest of the group with a facilitated discussion on what the team has created. The audience is given a chance to make changes if needed and give their take on the correct rating.  

Using this technique, I am be able to engage teams in a more meaningful discussion of where a group's Agile Mindset is strong and where it needs improvement. This creates a great lead-in to a discussion of the team's pain points and how to help them address them using Agile principles. 

If you get the opportunity to use this exercise with your team, be sure to reach out and let me know.

Does what your team value match your Agile practices?

/

Agile has become a crowded field and one that grows more and more confusing by the day. There are so many different approaches coming from so many different directions, it’s hard to have any hope of figuring out what “being Agile” will mean to your team. 

Will you adopt Scrum, SAFe, Kanban, or LeSS? Should you incorporate XP, Mob Programming, or TDD? Can one team use Scrum while another in the same company uses Kanban and can they both then scale up to DaD? With the overwhelming number of options and even more opinions, how do you begin to create an action plan?

The problem is, despite what some may tell you, there is no one right approach for every team. One of the first things you need to do with your team is to decide what matters most to your team and your company. What are your core values and how do those inform your goals and ways of working?

Each team is unique and is influenced by their environment, requirements, expectations, skill sets, and goals. For example, take a team that is working on a 7th generation product that allows users to file their annual US taxes, let's take a look at 12 core areas to help determine where to focus.

Cycle – Medium, Hard – Product is on an annual release cycle that cannot change

New Features – Low to Medium – Product must remain current with US tax code

Reliability – High – Users expect few to no errors

Innovation – Low – Users expect to be able to use the product in a similar way each year

Users – Non-technical – Although some users may be technical, a majority are not.  Usage must be obvious and documented in easy to understand language.

Regulation – High – Company must comply with federal and financial regulations

Team - Experienced – Team has been together for several years with strong product knowledge

Integration – Medium to High – Product must be able to import from and export to banking, accounting, stock broker, and government systems as well as their own bookkeeping and planning products.

Market – Low to Medium – Although highly competitive, competition is stable year over year with few new entrants or innovations.  Customers tend to stick with programs they are familiar with.

Team Structure – Multi-team – Product is made up of 7 segmented teams (4 dev, 1 QA, 1 UX/UI, 1 Product) with separate sales, marketing, and management. Standard turnover/replacement.

Corporate Culture – Diverse, stable – Workforce is a mix from recent college grads to long-term employees who are interested in more secure, large corporations with reasonable work/life balance.  A 9 to 5 workday is common for many employees.

Agile Experience – Little – A couple teams on another product implemented Scrum initiated by their Product Manager to moderate success.

Now let’s take a look at a mobile dating app team who are busily iterating after their initial release.

Cycle – Short, flexible – App can be updated on demand through app stores.  New features are only announced at time of release.

New Features – Medium to High – User’s expect a product that consistently provides new ways to connect with each other.

Reliability – Medium – Reliability is important, but users tolerate the occasional crash or slowdown

Innovation – High – User’s need to feel they are using the latest and greatest

Users – Tech Savvy, Young – Marketed to younger users who are comfortable with apps and don’t tend to reference documentation or tutorials

Regulation – Low – Must comply with App store rules

Team – Inexperienced, but skilled – Although typically younger with less experience, team members are skilled individuals attracted by high risk/high reward start up culture

Integration – Low – App is stand alone and is the sole product of company

Market – Volatile – New competitors appear almost weekly, users have very little loyalty and will often use multiple competitors at the same time.

Team Structure – Single team – A single cross functional team of 13 people.  Looking to double within the next year.

Corporate Culture – High energy, high stress – Teams are under pressure to rapidly deliver new features before competitors.  Motivation consist of a “us against the world” mentality and the potential of pre-IPO stock grants.

Agile Experience – Some – Founder launched using Lean Start-up principles he read about.  Work is done loosely in sprints/iterations and the team uses a form of User Stories with either To Do or Done status.

So what is the likelihood that an identical approach to software development will serve each team equally well? Although both teams could apply Scrum with potential success, are there other approaches or additional practices that can help the team reach their goals?

By identifying your team’s values using the 12 core areas, you can start to identify and create the best possible approach to guide your team to becoming Agile rather than just using a one size fits all methodology.