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.

Why I’m passionate about agile development

Agile continues to be a sought after development approach, team after team attempts to go agile and ask any job hunting tester what they’re looking for and more often than not you’ll hear agile being listed. Personally I love agile, done well you’ll end up working in a fast paced environment with a fantastic team but I am concerned how many people just wander into it blindly just because it’s the hip thing to do rather than because they, or their teams, are suited to it,

Agile is a full team approach, the best teams have managed to eliminate silos with everyone doing whatever is needed to get the job done. But that doesn’t mean we’re cowboys, instead you’ll find that just like every other team the people using agile have a wide range of skills and experiences, but unlike traditional approaches they are probably more likely to have diverse skills and will almost certainly be more ready to do what it takes to learn the skills they need to get things done.

In the past I have worked on a number of V-model testing projects and each time I would spend weeks, maybe months, writing detailed test strategies and test plans from hundred-paged requirement specs and each time I would be dying to get into the actual testing. Then the testing phase would begin and after completing the first 2-3 rounds of testing and doing the same mindless testing over and over for weeks at a time I would be dying to get back to test planning. For me agile works well, everything is on a short cycle, test planning is usually a few hours, maybe a day or two max, testing phases always involve exploratory testing and the emphasis on automation eliminates almost all the mindless, repetitive testing.

Unlike traditional approaches I can actually get involved early, agile has a great emphasis on the entire team working together to spec out user stories this is a perfect way to get developers thinking about testing before they even start coding. Add in Test Driven Development and you’ve suddenly got whole development teams caring about how testable a feature is.

Obviously like all software development projects things can go wrong, time pressures remain and there will always be times when things just do not go to plan. But if you enjoy arriving at work and not knowing quite how your day will look, being involved in projects right from the start and are good at dreaming up new and creative solutions to problems then agile might be the place for you.

Embrace reviews

During my testing career I have attended a number of training courses and sat through more than my fair share of interviews; it is impressive how many times I have been struck that somehow ‘Waterfall’ has become a dirty word. Attend an ISTQB training course and tell the class you follow a ‘Waterfall’ approach and you’ll be surrounded by faces of sympathy. Worse, tell someone you work with that your team is following a waterfall approach and they’ll hit back with the classic ‘this is V-Model not Waterfall’ response. I have worked on many so-called ‘V-Model’ projects and each time we seem to drop all the evaluate and re-work stages that make V-Model so much more reliable than Waterfall.

So why, if we are really following a Waterfall approach can’t we say so? Maybe deep down we all know that our first attempt at doing something is never going to be the best way. Many projects are successful but I think if we were really honest then everybody would be able to identify something, or a certain time when things started to go wrong. Panic, long hours and compromise are all accepted parts of software projects but maybe it shouldn’t be that way. An essential part of an Agile approach is regular retrospectives, focusing as a team on what went badly and even more importantly, what went right will give you far more benefit than daily stand-ups and writing on story cards. Iteratively developing software whilst continually reviewing and improving is what makes agile such a powerful approach.

Time pressures, laziness and a million other things can get in the way of reflection and performing retrospective actions but take the time to schedule in half an hour a week to review your own work, attitude or approach and you will quickly identify positive patterns which can easily be repeated. You don’t need to change the whole project to change yourself so start small and reap the benefits of review.