Introducing Change In Organisation

Did you ever feel like being stuck in a hamster wheel? Doing the same work over and over again without any engagement? The job that you were happy to have and brought you joy, became… just a job that you had to do.

Burnout is a state where I would not wish anyone to be. For me, the worst period of it was 2 years ago, when I joined a project (still being in the old one) as a test lead, where the development process started 5 months prior. There where are a lot of issues with it:

1. CDD (“Conference Driven Development”) – implementing new features before or on the conference day, and after it.

2. Unit/Integration checks – we had a few and the ones we had brought neither value nor information.

3. Ticket/task handover – It was vaguely described and there were a lot of shallow agreements while working on the handover.

4. Business and domain knowledge – was not shared evenly among team members.

5. Requirements hadn’t been explored – lack of time meant, that we lack some domain and business knowledge.

6. Our team depended on another team – communication between them was close to none.

7. Crunch periods – to deliver what was promised, overtime was over hours where required.

8. Dissatisfaction within the team – due to issues above.

9. And many more bottlenecks, that we don’t have time to deal with right now

After a couple of months of me working there, the project was definitely not a good place to be in. I ended up waking up at 5 am on one Saturday just to create a presentation that would include all the things that were wrong with the project. This process let me vent out some frustrations and have an outline of all the project issues. I could just pat myself on the back and let it go, but I had further plans.

After being done with the presentation, I thought about possible solutions that we could implement in the short and long term. With that in my hand, I could start a conversation about the change with my manager.

Catalyst

Every transformation needs an event that will push someone to alter their behavior. These events can be categorized into 2 types:

• The first one, where you are self-driven to bring the change upfront. 
• The second type is driven by external factors. Someone/something pushes you to adjust. That can be people base (demands from your boss, stakeholder, your work peers) or situation based (the technology used in the product is outdated, we lack funding or the world is about to end).

In this article, I want to focus on the first type. About the alterations coming from you, especially in the project context.

Why people want to make changes in the project. In my case, it was the burnout due to the work overload. Plus the tester inside me wanted to bring high business value to the customers and in my opinion, at that moment we did not deliver that. For you the trigger can be something like:

• Lack of information (e.g. you need to learn more about domain knowledge).
• Being dissatisfied with the status quo (e.g. the current testing process is more of a bottleneck than value).
• Yearning for stability in the project (e.g. we want to reduce the number of new things coming after sprint planning).
• The knowledge that things can be done better (e.g. if we formalize our development process, we won’t have a shallow agreement over the handover).

Plan

When you have your catalyst for change, the second thing you need is the proper communication of your change requests. But to do that properly, in my opinion, we need to step back to the article title and break it into pieces.

“How can I introduce a change in the project?”

In this question, we have three key things to consider that will let you see things from different angles and help you achieve what you want.

These things are I, change, and project.

I, the change maker

You need to think about your reputation within the project and how it can increase or decrease the success during the meeting with others regarding the shift. For that I would consider these factors:

• Role – what are you doing and what are your responsibilities in the project? It’s easier to introduce the change when you have some kind of management or leadership role.
• Expertise knowledge – having a business, domain, or technical knowledge will most likely allow you to push further.
• Relationship – When you have a more positive relationship with other people, they are keener to support you with your ideas.

Change – the type of change and the way it will be introduced

The next to consider is our main topic itself. Think about its shape and form, the more you spend time with it, the easier it would be to explain the necessities of it to others.

The (or some) factors to consider:

• Scope – how large is it and can it be divided into smaller parts?
• Speed – how fast do you need to make it happen?
• Steps – what are the milestones for your change to happen?
• Essentials – what do we need before it can happen (tools, people)?
• Owner – who will be accountable and push it forward?
• Visibility – how can we display its results?

Project – everything is done within the project

Everything is happening in the project space. Things to think about:

• People – who will be affected by it (development team, users, stakeholders)? 
• Affected – how will it affect others?
• Type – in what state project is in (in development, in production), what methodologies do we use? 
• Cost – how much will it cost (effort, time, money)?
• External – what are the outer factors for your project? 
• Mood – how will the overall emotions shift?

Having considered these things (and many others depending on your project context) we can start introducing the implementation plan. A clear vision and many other factors will help with the next step.

Evaluation and Inception

We have our plan and vision. Nothing else is left other than crash test it.

In my opinion, you have two options to evaluate your change plan and move it through the project pipeline:

• Use agents of change – start planting a seed of a change ideas between your teammates and try to push it further up (Your peers can evaluate your initial idea and even bring more to the table).
• Present it to your higher-ups – show to your higher-ups the problem (they will be affected by them in the end) and balance them with your ideas (which can have a positive outcome for the project and the team itself).

What I deem the most successful way (and a little bit cliche one) is presenting your problems/ideas and the change proposals to your peers first. This way you can pretest your work and evaluate it. Then an improved plan can go to your higher-ups.

What is left is to set-up a meeting.

Management – patient zero

This step is a crucial one and you need to be prepared for it.

• Set a goal of the meeting – give context to the meeting.
• Prepare an agenda for the meeting – it will be easier for you to move from point to point and keep track of what you are doing. 
• Have the facts and numbers ready – this will let the manager make proper decisions.
• Think about what matters should be prioritized – your improvement plan will be additional work for the project itself, depending on the project roadmap, not everything can be done as fast as you want. 
• Have a can-do attitude.

Regarding the attitude, I would like to use my favorite lesson from the book “Lessons learned in software testing”.

Lesson 101: “When you decide to fight, decide to win!”. What I like about it is that it can be used not only in software testing but in other areas too. The main premise of it is:

“The principle that we urge you to adopt is that every appeal you make must be persuasive. Even if you don’t win every appeal (you won’t, of course), you should develop a reputation that every appeal of yours deserves to win.”

Getting back to the main point. The purpose of the meeting with management is to show your proposal for the change, if you don’t believe in your prior work that you did, then you just waste your and everybody’s time.

From now on you may expect two outcomes.

Failure

“Shit happens”.

That does not mean that your ideas are wrong, there can be other reasons behind it:

• You can not have a full picture

              – Stakeholders or management plans for the project.

              – Other things can be more important (and bring more value) than your improvements.

• Humankind rejects changes – we love to have our conformity.
• It requires time – stuff that you presented can seed other concerns in your management mind, which can make alterations in the future.
• Sometimes the effort for advancement with the plan can cost more than you have imagined.

Bringing change is not an easy path to follow and don’t beat yourself down about it. Learn from your experience and try again in the future.

Success

Congratulations, you have introduced it. What is left is an equally hard part of cultivating the changing culture in your team.

Find the person accountable for the process (like we had in the planning phase). The owner of the change process needs to take care of the initial push back (Humankind rejects change) and align the direction of the process with the team. Without that person, everything you did so far will go in vain.

Other key rules that I would suggest to follow for the process owner:

• Set up a deadline for the process
• Formalize the process. It will be easier for the team to stick to it.
• Have checkpoint meetings to evaluate the progress and decide what to do next.
• When you have a lot of improvements, introduce them in batches (don’t overburden the team with them).
• Keep communication clear between team members. Listen to their feedback and…
• Don’t be afraid to make decisions.

The End Game

Event > plan scope > inception > escalation > fail (learn, try again) / succeed (owner, deadline, iterate)

The final question is, how did this whole process go for me?

Like I wrote before, I finished my presentation on Saturday. What was left for me was to have a meeting with my manager on Monday.

The meeting itself… Went well. I had built a rapport with the manager regarding the project, its issues, and what path we should go. As a team, we introduced some short and long-term repair mechanisms and other issues (which could not be solved by the team itself) were escalated further to C-level executives.

So was it a success? It depends…

The project itself finished 2 months later, due to a misconception of what the client wanted at the end (minimal viable product for conferences that would be also production-ready). That way I moved to my previous project again.

On the plus side, I learned a lot during that short time (from problem-solving to soft skills), and to this day on other projects, I use the knowledge that I acquired during that time. The above change model itself also helped me a lot with other projects.

As a company, I think we gain a lot of expertise regarding these kinds of projects and how to deal with them in the future, but this could be another story for another day…

Annotations:

• Cem Kaner, James Bach, Bret Pettichord (2002): Lessons Learned in Software Testing: A ContextDriven Approach
• Rob Lambert (02.2020): Develop your Superpower at work with effective communication skills