Tag Archives: Success

A fractal Cube

Our Team Doesn’t Need to Retro

TL; DR

Sometimes as a team becomes successful, and they have had very successful retrospectives, they stop getting value from those retrospectives. Something must change for the team, in its new state, to gain more value from this exercise. I suggest more retrospectives focused on smaller things.

Pain of Stopping Retrospectives

I have been part of a team that stopped seeing value from retrospectives. In fact, I have been part of many teams that found themselves in this situation for different reasons. In the past, those teams just stopped doing retrospectives until we realized things were very out of whack.

Then, as we scampered, and we flustered, and we struggled, we often found ourselves failing to pick up the pieces neatly. The few times we could recover was after months of struggling, the other times… Well I no longer work at those places.

Stopping retrospectives has consequences. Continuing retrospectives that are unfruitful also has consequences. A process that becomes tedious, and without any gratification, also becomes soul sucking.

This starts to feel like a “no win” scenario.

Increased Frequency, a Story

The team I am currently on hit this wall about two months ago. We did something very different. We increased our retrospective interval to once a day. The world seemed to change overnight. The trust and communication we had been building up to become successful and now started to pay off in large quantities. The daily retrospective allowed us to address issues and wins, as they were more fresh, meaning more of them were addressed and captured into our working agreements.

These new insights were on smaller things, but these smaller things made for bigger improvements. It was amazing, these retros were also shorter – about half the time. I felt energized and we are even more successful for it.

A couple of weeks ago, we tried another experiment, we turned up the frequency again. Now we hold a retrospective every time emotions run even slightly higher than normal. Some days we only have a single retrospective; other days we will have five. We always have our end of day retro (more on this in another post), however we let emotions and insights guide us now.

Advantages of On Demand Retros

These retrospectives are only about 10 minutes at the longest as they now focus on a single insight and outcome. By acting on focused events we have started to notice patterns that were subtle enough to be missed when we bundled everything into a single retrospective. We are becoming even more successful and our team is happy.

That is not to say it is easy. It takes work and trust to have retrospectives at this kind of interval. The payoffs are well worth it. The mini on the spot retros are some of the most effective I have ever had. We try all kinds of experiments now. Some last an hour, others a few weeks, but all are freer to try radically different approaches.

Conclusion

When your team is successful and safe, your old retrospectives may stagnate. They may have addressed all the larger and most visible issues, and you need a tool to help address the smaller, and larger impacting issues. We found that tool to be increased retrospective frequency.

Smaller, more frequent #retrospectives help when retros start seeming like they have no value. #Agile Click To Tweet

Myth of Management With No Hierarchy

TL; DR

Leaders exist; therefore, hierarchy exists. A flat organization is not truly flat, it is made of many leaders. Those leaders have the responsibility to train others to replace them. The company has the responsibility to help those leaders be successful and be diligent on keeping things safe.

A flat organization is not truly flat, it is made of many leaders. Click To Tweet

Leaders are Essential

‘The Harvard Business Review’ has the article: Hierarchy is Overrated. This article paints a very favorable view point of flat hierarchy, but does not address the need for leadership at all. People will become leaders. This is an essential and natural process.

However, much of what needs to be accomplished by leaders, functioning in a flat hierarchy, is not natural. One of the main responsibilities of these leaders, is to move to stop being a leader, the sooner the better.

The way a leader stops being a leader is to train and inspire. Say that someone feels passionate about team building. They take up the reins, figure out ways to start building team communication and unity. They start the ball rolling. Now they need to look for someone else who cares about team building. They will collaborate, train, and inspire them to both take over and train someone else.

Potential Problems

There are a host of potential problems. Everything from dissatisfied employees to locus of control. Most problems will stem from one of these three root causes:

  • Denying the existence of leaders
  • Team not trained in essential leadership skills
  • Organization not really being flat

Leaders Exist

Leadership needs to be recognized, and its existence acknowledged. This allows an organization to better define how leaders behave and what it means to be passionate about some aspect of the organization. Don’t deny them, embrace them, try to understand them.

Everyone Trained as a leader

Train everyone to be leader. This is a lot of work, but it pays off as people can step up and handle issues and opportunities that they feel passionate about. Leadership can be more easily distributed and handed off from one leader to another. Everyone is capable in guiding and supporting leaders as they venture into new ideas and interests.

Here are a few sources I recommend:

A Flat Organization

Having an organization that has a distributed hierarchy can be challenging. The leadership, the people with the titles, needs to support it. They must trust people to do the job, and enable everyone to be trained. The highest paid people in the room have the greatest potential to do harm with the simplest word.

So, there is a need to prevent their hidden biases from polluting down into an unintentional hierarchy with certain people being ‘more equal’ than others. This can be done by really paying attention to building a safe environment. By encouraging those beneath them, in title at least, to contradict them and actively stepping back, these biases become smaller.

Giving up Control

The goal of every leader, should be, to eventually not be the leader. Each person should be looking at passing the torch, and ensuring multiple people can replace them. If this is not done they become the bottle neck and get in the way of success. The idea is that everyone can take a vacation and nothing stops working.

Each leader finds someone else who is passionate about the task at hand. They share responsibility, and train as needed. Eventually they will stand back and give their protégé or partner a chance to run things.

In Conclusion

A truly flat hierarchy does not exist. This is a good thing. What real world flat hierarchies enable is everyone with the inclination can be a leader. There are difficulties which can be overcome with hard work and trust. It is rewarding to work in one of these organizations and they can be more effective if you acknowledge the existence of leadership, train for it, and upper management supports it.

Onboarding a human into a human system

Onboarding is much more than a meeting with HR, it is the integration of new person.

TL; DR

Onboarding is an important endeavor. If we approach it seriously and conscientiously we can make the new person feel more welcomed and part of a team.

Initial Onboarding Meeting

Human Resources has a job to do with its onboarding process which is important for all kinds of reasons. This onboarding covers legal issues and is often the first, if not only, exposure a new hire has with the company’s culture as defined by its executives. However, this should only be the start of the onboarding process.

Integration

It can take several months to integrate a new person into an existing team, so that they are emotionally and mentally part of that team. During this time, we need to help them, guide them, and be there to support them as they have questions.

Our goal in onboarding should be to help and guide a new hire in becoming a member of a team. Click To Tweet

My department has extended its onboarding process to three months and provided the new hire with a buddy. We choose a buddy from the newest employee who has been at the company at least six months, who are on the same team as the new hire, and is willing to accept the responsibility. The buddy is chosen this way to maximize the empathy for the new hire since buddies have the most recent memory of what it was like to be a new hire.

Buddies

They are a buddy, not a mentor. Buddies are there to answer questions and give support. They are not there to teach. Which is to say buddies are not given any authority over the new hire and are a model of the flat organization structure of the department.

Department and Team

We also extend the onboarding process to the team and the department. When a person is added to a team, that team is no longer the same team. To emphasize this fact, the team, the new hire, and their buddy all undergo training about the Satir Process Change Model by Virginia Satir.

This creates a cycle of repetitive learning for the new hire. The new hire learns about the process as part of their onboarding. They then learn about it again with each new hire brought onto their team. They again learn it when they become a buddy. We do this because we believe understanding of the Satir Process Change Model is important to the successful integration of a new person into an existing system.

The team and department then undergo activities to introduce the new hire to everyone, and to introduce everyone to them. These activities might include a Market of Skills, a Lean Coffee on hobbies, or many other activities. One of the main goals of an onboarding process is to make the new person feel welcomed, wanted, and appreciated. These activities done over a three-month period seem right to me.

Request for Comment

How do you, and your company/department/team approach onboarding in a new way? I would love to hear about it.

Greatness

I have been thinking about great teams and teamwork lately. Greatness is not something easily attained or held, but easily lost.

What does it take to be part of a great team? Click To Tweet

TL; DR

Greatness slips from our fingers at every moment, we must actively pursue it and not compromise for less. We must strive to ensure all voices are heard, that quality is maintained, and room to experiment is held. Anything less defeats greatness.

Acceptance

To ensure a great team, there must be an agreement of acceptance. All proposals must be met with a “yes and…” mentality. People’s views, emotions, concerns, and ideas need to be welcomed. Without this welcoming safety is destroyed.

Without that safety new ideas are killed before voiced. Trust degrades, and people fall into old habits. Greatness is lost, because innovation stagnates.

Acceptance can be achieved as long a few people are willing to champion it.

Uncomfortableness

The feeling of being uncomfortable signals the greatest chance for improvement. When the team “leans into” uncomfort and addresses the smallest things trust and acceptance grow. It is true that you need a seed of acceptance before this can happen; however, facing the feeling of being uncomfortable grows acceptance beyond its normal bounds.

Facing uncomfort, is very tenuous. Where acceptance can grow with a few champions, the ability to face things that make us uncomfortable can crumble with one criticism. This must be protected, and defended or the things that erode trust will remain hidden.

The most powerful and useful conversations happen when we solve real problems. If we cannot bring up those problems greatness dies.

Excellence

Once we have acceptance and the ability to face what makes us uncomfortable, then we need excellence. Excellence is the constant striving to do better than we are currently. This includes technical excellence, process excellence, teamwork excellence, and communication excellence; along with many other forms of excellence.

Excellence ensures quality of what we do, and constant improvement. It allows for us to make mistakes and learn. It allows us to revisit and revise old decisions. Excellence measures greatness, but by paradox excellence cannot be accomplished without the other things I mention here.

Experimentation

We don’t know how to improve, even if we do, the context will change. We cannot achieve excellence without the ability to experiment. The ability to make a judgement and be wrong.

Experimentation feels natural on the tongue, but we tend to subtly resist it. To be an experiment, four things must be true.

  1. There must be a possibility that the hypothesis is wrong.
  2. There must be a defined end for the experiment.
  3. Success and fail criteria must be known.
  4. The actions of the experiment must be defined.

In Short

Who does not want to be part of a great team? Greatness is simple to achieve but in no way easy. It requires acceptance of all ideas, the ability to face all uncomfortableness, a strive for excellence and continual improvement, and a willingness to experiment.

Greatness is simple to achieve but in no way easy. Click To Tweet

Without all these things, we cannot be great. With them we will always be traveling toward greatness.

Why I believe in #NoEstimates

Before I start, as I will be talking about different work experiences, I need to state all my opinions are my own. They do not represent the opinions of my current or past employers.

That being said now let me begin.

What:

When I was first introduced to the concept of #NoEstimates I was a mid-level developer and thought that it was a wacky idea that could never work. Later, still a mid-level developer, I decided that working with estimates was stupid. Then I grew up and learned that the world was not black and white. I listened to what @WoodyZuill had to say and tried to understand the meaning.

Experimentation:

My first experiences with trying #NoEstimates had nothing to do with Woody. I worked in a small company that hired me to take over a legacy VB.Net v1 project which had failed so badly they fired the whole team. They had no source control despite having 13 versions of the application deployed, and only one copy of official source code that didn’t match any of the deployed versions. I hired a new team, we focused on bug fixes that were discreet, understandable and easily repeatable.

We gave no promises and made #NoEstimates. We focused on discovering value, by giving users fixes to things that were easily understandable. Within 3 months not only did we have source control, but we managed to reduce the number of variant applications and we were deploying every week. We had moved beyond bug fixes.

We were so successful, that the company sold in under 2 years. The CEO was able to retire, based on the value we delivered. We did this entirely without estimates.

Tutelage:

Later, I got to experience #NoEstimates in a completely different way. The team I was part of worked on custom line of business applications. We often produced software for different departments within the company. Here we focused on changing discussions that were given to us. We always asked: what is one thing that if we gave it to you now would make your life better? Then we tried to understand that enough to figure out something that is discrete, understandable and has a clear definition.

Once we did that, we would work to deliver it. Once it was delivered, we would follow up with the users to see that it met their need. If it didn’t we changed it. When the need was met correctly, we were told what the next need was.

That is how we worked. The company never had worry about interrupting us, because our deliverables ended up taking less than a couple of days on average. This was not a precondition, or intentional. It happened because of how we isolated something to work on. Occasionally it would take significantly longer. That was ok also because it meant that there were more unknowns in that piece.

 

So What:

#NoEstimates as I have witnessed it accomplishes two things. The first is it moves authority to make business decisions to the current point in time. By delaying the act of what has priority, to the last responsible minute the business is better able to cope with business as it is.

The second benefit is that it places business decisions in the hands of those who have the knowledge to make the decision. I always say that programmers are business people who have not been correctly trained in business. I say that because every line of code is a decision about how the company does business. By focusing on discrete deliverable chunks and using those chunks to measure value/need, a lot more of the decision of what goes into the application goes to those who are responsible for the business.

 

Now What:

#NoEstimates is the beginning, not the answer. There is a lot more exploration that can happen out there. Let’s focus on improving how we do business, and share our successes and failures. Eventually we will always find better.

You are a Star

I believe I suffered from Imposter Syndrome for most of my career, and if there is one thing I can say I have definitely learned is that you are the star. No matter your experience level, language, or technology bent; the fact that you are out there producing code makes you a star.

If you are not producing code: do so. I can promise you one sure thing: No code you write will ever be as bad as some of the code I have personally put into production. I wrote some things when I was a junior programmer that would make the faint of heart faint. Trust me, I had to run a production application in debug because a variable would lose its value. To keep the program working I would have to edit the memory location and then hit continue.

But that is the beauty of code. It is so valuable that even the worst written application, if it meets its basic need, will be profitable. The application above was so successful that the company’s competitors would hire us to do the work under their name.

Code is value. As long as you are producing code you are producing value.

Now I am in no way saying to stop learning, or searching for a better way. However, I am saying that you should go and produce. Build something, either for yourself or someone else. When you are done, build something else.

Searching for perfection will not help you discover that you belong. It will, in fact, do the opposite. Only by cutting your teeth on code will you begin to see the value you bring to the community.