“No one cares how much you know until they know how much you care.” – well known quote

Some people are great at building connections with others.  They seem to have a persona that permeates the room and attracts others to them.

I am not one of these people.  As a closet introvert, building connections with others is something I struggle with.   Somedays it comes easy, but other days I wake up and don’t seem to care.  (Maybe I shouldn’t be so honest, but I assume you can relate.)

On the days that I don’t seem to have the energy, I take some time to think about one thing… everyone is a human and deserves to be treated well.

My faith teaches that everyone was created for a purpose and has inherent value.

Everyone on this earth is here for a reason, and no one is inherently better than anyone else.  We all have value, and we all have worth.

That applies from the CEO down to the janitor cleaning the bathroom or the short order cook making your lunch.  Everyone is someone’s reason to get up in the morning.

I try to use this lens whenever I look at people.  Do I do it perfectly??  I wish I could say that I do, but I don’t.

Talk to any of the people around me, and I’m sure they can give examples of times when I failed miserably.  I have been short with people and forgot they where human.  I didn’t see their inherent value but saw them as something that needs to be fixed.

I try to carry my failures lightly.  I don’t want to ignore them because they can be useful for me to understand some of my shortfalls, but I also don’t want them to weigh me down so much that I become fatalistic.

By keeping my failures in mind, I am more likely to see the pitfall and landmines in a new situation.  Avoiding these landmines makes the relationship safer both others and myself.

When we treat people well, we treat them as a whole human being with inherent value.  Then we can understand what they really need, not just what they are saying.  When we do this, we are building real connections with others.

What about you?  What failures have you experienced building connections with others?  What can you take away that can help you in the future?

Photo by Jonathan Harrison on Unsplash

The best time to address technical debt is when it is not a problem.  When you start to feel it, it is usually too late.

This is something I got to experience a couple of days ago.  Let me explain.

For those who know me personally, you will know that my wife owns two waxing salons.  A couple of days ago, we had a winter storm blanket 6 inch of snow over our community.   The result, the roof on one of her salons failed and started to dump water all over the floor.

This wasn’t the first time the roof started to leak at this location.  The roof leaked last winter in the same spot resulting in an emergency repair last February.  The landlord knew a year ago that the roof needs to be replaced.

Unfortunately, the summer passed by, and nothing happened.  Since the roof had no issues during the summer, it quickly because “out of sight and out of mind.”

Instead of addressing the roof issue during the warm summer months, the roofing crew needed to scoop 12 inches of snow off the roof and perform an emergency repair.  Not only that, the ceiling is damaged again and needs to be repaired.

You might not have water pouring into your building, but we all have technical debt we are ignoring. Technical debt has different levels of risk which leads to different degrees of urgency. Not everything needs to be fixed right now.  Something things never need to be fixed.

For instance, we had a 100-year rain last summer that resulted in some minor flooding on our property.  Nothing was damaged, but we did need to clean-up afterward.  To truly address the issue, we would need to rip up part of the lawn and do some dirt work. Since are rain like this will not happen again for another 100-years (statistically speaking) we are choosing to accept the risk and not make any changes.

What about you?  What technical debt issues are you not addressing?

Do you rate or rank your issues to determine the likelihood of it happening again?  What are you doing to fix the high probability issues before they happen?  Have you identified those issues that you know will show up?  Do you consciously choose what to fix or are you just dealing with the latest “fire”?

Instead of being reactive, start addressing the issues.  It might be a hard sell, but is worth it.

We knew last year that the roof was past its usable life, and it will continue to develop leaks.  The roofing company said it will continue to leak until it is replaced.  I would much rather fix the issue on a sunny summer day then have leaks in the dead of winter.

What about you?

Photo by Chris Thompson on Unsplash

Learning is a roller coaster.  You need to go through a dip to make it up the next hill.

I recently watched a situation that was completely avoidable.  An organization decided to change how team leaders within the program interacted with each other.  To facilitate this change, a PowerPoint deck was created, and the various people involved were trained.

Within weeks, the new change seems to be making things worse.  Team leaders weren’t sure what to do.  They struggled with the new responsibilities.  The leader’s productivity started to take a hit.  One of the proposed solutions presented to address this drop in productivity was more training.

While more training might be helpful, the lack of training is usually not the root cause of people struggling with change.

What we want to happen.

The figure above shows what most stakeholders want to have happened when a team implements a new way of thinking.  Most people will agree that the change will not increase performance immediately, but they expect things to get better, not worse.  Unfortunately, that is not the way reality works most of the time. Unless it is a trivial change, productivity will take a dip when a team first implements the change.

The dip can be shown using the Satir Change Model in the figure above.  (Several other models exist.  Feel free to use the one you like.)  The model starts with the Late Status Quo.  This status quo is interrupted by either an internal change or a foreign element interrupting the team.  This change then leads to a combination of resistance and chaos.  As the team transitions into chaos, performance suffers.  The chaos phase is the most critical.  In this phase, people are tempted to abandon the change and go back to the old way of doing things.  If the team holds on, there is a time when the new change seems to click.  The change makes sense and productivity starts to improve.  This phase is called the integration and practice phase.  If all goes well, performance continues to increase until the team proceeds to a new status quo.

Now that we have some of the theory, how can we use this knowledge?

First, when you are looking to integrate change, talk about the dip.  Do you have time for the dip?  How long do you think the dip will last?  In the example above, the program had very aggressive, hard deadlines.  The teams should have discussed if they had time for the dip.

Second, decide how long the team will commit to the changes before abandoning the them.  I’ve seen teams abandon changes right as they were showing signs of “get it.”  I believe to this day that the team was transitioning to the integration and practice phase and was on the road to a new status quo.

Third, Stick to it!! Give it a chance to succeed. During the chaos phase, it’s easy to feel you made the wrong decision, but use your team grit and drive on.  If you are still having problems after giving it an appropriate amount of time, try to tweak your change.

Seeing a temporary dip in performance when making a change is normal.  If you know it is coming; you can prepare yourself and others for the dip.  When it’s not a surprise, the chaos the change can bring will be more manageable.

What dips in performance how you see where you work?

Image of Bridge by Jonas Verstuyft on Unsplash

“Fear of failing is the number one killer of grand plans and good ideas.” – Co-Active Coaching, 4^th addition.

Everyone is afraid of something.    Some people are afraid of spiders or snakes.   Others have a fear of public speaking or a fear of heights. Over my years of working with people and teams, there is one fear I believe we all struggle with but hardly ever express in words.   The fear of failure.

We live in a society where we are pushed to be perfect. This push can be overt, but most of the time it is subtle.  Instagram and Facebook are full of other peoples “perfect lives.”  Be honest, have you viewed a post from a “friend” and thought, even for a moment, that they have a better life than you?  Most of us don’t post our failure for all to see.

Fear of Failure has stopped many dreams and projects long before they start.  The consequences of failure don’t even need to be real.  The mere belief that failure could happen is enough to stop many dreams dead in their tracks.   The bigger the dream, the more the fear of failure can rear its ugly head.

One way to minimize the fear of failure is to break down a large goal into a series of short-term goals. For instance, losing 20 pounds before a tropical trip this winter might seem overwhelming but breaking this down into smaller goals of 5 pounds each start to seem achievable.  Why does this work?  It works because the task doesn’t seem as difficult or daunting, so we feel less fear and anxiety.

While smaller goals are a great start, a system is needed to turn them into reality.  Without a system, goals are just a dream.  With a system, the habits and behaviors that prevented us from achieving our goals start to change.    This is the power of combining goals with a system.

So how do goals and a system to support them work together?  Let’s look at the previous idea of losing 20 pounds.  First, we break this larger goal down into small goals of 5 pounds each.  Then we design the system needed to accomplish this goal.  For instance, we can take out the calendar and plan which days to go to the gym.  We will also need to adjust our food intake.  Maybe we choose to try a low carb diet or reduce the total calorie intake.  Once we have the systems set, we implement the new system.

Note: you will not create the perfect system the first time.  By starting with small iterations like a week or two weeks, we can evaluate if the system is working.  Are we able to get to the gym as we planned?  Are we dropping weight? What about our food intake?    By tracking our progress over a short time frame, we can determine if we are tracking to our goal or need to adapt the system.  If changes are needed, only change one or two things at a time.  Then apply the system for another iteration and measure the results.

Planning small goals with a system might seem like common sense, but it is common practice?  How many goals do you want to accomplish but haven’t taken the time to create a system to support them.  One of my personal goals is to become a better writer.  Instead of just dreaming about it, I’ve set up a writing system.  Writing posts like this are part of my system.   I would like to say that I follow my system perfectly, but I don’t.  I am human just like you.

What about you?  What goals do you have? What system can you create to accomplish your goals?

Photo by chuttersnap on Unsplash

With summer quickly coming to a close, it’s time for fall lawn care.  Since I have around 2/3 of an acre to maintain, I have several pull-behind attachments for my lawn tractor that I use.

During the summer, I’ve seen an increase in both sedge and several types of broadleaves.  Instead of separately spraying for each weed type,  I planned to spray for both at the same time.  Early one morning, I mixed up 12 gallons of the dual mix in my trailer sprayer and went to work.

An hour later, I was done.  The lawn was sprayed, and I was ready to grab a coffee and watch the weeds die.

Several questions lingered in my mind as I put the sprayer away.   Did I get all the weeds?  Did I miss a spot?  Did I calculate my mix correctly and applied at the correct rate?   I might be done but will it accomplish the goal?  Was it adding value or was I just busy? It can take several days to see if the weeds are starting to wilt and several weeks to know if the plant got enough weed killer to kill it completely.

At work, we need to address some of the same questions.  We see problems that need to be solved.  We talk to our product owner or the users to see what they want.   We gather the information and set out to develop a solution.

We then kick it out the door and call it done.   But does our solution really help the user?  Did we add value or did we just get something done?

In a 2009 paper on online experimentation at Microsoft, the authors reported that only about one-third of ideas designed to add value actually added value. (They measured value through the improvement of a key metric).  They go on to say that “it is humbling to see how bad experts are at estimating the value of features.”

The only true way to know if a feature or idea is valuable is to set up a feedback loop with the users.  This feedback loop might include sophisticated multivariable or A/B testing with a product.  It might include surveys or net promoter scores.  If you have a small user base, it is possible to visit the users and watch then use the product?

Quicker feedback is always better.  When spraying my lawn, it takes a week or two before I know that I got the mix correct to kill the weeds or if I missed a spot.

Getting timely feedback from the user is common sense. But ask yourself, is this common practice?  How well do you get feedback from your users?  How quickly do you get feedback on the features you are working on?  What can you do today to improve your feedback?

If it takes months to get features into the hands of our users, how open are we to making changes when the user tells us that it doesn’t provide value?  Are we open to going back to something we did months ago? Every organization has a different answer to this questions.

Checking items off a to-do list is needed, but adding value is the true goal.

It’s been about two weeks since I sprayed my lawn.  By sedge is dying the broadleaf weeds are just a happy as ever.  After re-reading the mixing instructions, I think I under applied that chemical.   Not the value I indented to provide.

How about you? What change can you make this week to verify that you are adding value instead of just being done?

I am a lifelong learner.  And as a lifelong learner, I tend to subscribe to various podcasts, lectures, and classes online.  The other day, I was listening to a class I purchased from Udemy created by a gentleman who lives in Scotland.

In one section, he wanted the listeners to envision things that make them happy.  As an example, he took some time to paint a mental picture of sitting by the fireplace on a cold day, on his favorite chair, reading a book, drinking a warm drink, wearing a comfortable wool jumper.

Being from America, I needed to pause for a second.  Did he say what I thought he said?  A Jumper?  The vision I had in my head was completely different than the vision he was trying to create.  Being that I was mowing my lawn at the time, I had to ponder what he said for a bit.

Once I got into the house, I was able to confirm what a jumper is in Scotland.  In Scotland, a jumper is a sweater, while in America, a jumper is a dress worn over a shirt or blouse.  This just reinforces how imprecise words can be.  Understanding what a jumper is in Scotland might seem trivial, but this shows how easy people can be misunderstood.

The imprecision of words come from the fluidity of language.  English, like every other language, is contently changing, adapting, and evolving.  Different areas can use different words for the same thing.  Growing up in the Midwest, we always referred to a carbonated sugary drink as a Pop.  While working with graduate students from the east coast, I heard the same drink called a Soda.  While working in South America, everyone referred to it as a Coke.

The imprecision of words isn’t a big issue when participating in face to face conversation. If I had had been in a classroom with the teacher instead of listening online, my facial expressions would have most likely alerted him that I didn’t understand.  One or two quick questions and we would have come to a common understanding.  (And most likely a quick laugh).

The imprecision of words can become a much bigger deal when we assume understand in a one-way conversation, like this article.  While I’m writing this, I have a clear idea of what I’m trying to say and the point I’m trying to get across.  I’m looking at the words I write through the lens of my understanding.  You, as the reader, are reading this through a completely different lens.  So how can we help bridge this possible gap?  By using stories.

“Storytelling is the most powerful way to put ideas into the world today.” –Robert McKee

Since the teacher in the video painted a mental picture of what makes him happy, I was able to confidently assume what he was referring to, even though I never heard a sweater referred to as a jumper.   If, on the other hand, he had just referred to the jumper without the story to clarify it, I wouldn’t have taken this a completely different way (and wondered about his clothing preferences)

Telling a story doesn’t always need to be done with words, pictures and drawings can be used.  Being educated as an engineer, I learned quickly that picture and diagrams are more effective ways to communicate an idea than a lengthy specification. The old phrase, a picture is worth a thousand words is as true today as when it was first said.

Storytelling helps confirm common understanding.  It helps others to understand your intent without having to rely on only the words you use.  We all have specific sayings and phrases we use that other may or might not know.  Stories don’t need to be long, just a few sentences or a picture or two to build common understanding can help.

So how did I do?  Did my stories help make the point?  Let me know.

Feature Image from https://www.freeimages.com

Silos are something that graced this nation’s landscape for almost a century.  Growing up as a farm kid, I could see them for miles in the flat county of north-central Iowa.  For many farmers, silo’s where the only way to store a winters worth feed for animals housed on the farm. It was a way to keep the grain safe by making sure nothing would get in and damage it.  One farmer by my hometown built a house out of a silo, complete with a fifth-floor penthouse that was used for the occasional square dance.  Their importance has been memorialized by the National Park Service through the Silos and Smoke Stacks National Heritage Area.

Although silos have a critical heritage to the American farmer, they have a different type of heritage within businesses. They are used to protect the inhabitance of a group or department and control external interference.   They often lead to slower decisions and missed communication.  They can contribute to missed deadlines and slower response time to the customers.  Most everyone understands the silos within a business are a problem, but many do not understand how silos can easily quadruple the number of conversation needed to address issues or to clarify a misunderstanding.

Let’s look at a simple situation within a software development team.  Let’s assume that a developer with the team is working on a simple task that will be tested by a quality assurance (QA) testers.  During the life cycle of this task, we notice the following communication.  We can map this out in below.

1. Before starting the task, the developer needs clarification from the Product owner
2. During the task, the developer needs one more clarification from the product owner
3. While setting up the test cases, the QA tester need a clarification from the Product Owner
4. While testing, the QA tester need a clarification from the developer.

If we look at the diagram above, we will see that this simple situation results in 4 distinct conversations.  Since we are assuming this is a simple task, we that don’t need multiple people to make a decision.  (I’m defining a conversation as an exchange of information with a distinct start and end.)  Assume everyone is available promptly, the time and effort required for the conversation are small compared to the task.

Now, let assume that the organization has chosen to silo the developer and QA testers into separation departments or organizations.  Within this model, communication with the developer or QA tester needs to go through a test lead or QA lead.  In this situation, we can map the conversations below.

As you can see, the number of conversations went from 4 to 14, almost a 4-fold increase in the number of conversations.  (#4 alone required six distinct conversations). This example assumes that each conversation is a perfect conversation and all the important information is transferred correctly and completely.  But we all know that this is not the case.  Ask any kid that has played the game of telephone how quickly a simple phrase can morphe into something completely different.  It is likely that at least one series of conversations will result in a misunderstanding and will need to have some clarifications.   In reality, the clarifications would lead to a 5-fold+ increase in conversations.

To compound the problem, these series of communications can take several days if the developers and/or testers are in a different country then the leads.  For instance, if leads on on-shore and the developers are off-shore, the difference in working hours can result in a multi-day turnaround for simple questions.  In today’s fast-moving environment, can businesses afford this type of delay?

One of the twelve agile principles states that “simplicity – maximizing the amount of work not done- is essential”.   Allowing silos to exist flies in the face of this agile principle.   Removing silos within a workplace is a significant amount of work, but it can be done.  Start out by mapping your conversations and trying to find one or two small changes that can reduce the number.  Over time, you to can break down the silos and spend more time doing valuable work.

What have you done to tear down a silo in your organization?

Cover image courtesy of https://www.publicdomainpictures.net/en/view-image.php?image=232605&picture=barn-tractor-and-silo

Two years ago, my wife and I flew to San Diego for a conference.  We decided to take a few days off after the conference to explore the coast, so we reserved a car at the airport.   After a 2-hour flight delay, we departed from the plane and made our way to the rental car counter.  The customer service agent looked up our reservation and noticed we reserved a midsize car.  She apologized stating they no longer had any mid-sized cars available and they only had economy cars available.  We had to decide what to do.  Should we compromise and rent a car a smaller car or should we stick to our car size preference and go to another rental car company?  Should we be pragmatic or dogmatic?

We all face this challenge on a regular basis.  As an agile coach, I see the day to day stress of needing to get stuff done.  This stress can lead people to “ignore” some of the “rules” of being agile.  Maybe a developer was pulled out of a sprint for a couple of days to address a critical bug in production.  Maybe a senior leader wants a feature included in the current sprint even though the product owner and the team planned to work on it later.  Perhaps the team members are shared between two projects because they both need to be done.  The list can go on and on.  Start pointing out the issues and it won’t be long before someone points out the benefit of being pragmatic.

One way I’ve trying to work through the dilemma of being dogmatic vs. pragmatic is by teaching the why instead of the what.  Let’s look at Scrum as an example.  According to the Scrum guide, Scrum teams are cross-functional and have all the competencies to accomplish the work without dependences on others.  Unfortunate, many organizations that are at their beginning of an agile adoption are divided into functional silos (development, architecture, testing) and are skeptical of the idea of cross-functional teams.  By explaining the why of a cross-functional team (reduced lead time and improved communication) instead of just insisting, I have found that leaders and team members can better work together to find a solution that will get the organization closer to the goal of cross-functional teams.

Once you understand the why, you can better understand what is critical and what is not.  This understanding will also help you decide when to be dogmatic.  For example, let say I arrived at the rental car counter and the staff tells me that they only have one car left.  It is a mid-sized like I wanted, but the car has one small difference from the rest of the fleet.   The seatbelts have been cut out, and the airbags have been removed. They explain that the seat belts and airbags account for a small percentage of the car and the car has been recently serviced and will get me where I want to go.  From the outside, it might appear like any other car, but I would consider it is unsafe and would refuse to rent it. The same thing can happen with a team that looks to be agile from the outside.  By implementing a practice without understanding they why the team might be causing more damage than benefits.

While deciding when to be dogmatic or pragmatic can be a struggle, knowing and using the why behind the rules and help clarify the situation.  By bringing others into the conversation and talking about the why, you might find a different solution.     When I was presented with my options for the rental car, a manager overheard the conversation and offered a different solution.  Apparently, a mid-sized car just got returned but the rental car company didn’t have time to fill it with gas and wanted to know if that would work.  We took the third option.

Image from https://www.overdriveonline.com/one-way-streets-and-traffic-in-nyc/one-way-sign/

It has been more than a decade, but I vividly remember when I got my son his first bicycle. I spent more than an hour in the store trying to make sure it was exactly what he wanted. I zeroed in on a silver-framed, single-speed BMX-styled bike with a hand brake for the rear tire. I also walked out the door with a matching helmet and a new set of training wheels. It was a week before his birthday, so I had to keep it hidden until the big reveal with the family.

As his birthday approached, I prepared myself for his first try at riding a bicycle. I knew that my son had been cautious from an early age, not wanting to try something unless he was sure he would succeed. A small setback could cause him not to want to ride his bicycle for weeks or months. I had to find a way to assure him that he wouldn’t fall and skin his knee the first time he tried. If I didn’t find a way, I wasn’t sure whether he would jump on the bike a second time, so I bought the training wheels to help him succeed.

In the grand scheme of things, training wheels can be viewed as a waste. They cost money, and they take time to install and maintain. They slow you down and make it harder to turn. They are a sign of a young rider who could potentially build bad habits. But, for many, they are the only way to learn to ride a bike. Although some learn without training wheels, most need them.

Agile training wheels: Opportunity for self-management

Teams can be the same way. Some teams will try, fail over and over again, and still pick themselves up to try again. Other teams, because of the personalities of people within the team or because of the corporate culture, freeze the first time they fail and want to go back to the old way of doing things. They feel safe with the familiar. For cautious teams, team training wheels work best.

For example, I led Agile transformation for a program with three project teams. One team was comfortable with the project manager telling them what to work on and who should do each task. In a perfect Agile world, team members would self-assign stories, but this team hadn’t had the opportunity to practice this skill. As a temporary solution, I started out by assigning stories and tasks to the various team members. (Please keep reading. I had an exit plan identified when I started assigning stories; I just didn’t tell the team yet.)

Like the training wheels on bikes, team training wheels come at a cost. They usually slow down the team and result in inefficiency. They can also build bad habits. If I had continued to assign stories, the team would have remained reliant on me, as they had been on the previous project manager. But if done right, the “training wheels” can give the team time to experience and practice a skill before having to take responsibility for it. The best training wheels are temporary and provide help in a specific area — in this case, self-assigning stories.

As with all projects, I couldn’t correctly predict how long the stories would take. Some team members would finish tasks early, and others would take longer. The team would ask what to do next. Over the next couple of sprints, I went from actively telling the team what to do to standing back and watching the team manage themselves. Before they knew it, team members were self-assigning stories and would even switch stories if an impediment showed up during the sprint.

Not all teams need training wheels, but for those that do, they can mean the difference between success and failure. For team training wheels to work, they need to be temporary and provide help in a specific area. Before starting with a set of training wheels, define an exit strategy with a rough idea of how long the training wheels will be on and what needs to be accomplished to be able to take them off.

Originally Publish on Scrum Alliance.  – https://www.scrumalliance.org/community/articles/2018/january/does-the-team-need-training-wheels

Photo by Chris Becker on Unsplash