Summer Softball takes Teams through Storming

Intramural Softball Means it's Time to Take a Look at Our Teams

It's summer time again, and for me, that means one thing... Softball!

Each summer, the teams I play on get new team members as others move to different leagues or levels, and sometimes we even get new coaches. Or, I may be the one to move to a different team or league.

Through it all, there are important ways that softball teams should function through these changes that directly apply to how teams at work can function better.

1. Start Over at the Forming Stage When Changes to the Team Happen

With new team members, new coaches, or the creation of an entire new team, it is vital to the team health to start at the Forming stage of Tuckman's stages of group development. The goal is to have a team that is able to reach the Perform stage.

The issue with most teams is that they try to immediately Perform, skipping the Forming, Storming, and Norming stages that are so important.

"Why do we need to go through all the phases? We've all played softball before. Let's get out there and start Performing now!"

What is missing is that it takes time for people to understand their roles and purpose on the team, and get to know each other on a personal level (Forming Stage).

After the team is through the forming stage, the team should storm. The outcome of the Storming stage is a team that knows how to resolve their conflicts and is focused on the goal at hand (in my softball team, it is when we are able to work together to play the best we can).

Let's Norm together next. Now, the team wants to work together towards that one goal with mutual agreement and a strong sense of unity.

Unfortunately, management (just like softball coaches) want to disrupt teams, change them around, and expect them to immediately perform without the realization that there are steps that need to be taken in order for any team to get to the Performing stage. Or, it is easy to join a new team and expect that since they were in the Performing stage, you can join right in. In this case, it is important for the entire team to start at the Forming stage with you and go through all the stages.

The time needed for either of the above mentioned scenarios will vary based on the people's backgrounds and expectations, as well as the coach who is helping them get to the Performing stage.

2. Allow Teams to Self-Organize and See the Positive Results

One major thing that happens when a new softball coach comes onto a team, or when I join a new team with a directive coach is that he/she wants to assign you to a position. This is especially true in the more competitive leagues (but, it still happens in the leagues I play in, which is only recreational. I never said I was a great softball player...).

What happens when the coach says you are going to play infield, even though you despise infield because you know you're not good at it (or vice versa with any position)? You now have to play a position that you don't like, know you're not good at, and most likely will not excel at which will set you up for failure.

Think of the opposite scenario. The new coach comes in and asks people what position they like to play, and as a team, they decide who will play where. There may still be conflict between two people if both want the same position, but by now the team is into the Norming stage where team members work together towards their common goal. Maybe there's compromises to be made, or maybe someone decides to try a new position. Now it is the team who is empowered to make decisions, and thus in return, will want to work harder for the common team goal. Each individual now feels accountable to each other because they chose their own positions and now will want to show why they thought they were best to play in that position. When someone directs you to play somewhere you don't feel comfortable, the intrinsic need to show how well you can play in that designated position is not as strong. "Why should I care?"

The same goes with teams at work. A team that is self-organizing and empowered, feel a stronger sense of team, want to accomplish more, and feel more accountable for what they are delivering.

3. Domination is for those Teams who Stay Together

There is one team we play against that has somehow managed to keep the same players year after year (at least for the past 5 years I've been playing in one specific league).  You may think that this team has gotten bored of each other, or that they're not growing as players since they're around the same people. However, these assumptions are farthest from the truth. This team continues to dominate, and it's not because they're that much better players individually.  It's because they're that much better players as a team. Since they have been playing together for so long, they know how each other plays, they support one another, they listen to one another, they know how to quickly deal with conflict, and they grow because they trust each other and are allowed to grow as players.

They are in the Performing phase, and every season it shows.

Teams at work that stay together, even as they work on different projects, will show this same domination. A dedicated team has a rhythm, knows how to resolve conflict properly, feels accountable to each other, has better quality, and most importantly, they work as a team to get the product delivered.

Conclusion

Admittedly, my softball skills may not be the best, but one thing I do know is that I play so much better when I am on a team that doesn't force its players to rush into the Performing Stage, allows for self-organization, and stays together as the seasons go by. This is the team I want to be on, and stay on!

(Oh, and I don't mind being on a team that knows what fun is; see the below comic...)

   

Agile, Art, and the Combination with other Disciplines

Combining Art in a Story with Engineering and Test??

In a traditional development company, there are engineers and testers with other parties (such as Architects, UX, etc.) that can be a part of the team or be used as SMEs. 

Now, imagine a creative project, like a video game, that has artists who also contribute to the product. It would be easy to create Art as a silo and have them create the look of a game, hand it off to engineering to implement the art, then hand it off to testing to test it. 

Artists create, polish, and polish some more. So, how do you combine art with the other team members into one story if there is constant polishing that needs to be done? And, why is it important to include art in the team?

Agile builds products in an Iterative, Incremental, and Concurrent Fashion; so does Art

Art can and should be iterative, incremental, and concurrent with engineering and test. Stories can be broken down iteratively by creating a skeleton, then a prototype version, then a final version. Too many or too few passes? Break it down to what makes sense for your game, as long as the user story still delivers valuable functionality and is sized appropriately within an iteration's time frame.

Some user stories will not have art included, and that is A-OK

There are times when the story deals with backend functionality, and art is not included; it's okay. The goal is to include art at times where engineering and test can also be combined to deliver a valuable piece of functionality.

Write titles of User Stories to reflect who is included

I coach that when Art is included in the User Story, the word, "Create" is used. If engineering is included, use the word, "Implement". A story that reads, "Create and Implement the LAP Attracts" tells me that art and engineering are both involved in this story (testing should always be involved).

Combining disciplines into one user story provides Collaboration, Accountability, and a Sense of Urgency

By combining disciplines into one user story, people start working as a team and collaborate more. Everyone knows what is going on at all times in the project. Handoffs are minimized. People feel accountable to their team members, and thus work to get more work done.

This is a high level finding on combining art with other disciplines. If you'd like to know more on how to do this at your organization, leave a comment, and I'd love to get your thoughts and/or provide feedback on struggles I deal with as well.

The Choice To Choose How...

There's a struggle out there with whether teams in an organization need to do Agile ceremonies the exact same way. By ceremonies, I mean those events such as planning, retrospectives, stand-ups, review/play-through meetings, etc.  

There is no doubt that the ceremonies need to be done to implement the basics of being Agile (though, I hope those reading this also understand that only doing these ceremonies does not make an organization Agile. Remember, that truly being Agile also means being culturally Agile as well).

Many times I find organizations that require teams to:

• Estimate the same;  
• Task the same;
• Hold retrospectives the same;
• Create and use the same working agreement;
• Conduct the ceremonies exactly the same.

Consistency should definitely be prevalent. For instance,

We hold and follow the same ceremonies;
We use the same terminology;
We follow the same cadence (if using Release Planning, following SAFe, etc.).


However, how teams conduct or follow the practices within the ceremonies can be (and I'll argue, should be) different.

I've worked with and coached multiple teams in the same department who task differently. One team may use a tool such as Rally or Jira, and a different team may choose to do a physical board. 

Physical Iteration Wall at a company I am helping transform to Agile (Thanks to Post-its for being so colorful)!

Some teams may use ideal days to estimate, some may use points (I have my preference, but it is the team who ultimately makes that decision).  

Why allow teams to conduct their ceremonies how they want?  It gives teams freedom, accountability, and the ability to learn from their decisions.

Freedom

"They may take our lives
but they will never take
our freedom!"

Forcing (or, strongly recommending) teams to have to work a certain way, takes away the part where we enable and empower teams to make decisions that help assist them to work better. Some teams may prefer a physical board versus tasking inside a tool. Or, some teams may choose not to task at all. By allowing teams to choose how they want to work, allows teams, and the individuals within those teams, to have the freedom to make decisions that affect them.

Accountability

When teams are given the option to work how they choose, they also feel more accountable to themselves and to each other. Individuals and teams take ownership of what they put out. It's no longer about producing something they don't care about; they now have a stake in how the product was produced.

Learning

One of the biggest aspects of a team being able to choose how an Agile ceremony is done is that everyone is able to learn. How does someone know something does or does not work? Try it out. What happens when something is tried and fails? It becomes a learning experience, and that is okay. It is okay to let teams fail at how they do things. Only by failing will teams know what works best. 

By learning what works best, teams are given freedom and have accountability which leads to more personal satisfaction, less attrition, and better delivery of products.

WIIFU versus WIIFM

It's a fight meant for the presses. Coaches be prepared because this is going to be one fight you want to see!  

In one corner is the widely recognized and aging acronym WIIFM, or as we like to say, "The ever present, but inaccurate What's in it for me."

In the opposite corner is the newer, younger acronym WIIFU also known as, "Sounding like a sneeze, but a more relevant acronym meaning What's in it for us." 

Let the bout begin!  

WIIFM approaches the center of the ring.  The majority of the audience scream "WIIFM! WIIFM!" due to the popularity growth that change agents, trainers, and leadership established decades ago.  It's hard to change allegiances, and WIIFM knows this.  The alleged power and misdirected authority reigns from WIIFM.  These supporters know that WIFFM  is only out for himself, and yet, surprisingly the emphasis on "Me" doesn't deter the masses. 

WIIFU isn't going to allow WIIFM or all of his supporters deter him.  Approaching the middle of the ring, WIIFU strides confidently up to WIIFM.  The few in the audience screaming "Go WIIFU!" know that this is not going to be an exciting match.  They understand the power of thinking about the team, the organization, the masses. 

WIIFM takes a shot to WIIFU's head and misses.  With one punch, WIIFU swings and lands a big smacker on WIIFM's right cheek. WIIFM stumbles, loses his grounding, and falls back. It's a knockout!  WIIFU is the clear winner.

Implementing any type of change in an organization requires understanding about the wants and needs of a change and the reasons why.  Unfortunately, many still keep the answers to the WIIFM as the guiding factor on how to engage individuals. However, organizations are learning how to be successful by focusing more on teams to get things done.  And, it makes sense. 

Teams are able to throw ideas off each other, allowing for more creativity.  Teams work together to build products faster than one person can.  Teams help quality by having more than one pair of eyes on code. Teams hold each other accountable without management interference to release products/services that customers value.  Teams bring more joy to the workplace as collaboration builds.  

Good teams can be the lifeline of a successful company.

Thus, when coaching a new organization through any transformation, it is important to find the answer to, "What's In It For Us?" The "Us" part should be answered by thinking of every group of individuals that makes up an organization.

Who is this Us?

Us = The entire organization
Us = Upper Management
Us = Teams
Us = Middle Management 
Us = Project Management Office
Us = Any group of individuals who work together

It is important to not put the focus only on individuals' needs, but on team needs. It is the individuals working together who make the most impact and bring success to a company.


 

FTE or Consultant?? Let me Coach!

Oh, the dilemma!

Agile Coach contemplating a new opportunity: "Should I go in as a consultant or an FTE (full-time employee)?

The decision around consulting versus being a full-time employee when it comes to coaching companies in Agile encompasses more than benefits, vacation, salary, etc.  It encompasses what you plan to accomplish, and how successful you want to be at reaching the goals.

In general, there are two coaching paths.

1. Coaching teams already using Agile techniques
2. Coaching a department or entire organization through the transformation to using Agile techniques

If you're about to coach teams already using Agile, choose whatever suits you; FTE or Consultant will work.

However, if you're getting an organization up to speed on adopting, and eventually transforming to Agile, then there are a few things to consider.

Why Consulting Works for an Agile Transformation Coach (or any position that requires an organizational change)

No More Politics Please                                                

As someone who has to influence everyone from the teams to upper management, it is important not to have to report to one department.  We all know how politics play out in a matrix organization.  Some departments don't like other departments, one manager wants something different than the other.  At some companies I have consulted with, I saw full-time employees trying to undermine other employees so  that they can get promoted.

Being a consultant means you don't have to play the company politics.  You're able to stand back and watch, so bring some popcorn and a large cherry coke.

Objectivity                                                                        

If you're an FTE assigned under one manager, that person determines your salary and bonuses.  That tells me that you're going to be biased toward what that person wants.

It is important to set expectations up front, especially to the person who is paying you from their department budget.  It is vital to your livelihood as a Coach to reiterate that you are working for everyone involved in the transformation and that you are an objective party no matter what. If you feel that the company is not for that, don't take the job.

Being a consultant means you answer to the entire organization.

Freedom and Focus                                                             

By freedom, I mean freedom to do your job.  As a consultant, you're brought in for one purpose and you should be given the freedom to accomplish that purpose.  As an Agile Transformation Coach, you want to focus on the transformation, not other tasks that are outside that realm.
As an FTE, there are times when you will be asked to take on something else.  Although, this benefits the organization in the short term, the long term effects of not being able to focus on the transformation will hurt the company as your time is taken away


Being a consultant means you get to focus on the goals that were set forth when you were hired.

Trust                                                                                        

One vital component to bringing about change (and Agile Adoptions & Transformations are all about change) is that people have to trust you.  This means that every point I mentioned above has to be true.  The organization has to believe that you aren't playing company politics, that you are objective, and that you are focused on the transformation of mindsets and practices.
Your goal and purpose is to make this company succeed through the practices you teach and live by.  Your goal is not to sell a tool, not to progress in the company, not to make yourself look good. You are to transform an organization so that they are delivering high quality, valuable products that are within a reasonable range of the schedule, scope, and budget constraints.

Being a consultant means that people can trust you to get the job done and see the change through so that it sticks.

________________________________________________________________________________

After the transformation, taking an FTE position or staying a Consultant is up to you.  If you think you've achieved all of the above, and that being an FTE won't change anything because you've set your ground, go ahead.  There are times when being an FTE will work.  My take is, in the beginning especially, it is important to stay away from politics, be objective, have the freedom to focus, and be trusted.  This happens best as a Consultant.

What do you think?  Do you think that when transforming an organization, being an FTE is better?  If so, let me know. I'd love to hear your feedback and experiences. 



 

Team Fever? Grab the Thermometer!

With symptoms ranging from runny noses, to dry coughs, to fevers that put you in terrible sweats, getting sick is never fun. Being sick is even more disruptive to a team when someone has to miss work and others have to pick up slack, work later, or come up with other innovative ideas on how to continue at the same pace.

The same applies when team members are "sick" at work and have negative symptoms in their work environment; their productivity and quality are negatively impacted.  So how do I gauge how a team feels? I take their temperature.  A temperature gauge is my favorite way to start conversations and anonymously see how team members feel.  I do this before starting a retrospective, but this can be used in other meetings, at a wider level, or even at home for family meetings.

STEP 1

Create a thermometer with a scale, and feel free to make it fun.  With a recent team, someone saw my thermometer and thought I had the junior high girl I mentor work on it. In reality, I was the horrible artist, but the team loved it. We knew what it was for and it served it's purpose.

STEP 2

Create a measurable scale for the thermometer.  I like to use 1-10, though I have also used 1-5 to make it less convoluted.  You can also use words like "Perfect", "Not the Best", "Lousy", "Can I go Home and Never Come Back."  The point is to have some way of measuring how people are feeling.

STEP 3

Identify and document what the scale means and what is being measured so that there is no confusion. What does 1 really mean versus a 5? Am I allowed to use 5.5 or other fractions?
What are we measuring (the last iteration, the release, external factors, etc)?

STEP 4

Have each team member vote anonymously.  I like to hand out post it notes on which individuals write their temperature and hand it in.

STEP 5

Average the responses to get the temperature.

STEP 6

Follow up immediately on why the team thinks the temperature is the way it is.  What factors brought us to a 6?  How do we get to a lower temperature so we don't have a fever?

Document and decide as a team how to resolve any issues that were brought up.

STEP 7

Keep a rolling graph in the team area on the temperatures throughout the project.  You will mostly notice that as velocity lowered or things weren't getting done that the team temperature was worse.  

Let me know in the comments if you have been doing something like this or will be trying it, and what your result is.

TIPS:

• If a team  has low temperatures all the time, it could be a good thing or it can be that your team doesn't feel like they can be open. Evaluate the cause.

• Do not call people out if you think they put a bad temperature in.  Keep the conversations objective and allow for openness among the team members.

• If issues come up that will continue to impact the project, put those items in the backlog so they can be mitigated or resolved. 

Ghosts, Ghouls, and Estimations

Lurking behind the ominous shadows is something so scary that the shadows cringe in fear.  The mere mention of it sends people running and screaming as they trip over each other in their best efforts to get away.
If  you are one to get scared easily, I recommend you stop here because this is a word that sends chills down spines, makes people cower, automatically arches cats' backs in a defense stance.  The word is:

             Estimation

_________________________________________________________________________________

Estimating within an Agile project is an easy thing to do, but one of the hardest concepts to grasp.  We just don't get it.  If using points, we want to try to correlate points to days.  If using ideal days, we want to use that to understand why something we said would take "two days" really took three or four.