Author: Rob

I’d thought I’d share a summary of the ideas discussed by the speakers at the Agile Tour London 2015. The following are a collection of the ideas discussed by Gojko Adzic and my notes on them.

Gojko Adzic – How to turn continuous delivery into a competitive advantage.

Gojko Adzic


  • “Continuous delivery – have we gone too far?”
  • “Software is everywhere, developers are powerful”
  • “Automation is fast, continuous delivery is impressive – but have we gone too far?”
  • “Only a third of features are actually useful, a third are harmful and a third make no difference.”
  • “How often do we remove badly implemented, incomplete features?”
  • “Deployment <> Release”

The dangers of continuous delivery

  • Interrupting the user’s workflow.
  • Making a user relearn how to do a task e.g. new UI/UX.
  • Reducing the impact of marketing campaigns, due to frequently release which by themselves may not excite the user base.

My thoughts….

  • “Yes, we can build software fast now, but are we building the right thing? Because it’s quick to implement, not enough time is going into the idea behind the feature itself.” So for me, this is where you hope the Product Owner has this under control, but as an additional layer of protection, an agile tester will always be mindful of the users and really trying to understand the value of the feature before it makes it out of the planning phase.
  • For me there no doubt continuous delivery done right is a good thing, for both product developers and consumers, however, we do have a greater responsibility to be conscious of how each feature impacts a user.
  • We all know how annoying it is when for example your bank, favourite shop etc redesigns a feature that you have been using for years, and suddenly you are forced to jump through hoops and re-learn a process you use to be able to do in seconds. We need to be planning this awareness into our features.

So what can we do about it?

  • Decouple Deployment from Release
    • Clearly this represents a technique challenge, but the advantages to the user are clear.
    • As a tester it would bring great comfort knowing a feature could be enabled and disabled as required, this would allow the team to gain valuable feedback from a subset of users before pushing the feature out to a wider audience.
  • Consider the user
    • Consider for each new feature how the feature will be released to the user, can they opt into it. What help are we going to offer the user, for example if  we are changing an existing feature, how do we help the user through the transition?
  • Provide multiple versions of our software allowing the user to opt into functionality when they are ready for it.
    • We are increasingly seeing this from the big players now, either to opt into a feature or a whole version of an application.
  • Only give the user access to the features they need.
    • As software developers, it is easy to assume more is better, but sometimes holding back features so that you only give the user just enough to do what they need to do, is a much safer option. This reduces the surface area of the product exposed vs volume of users, which in turn should decrease support and training issues.

Gojko’s Continuous delivery rules

Gojko suggested the following rules as a good starting point for responsible continuous delivery….

  1. Don’t confuse the users
  2. Don’t interrupt the user
  3. Don’t disrupt or prevent marketing activities

The normal reaction I get when I tell someone outside the industry that I work in software testing is, “isn’t that really boring?”. Well, it certainly would be if software testing involved what most people think it is, however, the industry has moved on and so has the role of a tester.

When most people think about software testing, things like specifications, test cases, verification, logging bugs etc. spring to mind.  Now clearly these are facets of testing, however, that isn’t where a tester really shines. Traditional approaches to software development involve compartmentalising the development process, often with separate teams working on say, requirements, development, testing, deployment, support and so on. I have worked in many of these roles during my career, however, one thing stood out, it rarely went smoothly!

So what was the problem? When you break the development process up, you start introducing communication barriers, for example, the stakeholder with the requirement and the team building the solution may never come into contact with each other, and communication is only through documentation. This can quickly lead to slow feedback cycles, miscommunication, poor assumptions and misinterpretations. Additionally, this approach can often foster a blame culture, where as long as a given team has covered themselves, what happens further down the chain isn’t seen as there problem.

So how do we make sure we are “building the right product, and then building it right…” – Essentially to me, this is what a good software tester does.

Over the last decade or so, many software development companies have moved towards agile development methodologies, at the foundation of any agile technique is what is known as the three pillars “transparency, inspection and adaptation”. Typically any agile development technique aims to achieve a cross-functional, self-organising team, capable of delivering a given set of features within a given cycle of time. Now there are lots of approaches to achieving this, and this isn’t the place to discuss them. However let’s take Scrum as it a popular approach and one I have worked with.

So essentially the idea of scrum is, it is a set of meetings (ceremonies) and roles (product owner, scrum master and development team) which help foster better communication and reduce feedback latency. Now scrum itself is not a silver bullet – it is purely a framework to ensure stakeholders and the development team are communicating, and that the team is constantly learning how to deliver features better by achieving transparency, inspecting frequently, and adapting based on the information learnt. It is important to understand in the context of Scrum the development team is essentially everyone involved in delivering an iteration e.g. it is not just coders, it could be UI/UX experts, testings, graphic designers etc.

So how does a tester fit into this? Well firstly in an agile world testing is now longer a phase, it is a continuous process. Testers are no longer just verifying functionality against a specification, they are involved right from the beginning of the process, for example helping to define acceptance criteria and really understanding the business value behind a feature way before any code has been written. But why does a tester need to know this, I hear you ask? For me, it comes back to “building the right product, and then building it right…”  – the true value of a tester is not just verifying a feature has been built right, but does the feature actually deliver the business value the stakeholders wants? In order to do this, the tester really has to understand the value of the feature and the users who will be using it.

A testers role really involves understanding the users, being able to assume their persona and exploring a feature in the context of a solution, yes a tester will still be involved in verifying functionality, however wherever possible this is automated. The true value of a tester is the human element which no automation tool can replicate. A key technique a tester will use to achieve this is what is known as exploratory testing, which is a self-perpetuating learning based approach to explore a solution. Essentially you are observing and inspecting as you go along with your direction steered by the analysis of your findings. So I appreciate to some, this might sound like chaos, however there are a number of techniques which testers use to help focus their testing, for example, time boxing exploration, using charters (explore X with Y to discover Z) or touring guides (using metaphors to chaining features in the context of a role or persona).

What I really enjoy about agile development is, it is a collaborative process. No one person can be an expert across the entire solution, however through collaboration and context-based learning, complex problems can be tackled. A tester’s role involves working across the delivery process, with the walls between stakeholders, development, operations, support and testers being broken down. Agile development has evolved from just Dev + Test working together too much more, for example, you will often hear about DevOps now which is next natural evolution of agile development and is essentially Dev + Test + Operations, but really it doesn’t stop there – the idea is we are trying to bake quality into the whole process through working cohesively, collaboratively and continually inspecting and adapting to find a process that works even better than before, whilst developing valuable quality, features as quickly as possible.

Hopefully, this has given you an insight into what I do, and maybe even persuaded you that there is more to a tester than executing test cases : )

I always enjoying hearing from fellow testers, or if you have got questions or feedback, please get in touch.

I thought I’d share my experience of the Scrum Alliance certified ScrumMaster course. I took the course in March 2015 through a company called Agil8, Dave Hicks was the instructor. I have no connections to this company and have never used them before.

I finally decided to bite the bullet and take the course, at this point in time I had already been practicing scrum for some years and had instigated much of the process and tools our team used to adopt scrum into our business. I had naturally assumed the role of ScrumMaster but lacked confidence, as I had no formal training or certification – so I signed up…

The course was a 2-day onsite interactive course, followed by an optional electronically submitted exam which you have a maximum of 60 days to take. The exam can be taken from the comfort of your own home and is not part of the 2-day course. Your must attend both days of the course and successfully complete the exam to become a certified ScrumMaster.


The syllabus is, as you would expect, it covers the core concepts of Scrum and assumes no significant prior knowledge. It then moves into the specific roles in more detail, followed by a breakdown of the ceremonies and associated artifacts. I won’t go into detail on the syllabus, as I’m sure it changes and you can just look it up, however, I thought in this article I’d highlight what I took away from it.

Each topic on the course was discussed by the group and the instructor also provided insight into his extensive experience as well. On the second day, the group was being broken up into scrum teams, the teams effectively went through the motions of a sprint cycle with the creation of a backlog, all the way through to delivery of our increment, which happened to be a Lego house!

Scrum cycle

There were about 30 people on the course and by far the most valuable part of the course for me, was hearing about other people’s experiences in adopting scrum and the problems and solutions they had experienced. Some of the things that stood out for me were:

  • Gaining a balanced view of where agile methods thrive, as well as the real world challenges people face in the industry whilst trying to adopt it – there was a great mix of people ranging from the staff of multinational banks to lean startups, some already hardened ScrumMasters others just starting the journey.
  • I was the only person with a QA background on the course, I would say 70% of the people there were from project management backgrounds, and rest were mainly Dev leads. It was great to hear about their perspectives on agile. In my previous roles things like ROI didn’t really come up, but to many people on the course, this was one of their key concerns with adopting agile.
  • It was comforting for me, for everyone to acknowledge agility is a journey, and you have to start somewhere, and you will never reach an end point – and that’s OK!
  • For me having the ability to challenge theory was great too, for example: In theory, the team defines the definition of “Done”. To me with my QA background and personal experience, this didn’t make sense, as effectively the team is deciding the generic effort an increment takes to deliver e.g. As a team member I might say I want every release to have X, Y, Z testing performed – but the reality in a commercial context is, that may not be acceptable to the business. So to me, there is always going to be restrictions placed on the team probably by the product owner or the wider business.

So to summarise, I really enjoyed the course and felt I took away a lot from it. Agil8 and Dave Hicks were great, I would certainly use them again.

The exam method although very convenient, isn’t perfect, as effectively it is open book and multiple choice. So it is not very challenging and somewhat devalues the certification, as really it should be pretty hard to fail. Also, I don’t agree with some of the official answers on the exam and found myself having to answer questions in a way I disagreed with just to get the mark which was frustrating.

Having said that, I would recommend the course, and I think most people will get good value from it.