Coping with change on Scrum projects (Part IV)

Having worked in a waterfall environment most of my career, I am all too familiar with the "death march" which inevitably lead to shrinkage in the time left for QA to test the software. Fortunately, for testers as with developers, this story is going to change big time. How so?

#1. You will now be expected to participate right from the beginning of the every sprint. Wow, imagine such a concept. What value can a tester add this early on in a project - I'm being facetious of course. You will be part of the Sprint planning meetings so you'll get to hear right up front what user stories are planned. In fact you will be part of the process of embellishing the user stories themselves. You will for example help to define the user story acceptance test criteria. This significantly helps developers understand what they need to do up front for the tests to pass. And as a result, the quality of the code delivered is dramatically increased as well as the "accuracy" of code i.e. how closely the code matches end user requirements.

#2 You will be expected to be a part of the planning poker sessions to size (estimate) user stories. Participating in the estimating process means the company get's better overall estimates of user story complexity, which in turn means more accurate estimates, better plans, less stress and therefore in general happier teams with higher morale.

#3 You can and should be involved in the creation of unit tests. This is one significant way in which testers can enhance their skill-sets. With teams that practice XP pair programming there's a new concept called Ping Pong where the one pair writes the tests, and the other pair writes the code that makes the tests pass. This is an area where testers can add a ton of value to the process with their analytical and "how can I break things" mindset.

#4 You will be expected to automate more and more of the tests. As a result of this, you will contribute to the overall effectiveness of the team and it's productivity. Lean thinking suggests that teams need to be concerned more with cycle time and automated tests have a lot to do with improving cycle time from creation to deployment.

#5 You will be a respected member of the team rather than a second class citizen with the right to "stop the line" (Toyota Production System). i.e. Any bug that is found even early on should be resolved as soon as it is found. The Agile mindset solves the traditional project management problems by building a cohesive team and treating each of the functional areas as development. In fact Scrum only refers to developers on a project. i.e. if you're a tester, on scrum you're just another developer who has deliverables on the Sprint backlog.

#6 Because developers are writing unit tests, you will no longer be receiving extensively buggy code. So you can now rather focus on the more important aspects of testing edge and boundary conditions as well as automating your unit tests.

#7 Scrum and Lean practices expect that all code delivered at the end of the sprint is DONE. i.e. unit tested, functionally tested, integration tested. So you will have the time to get these completed each and every Sprint as all work including test is accounted for in the Sprint plan - as opposed to just having the "last 3 weeks of a project" dedicated to testing.

#8 Agile is built on the premise of sustainable throughput and in order to do this and keep the momentum of the development pipeline, it is imperative that quality is built in right from the start. Some of the most significant enhancements in this regard is Test Driven Development and Behaviour Driven Development.

Testing has certainly matured since Agile methodologies have taken hold and testers themselves are much more respected in the industry today than ever before. Testing is now essential to the development of good software as it ensures that the software does what it's meant to and performs as intended. With concepts such as TDD and BDD, the testing effort has shifted from a traditionally tail ended process to a front ended process and as a result quality is built in right from the start.

I know in my heart of hearts this is single-handedly the #1 reason for higher quality software, happier customers and happier development teams.

Written by Jack Milunksy - COO at Brightspark, certified ScrumMaster and Co-founder of Agilebuddy (Agile project management software that lets you easily Create, Estimate, Plan and Track your software development projects). For great Agile tips follow Jack at: www.twitter.com/agilebuddy. To get more info on Agilebuddy please visit: www.agilebuddy.com