Retrospection for Personal Growth (Continuous Introspection)

Retros for Your Life

It's easy for us to get caught up in life, and by the time we realize we are unhappy at a job or with a situation, it's too late to do anything. We get to feeling like we're unsuccessful or could've done more. What we forget to do is look within ourselves to find where we should be going or doing to improve ourselves, which ultimately will improve our situations.

I choose internal retrospectives over doing goal/vision boards for the main reason that vision boards can seem to limit you. I've never looked at my life and said this is where I will be in 5 or 10 years because if I had, I wouldn't be where I'm at now. I'd be blinded by what I thought was in front of me instead of what could be in front of me.

But, I digress. Below are some tips for how I do personal retrospectives to help me grow, that I hope you can find useful.

Choose the right frequency for you to retrospect (day, week, monthly...)

I found that every week is great for me. I have so much that happens in a week that it allows me enough to retrospect on, while being able to focus on something to improve for the next week.

Personal Experience: 

I used to do every two weeks, but unless I write down everything I do and how I feel about it everyday (which would defeat the weekly retrospective), then it was hard to remember those feelings. I also tried to retrospect everyday, but I found that it was harder for me to actually take the time to improve one thing in a day.

Look to improve yourself, not your job or your situation

It's easy to get caught up in the belief that it's the job that is making us unhappy or that our situation is to blame. Instead, we neglect to take a look at what we've done to allow us to be in a place where we don't want to be. Ask yourself the following as you retrospect:

• "What made me feel successful this week?"
• "How did I feel after [insert activity, meeting, session you did/attended]?"
• "What would have make me feel better/successful about such activity, meeting, session, etc.?"
• "How am I holding myself back from making such activity successful?"

Personal Experience

I have learned from retrospecting this way that in the past, it wasn't the job or the situation that made me unhappy. It was either the way I dealt with it or the inability to allow myself to move forward/past a fear. What is it that is holding you back because it's not the job or the situation you're in; we can get out of those.

Praise yourself!

This is the most important thing to do! It's easy to criticize ourselves, but it's harder to give praise for things we did good. We are our own worst critics I hear. So, drop that mentality and give yourself a pat on the back for the good things you did that week. What successes did you have; big and small?

Personal Experience

I grew up with nothing a lot of my adolescent life sleeping under overpasses, in children's homes, in halfway houses, or homeless shelters. Because of that, I always told myself I won't go back there. It's always been important to me to strive to be my best, which also meant being very hard on myself. What I ultimately learned was that I can be hard on myself while still making sure to recognize my small successes. By acknowledging my small successes, I was able to build on those and recognize what I did good so I can continue doing those things. Many small successes will equal to bigger successes.

Choose one item to adjust during your "life sprint" and take action

We can't fix it all! But, we can choose one item to work on between now and the next time we retrospect. Choose that one item that you can realistically do before your next retrospection and come up with the Acceptance Criteria and tasks that will help you reach your personal Definition of Done.

Personal Experience

For instance, I just recorded an agile podcast last week, which is still to be edited (shoutout to Rick Waters with http://agilechicagostyle.com/ for even considering me), and it was part of my retro this week. After retrospecting, it was the one thing I didn't feel I was successful at this past life sprint. I felt that I wasn't genuine as I was trying to say the "right" thing. Those that know me, know that I value genuineness and never want to be anything less. Now, I can't go back and redo the podcast since that's a lot of work for them. What I can do is determine why I felt that way and work this next life sprint to make sure I don't fall into that trap again. I'll spend this life sprint making sure that this need to say things right doesn't impede who I am in the future.

Most importantly, once you've focused on an action item and improved, keep it as part of your life. Changes shouldn't be temporary. Feel free to keep a backlog on the action items you chose to work on and improve.

Would love to hear your comments!

Remove the Impediment of Trust

Just Trust!

Somehow it has been ingrained in us, as a society, that we should be wary of trusting anyone.  Sure, that may sometimes make sense when we initially meet someone. However, why at work is it so hard to trust the people who make up the organization?

Lack of trust impedes the forward movement every organization should be striving for.

We take the time to pre-screen candidates, have them speak to multiple people, possibly take a test of some sort, and so on... Yet, we have the hardest time trusting the people we hire. The result is an organization that is built around micromanagement, dictatorship, and fear.

Lack of trust in our employees is a main factor in impeding progress when transforming to being Agile.  There's even an Agile principle that calls out,

"Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done."



So, why is it so hard to trust the people we hire? Is it that we don't want to give up the "power" associated with micromanaging, being constantly involved in details we don't need to be involved in, being constantly "heard", and so on.
Is it that we are so insecure in our ability to hire the right people? Is it that we are scared of small failures, not realizing small failures are the only way to prevent large failures?

I ask these questions to challenge us to think why we cannot trust the people we work with to get the job done. From management's point of view, it would seem a simple thing to do.  Why not trust the people you hire?  You did hire them for a reason.

So, let's drop our egos and our need to be "right", and trust the people around us to have grandiose ideas, to think outside the box, to be innovative, and to be allowed to do their job.

As Simon Sinek put it,

"When we tell people to do their jobs, we get workers. When we trust people to get the job done, we get leaders."  

Value in Stand-ups

Tips for creating more value in your stand-ups

 **Yes, this topic is overdone and there's many blogs, articles, and the such about it, but I still find that teams struggle with getting value out of stand-ups**

Team answers the following 3 questions in order:

• What is impeding my work from being done?
• What did I complete since the last stand-up?
• What will I complete before the next stand-up?

Why: 

1. Puts emphasis on the team collaborating on getting rid of impediments which also affects the team's work

2. By stressing what was completed, it puts emphasis on the fact that things should be completed each day and allows for collaboration to help each other get tasks completed. 

*One way to verify tasks will be completed each day is to write tasks that are a day's length of time (this removes the need to put hours and stresses that tasks should be moved daily).

Centered around the task(s) being worked on

Why: Team focuses on the work that they assigned themselves. This is extremely useful for teams who take longer than the recommended 15 minutes.

A parking lot is used and reviewed daily

Why:  Parking lots are useful in that they are places to "park" conversations that do not necessarily apply to the 3 stand-up questions. Put items on a post-it note that need to be talked about after the stand-up and place who needs to be involved in the conversation. After everyone has participated in the stand-up, review the parking lot items that need everyone in the discussion, then talk about those that do not apply to everyone. People can stay and listen, but it is not mandatory. This helps with conversations that do not need everyone and impedes others from getting work done.

Noise/Impediments from the previous day are reviewed

Why: Noise/Impediments from the previous days can be reviewed before the stand-up. Have a section where these are placed on the board (the team's information radiator). By putting them in front of everyone, the team does not lose sight of them, and others, including the team, can see where the team may need assistance clearing impediments. If the same impediment is staying too long on the board (you can mark the date it was added), then how different types of impediments should be reviewed.

Transparency is the key to success!!!!

Using Agile Techniques in a Public High School!

In my childhood days, I (might have) pretended my stuffed animals were my students as I handed out tests, wrote out lesson plans, created team projects and so on. So, think of my excitement when I got the opportunity to teach high school kids how to use Agile techniques to run their team Biology projects.

In the beginning:

Teacher sees a need to have teams become better at

• organizing their work
• working better as a team
• determining if/when teams will be done by the deadline

It continues with:

An Agile Transformation Coach who loves to work with kids (and used to teach her stuffed animals…oh yeah, that's me)

It continues with:

The Teacher and Coach come together to determine if teaching Agile techniques will provide value by assessing the

• current situation and needs
• willingness of the students
• support of the principal

It's determined that YES, even a Biology High School class can benefit from Agile techniques!

Let's Start:

We have teams!

There are 2 classes with each class broken into 4 teams of 2-3.

We have a Product Owner!

The Teacher becomes responsible for the backlog: writing user stories, prioritizing, ordering, accepting stories, etc.

Students reviewing the stories the Product Owner created

We'll use a mixture of Agile Techniques!

• Scrum Activities (Product backlog refinement, Sprint planning, Daily Scrum, Sprint review, Sprint retrospective)
• Scrum Artifacts (Product increment, Product backlog, Sprint backlog)
• Scrum Roles (Development Team, Product Owner, ScrumMaster)
• Kanban Principles (Visualize work with cards, Limit Work in Process, Continuous Improvement)
• XP Rules (User Stories, Pair Programming, Spikes usage, XP Values: Simplicity, Communication, Feedback, Respect, Courage)

Now What:

See the flashtalk I presented at the Global ScrumGathering Shanghai where I presented about the what was done at this school: https://www.slideshare.net/secret/pYx2gSCyqhq9Lt

Empowering Offshore Contractors on an Agile Team

Agile isn't just about doing ceremonies, it's also about being agile by changing the way we think and work together. One of the main changes that agile techniques advocate is empowering the team to make decisions, plan and estimate their work, resolve conflict, and so on.

However, how can that apply to offshore contracting teams who are used to working in an environment where they are told what to do, and not asked how? Let's cover some ideas.

Set their goals to align with what agile stands for                                      

• Don't reprimand offshore team members for speaking up
• Write their contract with the same goals that the client and/or onsite employees have (as a team, everyone should be working toward the same goal)

Remember, no matter the location of the individuals, they all make up a team that should be working together.

Make the offshore team feel like they are just as important as onsite team members

• Don't only communicate to the onsite team members; always include everyone on the team, even if they are on the other side of the across the globe
• Ask for insight and questions from those who are not onsite
• Hold meetings where video conferencing is used
• When treating onsite team members, try to also arrange for the offshore team members to partake in something fun (for instance, in many of my meetings, I provide snacks. In that case, arrange for someone to expense snacks at the other location(s))

Allow for mistakes and continuous improvement             

• Give offshore team members the same freedom you give onsite team members
• Coach offshore team members in the same way coaching is given to onsite members
• Ask for and follow through on advice given in retrospectives

There is no doubt that a mature agile team works at their best, not simply because of the ceremonies, but when they are empowered and have support behind them to truly be Agile. Offshore contractors deserve to have that same work environment, and if they do, I can guarantee you that they will get just as much done as if you micro-managing them. The best part is that quality will rise. Team happiness for all the team members will raise (as everyone on the team communicates instead of onshore team members telling offshore team members what to do). Most importantly, because the entire team is empowered, the project will have a much better chance of being successful.

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.

Attack of the Cop Out Words

We say about 10,000 to 25,000 words a day, according to the latest statistic I could find. Well, here's what I have to say to that...

If we're saying all these words, let's make them valuable. Let's make sure they do not minimize our intentions.  Let's make sure they are powerful.

Below is my list of words to stay away from (in day-to-day work contexts). 

Iron Man's Initial Resistance to Teamwork

Walking through the front entrance where I'm currently consulting as a transformation coach, stands a life size replica of Iron Man. I don't yet know the significance of why it is there, but i

Iron Man's existence begins with a child prodigy who grew up to be a pretentious, mostly egocentric engineering genius named Tony Stark.  During the movies, comics, and books, Stark takes on the Iron Man persona, saving people, being a hero, and letting his selfishness shine through.  He can do it all.  He is the one who is the genius. He doesn't want anyone else involved.

However, as things progress, it becomes apparent that Stark cannot do everything by himself.  He needs his friends, his assistant/lover, his community to help him.

As I work with and coach teams, and organizations, I see this same mentality.  Famous quotes I'm used to include:
     "We're getting the product out the door, something must be right..."
     "I'd rather just get my work done than have to worry about a process..."
     "Having code reviews is a waste of time; I know what I'm doing..."
     "I don't want anything else added that takes up more time..."

ACT on Adaptability

A = Adaptability
C = Consistency
T = Teamwork 

Applying Adaptability, Consistency, and Teamwork is important when it comes to delivering a successful project. 

Being able to Adapt is the first and major part of successfully delivering a high quality, valuable product within a realistic time frame that still meets the customers' needs.

Changes come at all times during a project:

• Requirements change due to the market's demands. 
• Resources leave or get transferred.
• Organizations go through mergers or acquisitions.
• Tools get introduced mid-project.
• Schedules change. Scope changes.  Budget changes.

Adapting means that we have to be able and willing to open our minds to thinking outside the box, to allow ourselves to take that step down a road we are not yet accustomed to.

How we adapt at work can be seen by how we adapt in our everyday lives.

You Say "Just a Phone Screen", I Say "Just Your Career's Future on the Line"

Common Etiquette of Phone Screens (or you would think it should be common knowledge)

Over the past couple years, I conducted over 100 phone screens for my and other's teams.

Phone screens are the first time that I get to hear a candidate and talk to them.  Besides the resume which helps me choose whether to phone screen, the phone screen gives me the knowledge to know if I should bring someone in for an in person interview.

Fortunately, most phone screens go well.  However, some do not.  Below are my 10 tips to make your phone screen as best as possible.

For Vendors: Take note, because many of your candidates are guilty of not doing the following.

Answer the Phone with your Name.  For instance, "This is Ebony" is the first thing I say if I'm expecting a call.  Here's why.  I don't want someone to butcher my name (yes, it is only 5 letters, but trust me, there are many ways I hear it pronounced).  Second, as an interviewer, I may not know how to pronounce your name.  Make me feel comfortable, so I can skip the first few seconds asking about pronunciation, and we can focus on seeing if you're a great fit for the job.

Use a Landline if Possible.  One of the most popular commercials years (and years) ago had the tagline "Can you hear me now?" and there was a reason for it resonating among millions of people.  No, I can't hear you now, and even if so, if you have to ask, there's a problem.  My advice: find a landline.  Granted, I know it can be difficult these days (I have one phone and it's my cell phone).  So, if you're planning on using a cell phone.  Call some friends using that cell from the exact location you'll be taking the phone screen.  You want to make sure you get good reception.  And, if you choose to use a cell phone, don't blame me for the fact that you hear an echo or I'm cutting out.  I'm on a landline, and most companies will be.  Plus, you're being interviewed by me, which means stay away from pointing fingers at me.  Instead, work on getting the issue solved or next time prepare like I mention here.

Be Ready for the Phone Screen.  You should not have to tell me to wait while you go find a room, finish a task, or get off another call.  Phone screens are scheduled (or should  be), so be prepared.

Prepare for Common Questions.  Some of these include: "Tell me about yourself", "Tell me about your last job", "Why do you think you'll be good for this position?", "What do you like about our company?"...  Most importantly, as you're preparing, make sure that your answers apply to the job for which you're being phone screened.

Answer Concisely while Selling Yourself. Phone screens aren't hours long (or mine aren't), so I want to get a good grasp on who you are and how you will fit into this company.  Give me what I will find important.  At the same time, sell yourself!  30-45 minutes isn't as long as you would think.  Sometimes, if you haven't sold yourself in half that time, you could be cut short from finishing.

Listen, Listen, Listen.  I want to know certain information about you so listen to the question and answer that question.  So many times, interviewees don't even answer or address the questions I ask. That proves to me that you most likely won't be able to take direction, or listen to others or even work together competently on a team.

Answer honestly.  If you don't know an answer, say you are not familiar with that concept, but will follow up on it.  I put this on here because it's funny how many people try to get over on me.  I can hear you typing in the background trying to google an answer.  I can tell when you put me on mute to look something up or maybe ask someone who is there with you. I will cut a phone screen short if it doesn't seem like you're being honest with me.

Lessen the Silence.  Long pauses on a phone call can be detrimental by seeming much longer than they really are.  Since I can't see you, I don't know if you're thinking, yawning, or just sitting there dazed and confused.  Try not to have pauses longer than two seconds.  If you're figuring out an answer to a technical question, explain how you're getting that answer.  This will lessen the silence, and give the interviewer an idea on your thought process.

Don't Ask Unnecessary Questions.  The phone screen is only the first part of the interview process for many.  This means that there's still more to do.  Stay away from asking questions right now about salary, vacation, work hours, etc.  This only tells me that you're more worried about that instead of what the job entails or what kind of culture we have, etc.

Give a Firm Handshake.  Yes, I know you're on the phone and can't give a physical handshake, but end the call as if you are giving me a handshake and thanking me for my time.  I recommend to interviewees I coach to extend their hand and pretend they're giving the person on the other line a handshake.  As an interviewer, I don't know you're extending your hand, but your tone of voice will say so.  By giving thanks for my time and speaking with you, it shows gratitude and respect.

How NBA's MVP Derek Rose Opened My Eyes to Project MVPs: What I Learned in Game 4 of the Bulls' Playoffs

Oh, how my heart broke last night after watching Game 4 in the post season with the Bulls versus Miami.  I should note quickly that I'm a Spurs fan, and always will be, but we got the air knocked out of us early in the playoffs, so I had to root for the city I live in now.  Right?  Go Bulls! Or, at least that's what I was chanting last night until the MVP and our most highly praised player seemed to skip out when the fans needed him most.

Derek Rose is to many Chicagoans as the star team member is to an IT project.  He's who you count on to drive the team even if you don't ask him to.  He's the one who has the most skills and knowledge because he has passion for what he does.  He's someone who listens to the Coach and offers advice at the right time that is deemed necessary and valuable to everyone involved.  He isn't afraid to ask questions or be a team player because he knows exactly how useful he is to the team. 

Derek Rose is this year's NBA's MVP (Most Valuable Player) because of all of the above attributes he brings to the team (and I also like to think no one wanted to give the MVP to his annoying pompous nemesis, Lebron). 

Similar to the NBA, the organization relies on the Project Managers (Coaches) and their teams to bring success to the organization through their various projects.  Throughout these teams, there's usually that one MVP team member who you use for their knowledge, teamwork, and experience. 

The problem, which Derek Rose had, is that our MVPs are overworked (playing all 4 quarters in every game), or carrying a heavy load of responsibility, or letting others down if they do not perform at their highest standards at all times.  After watching Derek Rose last night, I decided that the MVP may not be the best thing to have on your project.  Wouldn't it be ideal to have everyone equal (especially if they're all extremely great at what they do).  However, MVPs are a reality.  If you do have an MVP, here's how to make sure there's no let down at the end of the project.

Encourage Creative Shots in the Beginning
Derek Rose (and his other teammates) flawed throughout games 3 and 4 of the playoffs by taking these creative (and in the end, worthless) shots in the last minutes of the game.  New ideas, creative moves, and risky shots should be what happens in the beginning, not when we can't correct our mistakes.  By the end, the pressure to be successful and finish is way too strong, putting even more demands on the team members, much less your MVP.  It is much harder to fix something with only a week to go on a project than it is when it is the first week of the project.  Take advantage of the time you have, build in 'playing around' in your timeline, and take those crazy shots in the beginning. 

Allow All Team Members to be MVP
The only MVP award I was presented with was in 5th grade for the Most Vicious Pinky.  Yes, we used to play thumb wars with our pinkies (enough on that topic though).  Although my MVP honor didn't put  much pressure on me (okay, maybe on my pinky), it did allow me to feel honored, just like any award does to someone.  No matter what, an honor is an honor and everyone wants to be the MVP at some point. 

My suggestion; allow all of your team members to be the MVP.  For instance, allow other team members to:

• Hold a meeting or two in your place 
• Attend a meeting with you (as the SME) that's with upper management
• Be the first point of contact for questions you have that normally would go to your MVP
• Decide what (s)he feels is best to do on a piece of functionality

These are just some suggestions of course, so be creative and allow everyone to take over as MVP for a second, a minute, a day (however long it takes to make everyone else feel just as valuable).  At the same time, continue to encourage your MVP throughout; you're not looking to replace the MVP, you just want others to feel like they are MVP material as well. 

I'll use the example of Kurt Thomas, who usually sits on the bench.  Last night, for one night, he came on the court and played like he was an MVP, making shots that helped Bulls fans feel better about the game.  I credit their coach for keeping him active in trainings and allowing him to step up.  Final words on the topic: We all want to feel special (feel free to insert an adorable "aww" here). 

Recognize Reality
This one's a quick point: Recognize that your MVP is a person.  What does that mean?  It means we make mistakes.  It means we try and we fail.  It means we get nervous.  It means we need help every once in awhile.  It means we could let you down because your expectations are way too high and unrealistic.  Just recognize and accept these facts and there will be no need for let down. 

Don't Stop Coaching Ever
Don't give up!  Don't stop coaching!  Unfortunately, in Game 4 last night, the Bulls and our MVP, Derek Rose seemed to give up.  Game 3 was different, we tried to the very last second to win and it showed.  This team mentality has to come from the coach.  Always be there for your team.  Coach them through questions, impediments, training they need, etc. 

Being a Project Manager isn't about directing or simply implementing projects.  It's about coaching your team to be successful. 

Think about it.  Like Derek Rose was, the best high school athletes are aggressively recruited by colleges, promised the best in life, and given a multitude of colleges to choose from.  Yes, they may choose to play for different teams based on many reasons.  However, I'm guessing a major decision maker is the coach. 

Don't be a good Project Manager; be a great one and include coaching in your skillset.  If you're not familiar with how to successfully coach, read books, view webinars, do something.  And, once you start coaching, don't stop ever!

No Seconds Needed, I'm Already Full

Cheese and crackers can never be a complete meal for me.  I need something that fills me up, satisfies my hunger, makes me fill full longer than 5 minutes.  I must say, that's exactly the way I see my need for 'food' at work and in life.  I've been fortunate to find that fullness and not settle for the fast food or the quick sugar fix.  My life is and will continue to be full of sustainable food that keeps me feeling whole and healthy.  

This blog is my way of sharing thoughts, ideas, actions that will hopefully fulfill those pangs of hunger for you and even me.  Since my career has been mostly based in the Information Technology field, a lot of my posts will deal with that (specifically Project Management, Agile, the corporate world, and life in general).

I can't wait to start sharing with you.