Scrummage

“Scrum is a container,” repeated the instructor of a two day Professional Scrum Master course that I attended recently, “it’s not a magic formula for success; it’s just a framework that allows skilled people to do skilled work”.A Scrum novice before attending the course, I both agree and disagree with that description. Scrum is very much an empirical process that focuses on removing impediments and creating an environment in which complex work can be achieved efficiently.But I think it’s also more than that, because the thinking and attitude that underpins it is powerful, and I was actually surprised at how much it resonated with the way I approach testing. To an extent, much of the philosophy is similar. To explore how, let’s backtrack a little bit.Having never worked in an organisation or a project running Scrum, I was slightly nervous about the course. I had a rudimentary knowledge of what Scrum was – or I thought I did – but the course was targeted at turning those with a solid practical foundation in Scrum in to Scrum Masters.It turned out that this was actually not an issue. The Scrum Master in any Scrum Team is the person responsible for coaching the team in how Scrum works, and helping them to adapt their working habits and environment to fit the framework. If Scrum is a container, the Scrum Master is the person who holds and shapes it.This meant that the course was very much focused on developing a deep understanding of what Scrum is and the ideas behind it, to better enable those present to fill this guiding role. If you’re going to help people adopt Scrum, you need to understand why Scrum can work, and the fundamental principles that lie beneath it.And it was in these fundamental, underlying principles that I found a lot of resonance with my own thinking about software development and my own testing philosophy.The three pillars of Scrum, and the empirical process on which it is based, are transparency, inspection, and adaptation. Scrum recognises that there are innumerable variables in even the simplest endeavour, so to attempt to control them all would not only be impossible, but also rather foolish.Instead, Scrum recognises this complexity and uses the three principles noted above to create a framework in which we can better respond to complexity and change. It promotes agility, and instead of trying to nail everything down, accepts an almost sceptical view of software development: we can’t know everything. So we don’t try to.This is something that I recognise in the way I test too. When we first engage a product or system, we do not – cannot, in fact – know everything about it. Even if there is a “complete” specification document, the constant variability means that the only thing we can consistently rely on is that things change and all of what we know now will not always be true.So, like Scrum, I don’t nail down everything in advance. Instead of trying to create a bunch of test cases which represent a complete inspection of a static and well understood “ideal”, I recognise that testing is mostly about learning. I’ll construct a model which represents my current understanding of how things should be, in a form that is accessible and lightweight.In testing using this model, I embody Scrum’s three pillars of transparency, inspection and adaptation. My model is deliberately transparent and visual to allow inspection both from myself – whilst testing – and from other stakeholders who are constantly encouraged to critique it. In this way, my model is constantly adapted according to the latest understanding we have.My testing is therefore accepting of the variability of the complex environment in which it must occur. In contrast, traditional factory-style testing advocates the creation of fixed, static representations of test ideas which reflect one representation of one ideal at one point in time. As soon as that fixed point of reference changes, those static test ideas – typically known as test cases - are potentially compromised.However, given that those test cases are often stored in monolithic tools or repositories and are rarely accessible to the non-testing observer, there is little transparency of this degradation in relevance and the opportunities to inspect and adapt them are minimal. In addition, any adaptation that does occur is often time and effort intensive, because the test cases are low level and rigid, instead of being lightweight and adaptive.Scrum also uses the idea of incremental Sprints to help provide regular and structured opportunities to implement these principles. The time-boxed events (often called “ceremonies” by true believers) that populate every Sprint – a Sprint Planning meeting to start, daily stand up meetings throughout, the Sprint Review and Sprint Retrospective to finish – are all designed specifically as opportunities to inspect and adapt.Even the idea of the Sprint itself (Scrum’s fifth event) - which cannot ever be more than one calendar month, and which must deliver an Increment of working software – is part of this thinking. By creating a series of iterative cycles, Scrum allows the business to conduct regular inspections of genuine finished product rather than the faux, document-based deliverables that are the stock and trade of traditional projects until the latter stages when big bangs start to go off.An exploratory approach to testing – especially one structured around Session Based Test Management – operates in a very similar way. Instead of just planning and the executing “all the testing” and then stopping and looking back, an exploratory approach is one which treats test related learning, test design, and test execution as parallel activities that occur in parallel throughout a testing project.This means that when testing in an exploratory fashion, I regularly stop and consider the genuine product of my testing – which is usually information to help the client to make quality related decisions about their product. If at that point I realise that I can produce a better genuine product – i.e. more useful information - from my work by changing what I had planned to do, then I will.When running Session Based Test Management, this regular inspection and adaptation is even more explicit. Each time you complete a time-boxed test session you have the opportunity to review your model and re-assess what the most valuable thing to do next might be. Inspection and adaptation.There are, of course, ways in which elements of Scrum can’t be applied to testing directly, most obviously as Scrum deliberately refuses to label individual roles within what it calls the Development Team; instead all members own all the work and share responsibility for getting it done (though despite the common myth, this doesn’t mean that all testers must develop code, and vice versa).What was clear to me though, was that the thinking that works for Scrum on a macro level – i.e. across the entire project or organisation delivering a software product – is also reflective of thinking which can be useful at a comparatively micro level too – i.e. as an approach to testing.So while I agree with the idea of Scrum being a container – formed by its underlying principles and thinking - that allows skilled people to do skilled work as effectively as possible, I think that it can also be more than that.To get the most out of Scrum, that container would also be filled with the principles and the thinking. In other words, if the people doing the work understand and engage with those ideas, then the way in which they approach and engage in the work itself inside that container will likely be even more effective and efficient.As an admitted novice who hasn’t actually ever had the opportunity to work in a Scrum team, I am nonetheless sure this is what happens within good, experienced Scrum Teams: they buy into the ideology that complements the approach.On the other foot too though, there is value in the principles of Scrum even if you can’t get inside such a container.For me, someone who has never worked in an organisation or project that uses Scrum, I recognise the value and power of the principles that underpin it. They resonate with how I already try to approach my work, but this course also served as a nice opportunity to look transparently at my own thinking and approach, inspect how effective it is and what could change, and set to work on adapting it.Whether you work in a Scrum Team or not, those principles of transparency, inspection and adaptation are powerful ones.Author's Note: I should mention that the Professional Scrum Master course I took was a Scrum.org approved course offered by Assurity. You can view details of the course here. While I openly admit that I work for Assurity, I can say without bias that I thought it was a terrific course for those interested in Scrum and would definitely recommend it.