DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones AWS Cloud
by AWS Developer Relations
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones
AWS Cloud
by AWS Developer Relations
  1. DZone
  2. Culture and Methodologies
  3. Agile
  4. Are You Rocking the Boat or Flowing Between the Rocks?

Are You Rocking the Boat or Flowing Between the Rocks?

As a leader, when you introduce change, whether that is Scrum, large-scale Scrum, or even Agile practices, do you prefer rocking the boat or flowing between the rocks?

Joshua Partogi user avatar by
Joshua Partogi
·
Sep. 19, 18 · Opinion
Like (2)
Save
Tweet
Share
4.56K Views

Join the DZone community and get the full member experience.

Join For Free

One of the challenges I face working as a Professional Scrum Trainer is reading what is in people's mind when they are silent. In a classroom setup, silence can mean many things and it depends on the local culture. In some cultures, silence can simply be read as respect given to the person who is talking. Silence can mean "I agree with what you said." Silence can also mean the person may not be fluent in the language delivered by the trainer. Or it can also mean, "I really don't want to be here!" Generally, I prefer people to be having discussions and be loud in the class.

Addressing the Silence, an Anecdote

So, I was conducting this class where the majority of the participants came from one company. Now, this company is a huge multinational company who is trying to implement Scrum at large scale across multiple continents. Software development is not the main activity but only a supporting activity in this company. This company does not make money from software, in fact, the software that is developed by the software developers is only used as a tool to test the microprocessors that are built by the other departments.

There was one person whom I noticed that didn't seem to feel comfortable being in the class. Let's call this guy Eric. I was interested in him and observed him from the morning of the first day. He was very silent and did not seems to be engaged in every discussion we had in the class. You could see from his body gesture that he felt like a prisoner in the classroom. I kept observing him, curious why he did not seems to be interested. Could it be because I didn't create enough spark to excite him? Without wanting to blame myself, I thought maybe it was because he's not fluent in English that he was not joining the discussion. So, I just let him be throughout the first day.

At the end of the first day, I ask everyone: "Is there anything that we should do differently tomorrow?" I was expecting to get feedback from Eric. Of course, everybody including Eric did not give any feedback about the class. So, I thought that everything must be alright.

When I went back to the hotel, I kept thinking about Eric. Then I thought, how foolish could I be? If Eric is not comfortable talking, he won't be comfortable expressing his needs in front of the whole class. So I thought the strategy needs to be changed tomorrow. Rather than asking the whole class, I am going to talk to Eric during lunch time to confirm what I have observed in the class.

On the second day, I approached Eric during lunch time. I asked him if we could talk privately. Eric seemed surprised—maybe he thought that he was in trouble or something. I started a conversation with him.

JP: I noticed that you seems to be uncomfortable. Could it be because something that I said in the classroom?

Eric: (silence).

JP: ( not knowing how to translate his silence) Are you getting what you need in this class?

Eric: (raised eyebrow).

JP: Do you really want to be here in this training?

Eric: ( started talking). Honestly no.

JP: What makes you feel that you should not be here?

Eric: I was forced by the other Agile coaches in that room to come to this training.

JP: That is interesting, do you know why they want you to be here?

Eric: I am not really sure. They are really pushing this Scrum thing. They want everybody in the company to use Scrum. It is the company direction. I head the department where my team members are reluctant to use Scrum. Maybe they are trying to convince me by sending me here so I can convince all of my team members. The company also already invested lots of money in this large scale agile framework so they want to move really fast in the transition.

JP: I see. Do you think Scrum is relevant for your context?

Eric: I think Scrum is good but many aspects are not relevant for what we are doing.

JP: I can understand why you feel you shouldn't be here.

Eric: Thank you. I wish those Agile coaches would at least listen to us first rather than forcing their way.

From Eric, I've learned that there are two major approaches to introduce change to our organization. The first is what I call rocking the boat and the second is flowing in between rocks like water in the river.

1. Rocking the Boat

As Scrum is increasingly becoming popular and becoming the new de-facto method for software development, more and more companies want to use it and transition to Scrum as fast as possible. The trend these days is no longer Scrum but large-scale Scrum. However many companies do not have the patience to transition—they just want to install Scrum and hope everything will be improved the following day. Perhaps it's because many Agile practitioners and trainers are using the tagline "speed and time to market" during the marketing process that so many leaders do not have the patience to wait anymore these days.

Leaders who introduce change by rocking the boat will find resistance along the way. The success of change really depends on the scale and the heterogeneity of the organization. Small organizations where the people are relatively homogeneous may find it easier to flip the boat and see the effects of change faster. The level of resistance for a large-scale heterogeneous organization is much higher than the small homogeneous organization. If the level of resistance is high, getting to the point that is expected will take a relatively long time.

Even though rocking the boat may seem easier to do because you just authoritatively tell everybody to change according to the textbook, getting the expected result actually takes longer because there is resistance that is impeding change to happen sooner. Leaders who choose to rock the boat will only get compliance from their people. Leaders who introduce change by rocking the boat is what I call the ambitious leaders.

2. Flowing Between Rocks

"People don't resist change. They resist being changed."
― Peter M. Senge

So, how can we introduce change in an organization without creating high levels of resistance? I've learned that we need another way of introducing change, like Scrum, without rocking the boat. We need to understand that people resist being changed. If you are a leader in a multinational company, you need to understand that your people come from many different cultures and backgrounds. A single approach for a heterogeneous organization does not cut it. You need to connect with people and embrace them at a personal level to see what they think is the best way to approach the change. Get them engaged throughout the change process. You must move in small steps and ensure that resistance is being well managed. Ensure people who are going to be impacted by the change that you are going to be there with them during the pain caused by change.

Scrum is a framework that should help people work, it should not be used like prescription medicine, it should be used according to the context in the organization. Not only Scrum but also large-scale Agile/Scrum framework or even any other Agile practices. Copying how others in a case study do Scrum or scaling Scrum will not work for your context.

Flowing in between rocks is much harder than rocking the boat. It takes more time, hence it takes patience, and is an art in itself. From my personal experience, when we are connected with people and get their engagement it actually becomes easier as we have invested time to manage the resistance up front. Leaders who want more than compliance should flow like water in between rocks. Leaders who introduce change by flowing in between rocks is what I call the humble leaders as they invest their time, they have the patience to connect with their people at a personal level, they value their people, and they work to have empathy for how change is going to be painful for their people.

Most people introduce change like Scrum by rocking the boat. But the more I meet people from many different cultures and backgrounds, the more I realize that it can't always be that way. We can introduce change like Scrum without creating disruption. As a leader, when you introduce change, whether that is Scrum, large-scale Scrum, or even Agile practices to your team or your organization, do you prefer rocking the boat or flowing in between rocks?

scrum Eric (software) Software development agile

Published at DZone with permission of Joshua Partogi, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • 3 Main Pillars in ReactJS
  • Introduction to Spring Cloud Kubernetes
  • Shift-Left: A Developer's Pipe(line) Dream?
  • 5 Steps for Getting Started in Deep Learning

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: