Process Change

Linda Rising – Organisational Change

I don’t need to convince people. They should just see how good this idea is” – Linda Rising

I’m sure anyone who has ever worked in a team has experienced this thought pattern at some point in their life.

Linda Rising’s fantastic keynote, “Myths And Patterns Of Organizational Change” at this year’s Pipeline Conference has some brilliant ideas for dealing with change. If you haven’t already seen it, I highly recommend making the time to do so.

Linda Rising – Myths And Patterns Of Organizational Change – PIPELINE Conference 2015 from Software Engineering Practice on Vimeo.

What works for me might not work for you. Reverse. Repeat.

Earlier this week I posted my thoughts about DevOps and Continuous Delivery. TheSunshine tester responded on Twitter with a strong defense for Agile

I love that methodologies are able to create such passionate responses. Even amongst the truly committed I doubt I would find any passion for the Waterfall method. Yet the Agile, DevOps, and CD communities seem genuinely excited about working together in this way.

Software Development has greatly improved in the last few years but I still think we have a long way to go before it is considered reliable. Last year CIO.com reported that the majority of ERP projects are over time and over budget. If Agile is truly the silver bullet then all teams would be adopting it, and finding success with it. Unfortunately that doesn’t appear to be the case.

No matter how successful Agile, or any practice might prove to be we should still be seeking new and better ways of working. Humans are unique and our involement makes every project equally unique. The team who has success with agile is unlikely to have the same team make-up, or collective experience as one who doesn’t transition, or who fails to succeed with agile. Our interpretation of what a process involves, and our previous experiences all serve to influence what the end process will actually look like.

We need to have discussions about DevOps because it has arisen from an apparent divide between developers and Ops people. Whether this divide is caused by agile, or a failing of the implementation is irrelevant, the fact is that many teams are finding things as they stand are not good enough.

At Songkick we’ve followed Lean practices for many years. We have small cross-functional teams, daily stand-up meetings and weekly retrospectives. We measure things and try to remain flexible and responsive. Despite this we were having trouble releasing working software. Implementing Continuous Deployment was an enhancement to our agile practices. It went beyond giving us a framework for working together and gave us the steps we needed to make frequent releases too.

One of the criticisms I often hear is ‘it wouldn’t work here’. Hopefully these reservations come from understanding that there are no best practices, but whatever your reason for resisting copy-book change you are right.

What has worked for me, in my team, on my project will never work in exactly this way with your team.

Simply put, best practices do not exist.

Continuous Delivery is the current trendy approach and that is a concern. You should be trying to fix a problem not copy a textbook. If you cannot identify the benefit of any practice, agile ones included, then you shouldn’t be using it. One of the most valuable skills we learned from adopting Continuous Delivery was the ability to review our process and identify exactly what was working and what wasn’t. We continue to review things, making changes as our needs, or the team, changes.

Talk to other teams, listen to their experiences, read widely but use their processes as your guide. The most useful thing you can learn from other teams is how they implemented change. What were the triggers or warning signs? How did they know it was working? How did they choose this change?

These are things that you can apply to your own situation. These are the things that are likely to actually help you deliver good software.

Instigating change

In my last post I defined different approaches that people adopt for dealing with bad practices. Consider a bad practice to be anything which is damaging to a project or your sanity. This could be something that has an obvious negative impact such as excluding testers from early feature conversations, or maybe a more personal issue such as feeling you are unable to test effectively because you have too many interruptions during the working day.

Many people just accept that company culture is set in stone, either taking for granted that things are good, or suffering through the bad times. Maybe you spend your evenings and weekends complaining to your loved ones or suffer from the Sunday night ‘back to work dread’. I’m a huge believer in individuals recognising and driving improvements to process and projects. No matter what your level within the company be pro-active in identifying changes and do whatever you can to make things better.

How you go about actually making changes is somewhat down to your personal preference. At the highest level you need to know what the problem is, have some ideas on how it could be solved or improved, and then take steps to gain buy-in from the team.

I’m trying to convince my boyfriend that we need a dishwasher. In truth I’ve been trying to convince him for about 18 months now. We both commute so washing up is ignored until we run out of something, usually the tea spoons go first. With a mountain of dishes to get through we end up spending a whole evening cleaning up. We both agree that the problem is washing up takes up too much of our free time.

Initially when I proposed a dishwasher as a solution he was a total no-no. We would lose a cupboard in the kitchen, we would need more plumbing, environmentally it was a terrible idea, and have you seen what they do to the glasses?! I left it and then gradually drip-fed him reasons why this would be a great idea. I told him about the new dishwashers that actually use less water than washing up by hand, I emphasised how much free cupboard space we have these days, I sighed over another evening spent washing up. Basically, without him even realising it he was hearing the benefits of making the change on a regular basis. Finally the glasses, I can’t disagree with him that dishwashers really do scratch glasses so I offered a compromise, even if we wash glasses by hand it will be better than having to do everything. We have reached agreement that a dishwasher is the solution to the problem. Now we just need to work out the practical aspects of achieving the goal.

Workplace problems can be resolved with a similar approach.

Identify the problem:

Make sure you are focusing on the problem and not the solution. Your problem will never be that you aren’t following Continuous Delivery or that you don’t get invited to a particular meeting. You might find that you can identify several quite different problems. In this case choose the most problematic, or the most visibly problematic to solve first. Try to understand the reasons why the problem exists, was the situation introduced intentionally and if so, why?

Find potential solutions:

Spend some time researching how you could solve this problem. Try to identify as many possible solutions as you possibly can, you might be surprised at how a seeming crazy idea can turn out to be a brilliant solution to the problem. Aim to come away with one or two potential solutions that you can use to gain buy-in from the team. Be careful not to have a fully defined solution that could make people feel like you’re trying to dictate change.

Blog posts, videos of conference talks, meetups etc can all offer ideas for solving problems even if they don’t immediately seem to have much in common. Take care not to fixate on a particular approach just because it seems trendy right now.

Set an end goal that the whole team agrees with:

To be successful you need at least the majority of the team to buy-in to your solution. How you go about this will depend on your team as well as on your personal preference. You may prefer to present to the whole team at a regular team meeting, or you might prefer to meet with people on a one-to-one basis to recruit foes to your cause. I find it helpful to sound out my ideas on several honest, and smart people within the team before presenting to everyone. Hopefully they’ll point out any obvious flaws and help you to build a stronger case. Try to address the whole team as soon as you feel confident about your solution.

There will always be resistance but there will probably also be valid concerns about making a change, or towards your proposed solution. Engage these people in conversation and make sure you understand their reasons for resisting. Work with them to help them overcome the fear of change, particularity if the proposed change will affect the way they work.

Don’t worry about how ambitious your proposed solution may seem. If everyone has a clear idea of where you want to end up then tiny steps will lead you to the goal. Keeping moving forwards and one day you will arrive at your destination.

Persevere.

Change is difficult. Do it anyway.

The conditions you face day-to-day are one of the key components to your workplace happiness. Most people have some opportunity to improve the way they work so look critically, dream big, and be courageous in driving change.

Book Recommendations

On Friday I asked the Twitterverse to recommend books about process change. I was hoping to find 2-3 good titles which I could give away during my Agile Cambridge Tutorial. As always the great mix of people on Twitter didn’t disappoint. Here is the full list of recommendations:

Fish, and Fish! Sticks were recommended by Erik Brickarp

Understanding Organisations was recommended by Graham Bleach

Quality Software Management: Vol 4: Anticipating Change was recommended by Michael Bolton

Peopleware: Productive Projects and Teams was recommended by Helena Jeret-Mäe

Bob Marshall linked to his fascinating blog post on Homogeneous Mindsets.

Have you read any of the recommended books? Would you recommend any others?