Identify The Organizational Anti-Patterns And Common Smells

Introduction:

Before identifying the organizational anti-patterns and common smells, let’s first understand what patterns are all about.

C.Alexander in his book, “The Timeless Way of Building” written in 1979, defines patterns as follows:

A pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice.

The opposite of this pattern is an anti-pattern, something that should not happen and that usually happens all the time, given the kind of actual transformation that you are talking about.

Let’s look at an example of an anti-pattern. Consider the scenario below.

In this example, the coach asks the client’s permission to give feedback on their stand-ups. The client welcomes the feedback. The coach makes the client aware that he does not use the three questions in his stand-ups and adds value to the stand-ups. The client acknowledges this observation by the coach but justifies that they have tried that approach, and it felt really disconnected. He says that his approach feels more like a team.

The coach then references the book on scrum and emphasizes that the stand-up serves a particular and important purpose. It’s essential to maximize benefits and not waste people’s time. That’s why he should cover what was done, what will be done, and any impediments. The coach then enforces that the stand-up from Monday must include these three questions.

As per your understanding of the scenario, what is the coach doing?

Is he advising, or is he coaching?

Clearly, the coach is advising and not coaching in this example. He wants the client to implement what the coach learned in his scrum class with his team.

As a client, how would you feel in this situation?

Unfortunately, this situation repeats itself in many organizations. Most of the time the ‘coaches’ end up telling people, advising people, and consulting rather than taking a coaching stance.

This example is one of the anti-patterns in organizations.

Let’s look at specific anti-pattern scenarios to get a better understanding.

Following are some Specific Anti-Patten Scenario:

There are many behavioral patterns in an organization. For example, consider the context in which Developers want to work independently, and everyone works on one user story at a time. And then, they sit on the user story until the end of the day or until the last day of the sprint.

Finally, the burndown chart looks something like what is shown in the chart below.

The black line is the ideal scenario, but the actual work gets done in red. The black line is how work should get done in small increments over the sprint cycle, but in reality, the burndown spikes in the last few days of the end of the sprint cycle.

This anti-pattern gets repeated in many organizations over and over again.

Anti-Pattern: Maximizing Utilization and Reporting Planned Vs Actual Hours

At the end of the sprint, the developers have often questioned their hours variances. This is because they had committed X hours to the task, and you completed it in X + Y hours, where the Y is the variance hours.

To make matters worse, project managers are worried about keeping everyone busy until the end of the sprint, where they are more output-focused than outcome-focused.

This is also one of my most interesting observations, given the number of teams I have seen in my career. This is the traditional approach of doing things, and if you keep doing things in the same old way and expect different results, you might not get different results.

People keep implementing the same old practices in the name of Agile, but they expect different results. This approach leads to a waste of time as well as not really identifying the gaps for process improvement.

All in all, if someone is working on maximizing utilization and reporting hours variances, they are creating a lot of waste in our ways of working.

Anti – Pattern: Agile Fixed Price Contracts

One thing that I have heard many senior leaders say is that Agile is only execution. They expect you to write a traditional contract with a fixed cost, fixed time, fixed scope and execute it in Agile.

Isn’t Agile all about welcoming changes and transforming a client’s evolving vision into a product?

How is it even possible to execute Agile when you are given a fixed time, fixed scope, and fixed cost?

The situation is breaking two of the most critical Agile principles.

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Anti-Pattern: Scrum Masters Have No Idea of Scrum

Many people ask me, who is the best person for becoming a Scrum Master? Is it a project manager or a business analyst, or anyone else?

My response is this. Scrum Masters are those people who are real experts in the scrum. But nowadays, if you look at job postings in the market, some say “Need 7+ years of experience as a java scrum master”!!

It is common these days to have a scrum master who knows everything but SCRUM.

One of the major reasons why scrum implementations don’t really kick off in organizations is because the scrum masters are one of the weakest links in the node. Scrum Masters who do not know about scrum cannot clearly articulate the benefits of the scrum.

Organizations find it difficult to understand the scrum master role because many people don’t subscribe to the same school of thought. They have a very vague understanding of scrum and the responsibilities of a scrum master. As a result, many people think that scrum master is a part-time role; scrum masters are only supposed to facilitate meetings. Some people even question the scrum master’s tasks 8 hours a day. They believe that the job of a scrum master is to schedule outlook meetings, and book meeting rooms.

Some of the anti-patterns of the scrum master that I have observed are as follows:

• Less experienced developer in the team playing the dual role of a scrum master while being a developer.
• Scrum Master is more of a rotating role where people take turns to play scrum masters.
• Scrum masters are not empowered in the organization. They are expected to do what they are ‘told’ to do.
• Scrum masters report to the Manager and take over all the delivery responsibilities.
• Designating “left over” people to the role of scrum master, for example, any manager who is not assigned any work or project, or a business analyst who is on the bench or a test engineer who has no tasks assigned.
• Scrum masters who don’t know how to train people on scrum.
• Scrum masters who cannot identify the impediments or they themselves become an impediment because of their own personality.

Anti-Pattern: Senior Leadership Undoing Agility (Mostly Unintentionally)

Most of the time, senior leaders are unaware, but they are undoing Agility.

The following bullet points emphasize how leaders undo Agility:

• Leaders, asking for traditional metrics and reports.
• Leaders are output-focused and not outcome-focused.
• Leaders encourage rewards such as ’employee of the month’, ‘star of the month’.
• Leaders think that ‘Agile is only for teams” and “not for me”.
• Leaders, discouraging cross-functional team and self-organization behaviors. <.li>
• Leaders put a “get it right the first time” condition instead of nurturing a “continuous learning” environment.
• Leaders, not encourage a common purpose or alignment for the teams.
• Leaders create systemic dysfunctions that unsettle the purpose of Agility.
• Leaders create governance models that undo Agility.

I see in organizations most of the time that leaders are playing their part but undoing Agility in the process, knowingly or unknowingly. I have seen that leaders are not ready to learn, who don’t attend agile training, and by default, their demeanor is that ‘they know everything.

Anti-Pattern: Product Owner for Teams

A product owner by definition, is the leader responsible for maximizing the value of the products created by a scrum development team.

The anti-pattern thus is that there will be one product owner per team. Renaming one business analyst overnight into a product owner is also one of the anti-patterns. Many people assume that the only role of a product owner is to write user stories. Product owners are not empowered to make decisions.

When people ask me, who will write user stories, I tell them that the best typist in the world will type it. I believe that developers can write user stories with the help of the product owner, and when they do, they understand the product even better, but some people get offended by this idea. They think that developers should just implement what they are told to implement. What they don’t know is that the development teams write the majority of user stories.

Another anti-pattern is to create a lot of intermediaries as product owners, such as proxy product owner, technical product owner, product owner 1, product owner 2, onsite product owner, offshore product owner, and so on.

Most of the organizations I have seen are project-based organizations, and bringing in a product owner is a big change for them, and that’s why they struggle with it.

Anti-Pattern: Blind Scaling

A team that struggles with their own code, now they are scaled, irrespective of the framework used for scaling, leads to scaling of previous problems and not scaling of scrum or agile. It becomes such a difficult situation for a team if blind scaling is applied to them, especially the teams with massive technical debt. They are already slowed down because of the debt, and now the new scaling framework imposed on them makes it even harder for them over a period of time.

A yardstick needs to be applied even before the organizations decide to scale, and scaling should be implemented only when the yardstick criteria is met. Sometimes you even have to descale to simplify your problems.

Most of organizations take pride in complexity. And that’s why, in order to simplify your problems, you have to simplify your organization.

You cannot operate in chaos.

For example, I was coaching in a bank, and they had a huge amount of technical debt. They had around 1242 defects, and they called all these defects as minor defects. Their unit test coverage was at 60%. They didn’t write a single automation test.

Then, when a famous scaling framework was imposed on them, the situation became terrible for the teams. They had to scale with 8 other teams. They had to integrate their pieces with 8 other teams. This can be a nightmare for a team.

Organizations should be really careful with scaling. Instead of getting benefits out of scaling, they end up creating more problems for their teams, and the problems get bigger with time.

Common Smells

The term ‘smell’ refers to the occasional negative characteristics of a process or practice that could adversely impact the quality of the outcome.

For example, sometimes, we feel lazy and skip retrospectives. Sometimes people don’t come for daily scrums because they don’t see value in that. Many team members don’t even understand why they are expected to do certain things a certain way, and that imposes a serious challenge.

When enforced, they attend these meetings half-heartedly, or they don’t even show up. They find these meetings boring, repetitive, and monotonous.

There is an incident which I would like to share with you. A senior developer with 10 years of experience once told me that he used to attend retrospectives diligently once upon a time. At that time, they used to write down a lot of actionable items, but no one even cared to act on these actionable items.

In this example, this senior developer did not see any value in those retrospectives.

If people are not involved, if people’s opinions are not appreciated, if people are not engaged, then they don’t love your meetings and they don’t come to your meetings.

If you look at your own retrospective meetings, there are one or two dominant speakers who talk the most, and everyone else looks at each other, asking, “why are we even here?”.

Sometimes the sprints get extended. Sometimes there is one team working on two parallel sprints. All of this happening in the name of scrum and agile. It’s really sad.

Techniques To Coach Team Level Anti Patterns

I am going to give you a high-level idea of what worked for me and what didn’t work for me.

Following is one way to cure anti-patterns like a doctor.

Symptom, Root Cause, Solution

Step 1: Inspect the symptoms of the problem by performing a diagnostic test. Without a diagnostic test, everything is trial and error.

Step 2: Find the root cause of the problem. This will expose the underlying systemic issues.

Step 3: Find the solution.

Let me share an example. There was a time when my senior leadership once said that everyone in the team is a really great developer. And that they have sufficient competency to take up any challenge. That was their assumption.

But when we started working with a few teams, we found that 60% of the developers used google to search “how to write an algorithm?” based on their day-to-day job.

Obviously, it meant that these people didn’t feel safe to ask for help and support, that they needed training or mentoring, or they needed to be paired with a senior developer.

Because these people didn’t ask for help, the assumption on top that they are competent developers who can take up any challenging task was not challenged.

As a coach, I tried to explain with a positive intent that these guys needed help. And if they are not supported, it would impact negatively in the long term.

As we start to become transparent, the benefits of transparency start to pay off in the long run.

I have also observed in my experience that people who ask for help are assured of help on their face but are judged behind their backs. That is also an anti-pattern where people don’t feel safe to ask for help.

Jutta Eckstein’s Techniques

Another technique is Jutta Eckstein’s techniques to coach organizational anti-patterns.

WHAT – > NOW WHAT – > SO WHAT

It’s kind of a feedback loop.

What is the current situation? What should we do? And How can we improve?

These cycles give us a really good insight of most of the problems that we face and the experiments that we want to perform.

Doing retrospectives with the best intent to improve is another technique of addressing the anti-patterns.

Coaching Techniques

Following are some of the coaching techniques to fix the anti-patterns.

International Coaching Federations (ICF) Coaching Competency Model.

This is a big study by itself. People study these competencies for several months and then they appear for the certification exam. If someone wants to fix these anti-patterns then they can try these coaching techniques.

GROW Model

is also one such technique

Marshall Goldsmith Stakeholder Centered Coaching:

Systems Thinking” to explain cause and effect:

Fun Therapy To Change Behaviours:

Watch this video to know how fun therapy changes behaviors.

Conclusion

I have been an agile coach for a very long time and as much as I am impressed by the speed at which agile is being implemented in organizations, these anti-patterns listed above disappoint me.

Instead of looking at Agile as an execution methodology, organizations must start to look at Agile as a philosophy, where everyone from top leader to team members take the time to train themselves and understand it’s principles before making critical decisions.

It is also my observation as a coach that an agile approach must be implemented not in bits and pieces, as per the leadership and organizations’ convenience but by abiding by the Agile principles.

Efforts must be taken to improve adaptability by making changes in the process more fun to implement than just being enforced on team members.

What are your thoughts on these anti-patterns?

Have you observed some anti-patterns in your organization?

Which are they?

Please share in the comments section.