Process Change

A Positive Way to Think About Bugs

Bugs are the things of nightmares. There are the ones that appear unannounced in production systems, at a critical time, and are spotted by the most vocal hater of your company. There are the intermittent ones that you spend hours trying to track down, and the small, irritating ones that you know will never be prioritised. There are the ones you’ve never seen but suspect are there, lurking. Waiting.

Over the years I’ve had an additional bug nightmare. One where someone expects me to spend a significant amount of my time capturing bug report metrics. They want to know how long bugs take to fix, how long we took to find the bug, or how good a developer is based on the number of bug reports we have.

When you take all this negative bug energy and throw in Jira. Or Mantis. Or BugZilla… it’s easy to understand why we all hate bugs.

But there is a positive side to bugs.

It’s too common to hear of bugs surprising teams and nothing changing. Some bugs are unexpected, and it doesn’t always make sense to try to stop a similar things happening again, but those are the exceptions. It is much more common for similar bugs to appear in different parts of the systems, these are strong indicators that things are not quite right. Observing and sharing these patterns can be a great trigger to motivate teams to change.

Every wondered how you can convince people to give you time to work on tech debt, or process improvement, or make progress on that cool infrastructure project? Well bugs can be very persuasive…

When a release showstopper bug, or production issue is found use it to its full potential. Understand the root cause, try to establish exactly why the bug appeared when it did. Was the issue poor communication, lacking test environments, or something else? Don’t make this a blame game about individuals but use it to find pieces of your process or technology that could be improved. In my experience bugs are almost never a result of poor code, they are much more likely to indicate code complexity, lack of context, poor test data, or simple lack of experience.

Once you have your information tell your story. Keep telling it. You’re not trying to force people to change things, you want to simply highlight the issues that are occurring as a result of things being the way they are. Once you find your interested audience work with them to make improvements.

Step by step you’ll find things improve.

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 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.


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?