[Reading time 10-15 minutes]
As we approach our first eighteen months of using the Agile Scrum methodology at Ennov PV, it seems a good time to reflect on our journey so far.
It’s pretty obvious that implementing any new process is going to be a challenging task, but the beauty of Scrum is that it is a very simple methodology: there are only a few rules and conventions to follow (see http://www.scrumguides.org/scrum-guide.html) and the actual execution is designed to be very flexible and adaptive. By definition, as an ‘agile’ approach, you can anticipate that your implementation will evolve and improve dynamically over time.
The ultimate goal of the Scrum framework is to support the delivery of a tested (and potentially releasable) software increment at the end of a defined, repeating time period called a Sprint. I’m not going to provide an in-depth description of Scrum theory, but I will focus on the key roles, artefacts, and events we are using in our setup today at Ennov PV.
We actually have two Scrum teams as we recently split our growing group. Each team has a core development staff (five and three respectively), whilst the testing resources (five) are currently shared. Strictly speaking, Scrum doesn’t support this distinction of developer and tester – it expects teams to be cross-functional and therefore largely self-contained, with all members called Scrum developers (even if they having coding or testing specialisms). We have one nominated Product Owner, the role which I perform, although I do have some significant assistance with other products in the range from designated Product Mangers. We have a nominated Scrum Master for each team – this role is intended to act as something of a mentor within the process, to guide in best-practice and help with the elimination of impediments from outside the team.
Scrum uses one primary artefact – the Product Backlog. This serves as the master list of all things we would like to do with a given product. Each product has a separate backlog. It is mostly made up of development activities (both bugs and new feature requests), but can include documentation and other ancillary tasks. There are several notable features of this backlog:
- Items are sorted in descending value order – of course, ‘value’ is determined by many different factors. In our realm, that could be regulatory impact, extent or seriousness of a software bug, or number of users impacted by a new feature
- It is owned exclusively by the Product Owner – I am solely responsible for accepting items onto the Product Backlog and defining their priority. Naturally, I will seek to obtain input from as many different stakeholders as possible, reflecting a wide variety of external customers and internal requirements
- The Product Backlog is transparent – this means that all members of the team, and in fact company, can see the contents. This further facilitates external input via myself, but ensures the Scrum team have a clear vision for each product
- Items are represented as ‘stories’ – each story details the intended change, who the change affects, and the perceived benefit. Critically each story is then characterized by a number of acceptance criteria that would need to be met in order to consider it met or ‘done’
A secondary artefact is the Sprint Backlog, this defines the stories to be completed in a given Sprint. It is the process by which items are selected from the Product Backlog into the Sprint Backlog and then developed in a short controlled timeframe that makes Scrum an effective mechanism.
Our Sprint cycle lasts two weeks and consists of a number of fixed ‘ceremonies’ or events:
- Retrospective – this takes place at the beginning of the Sprint and, as the name suggests, actually looks back at the previous Sprint. The objective is to determine what improvements we can make to the process going forward
- Pre-selection meeting – this also takes place in the first week of the Sprint and the purpose is to start planning what we will look at in the subsequent Sprint. The idea of doing this ahead of time is that the team have the opportunity (whilst working on the stories in the current Sprint) to research the next Sprint’s work and refine the stories. This activity has helped with improving the accuracy of our estimates and ensuring more transparency for the whole team
- Selection meeting – this takes place at the end of the Sprint cycle and gives us an opportunity to evaluate any stories that didn’t get completed (so that we can roll them into the next Sprint, or return them to the Product Backlog). It also allows us as a team to commit to the scope of the next Sprint and to make sure we are being ambitious but not unrealistic
- Daily stand-up – perhaps the most important activity, this takes place daily and gives the team an opportunity to discuss the current status and identify any impediments to completing the objectives of the Sprint.
Further to these events we also arrange routine product reviews to showcase the development to the rest of the company and solicit ideas and feedback from everyone. I’d like to increase the regularity of these demonstrations, as of course they are very valuable in terms of knowledge sharing and defining development strategy. There’s no doubt that including additional routine customer demonstrations would also be worthwhile too.
From my position of Product Owner, what have we gained from adopting Scrum?
In order to answer this question it is important to understand how it differs from our previous development approach – I think there are three main distinctions:
- Development prioritisation – whilst we worked to an issue backlog previously, also prioritised to reflect regulatory and customer needs, the feed of tasks into the development teams was fundamentally top-down. With the new transparent Product Backlog, accessible to the entire company, it is much easier for everyone to have oversight of the product direction. As a result, everyone can provide their input into the design of new features and help spot potential dependencies in the development. Individuals outside of the development team can add their specific customer experience to help identify conflicts in design and the current usage of existing functionality
- Developer and tester integration – previously a developer would deliver against a specification, prior to handing over to the test team. By working together throughout the Sprint the testers can now provide much earlier feedback as a story is prepared. The acceptance criteria evolve collaboratively and, as a result, promote greater reflection by the whole team on potential impacts away from the main development focus. Stories on the Sprint Backlog are only considered done when they have been satisfactorily tested against the comprehensive acceptance criteria. I am convinced that the use of these acceptance criteria is already proving very influential in improving the efficiency and accuracy of our development
- Development agility – under our previous practices, we had a tendency to gravitate towards larger releases with a broad scope of change. Experience has taught us that many customers are reluctant to tackle the deployment of these larger releases because of the burden of validation. Unfortunately the limited appetite to apply updates has had a self-fulfilling effect on the size of subsequent releases, as issue backlogs are allowed to grow. With the new approach we can be more dynamic in our preparation of new releases – a single Sprint, by definition, can generate a potentially releasable version of the software. As a result, we can aspire to a situation where smaller, more regular software releases can be made available. Our customers can deploy these updates more rapidly, or at least collate a number together and then deploy, with controlled, lean validation strategies.
In order to further bolster this approach, we are working hard on new measures to eliminate regression from one update to the next. We are rapidly building a library of automated test scripts that can be executed against every build to confirm the expected behaviour of existing functionality. The auto-testing, together with rigorous manual testing throughout the Sprint process, will assist us in attaining a combined goal of improved quality and efficiency.
I said at the start of this post, that any change of methodology is likely to prove challenging, so what have been the main hurdles we have encountered?
Well, thanks to our receptive and willing team, the adoption of Scrum has been itself relatively painless. Our main difficulties have been in the detailed mechanics of the process:
- Estimation – in order to schedule progress into a narrow two week development Sprint it is necessary to accurately estimate the time it will take to develop, review, and test each story. This is notoriously difficult to do, and really it only gets easier with experience. That doesn’t mean we don’t occasionally have aberrations – where a single story takes far longer than expected! We are working on strategies to avoid this, or at least to mitigate the impact, such as breaking bigger tasks into separate stories or having dedicated research stories (called spikes) to evaluate requirements more rigorously prior to estimation
- Delivery to test – with every sprint there is necessarily a lead time before any stories can be passed from developer to tester. It is an ongoing challenge to ensure that we have a consistent feed of items to test during the Sprint, and that we don’t backload all of the testing into the last few days. To address this, every day in the team stand-up we attempt to identify what can be pushed through for testing (and also try to make sure some shorter development tasks are tackled at the beginning of the week)
- Team objectives – Scrum is a team practice and it certainly takes time to ensure that the Sprint Backlog is viewed as a team objective, especially when in most circumstances any given story will only require the sequential action of one individual developer, one code reviewer, and one tester to complete. Evaluating the overall team objective every day in the stand-up and planning the best team-wide approach to meeting the Sprint goal is critical to changing this mind-set.
So where do we go from here?
With new individuals integrating into our teams (we have recruited an additional three developers and one automated testing specialist in the past four months) and the recent split into two teams, we now have to ensure we can adopt a consistent approach and continue to manage the process effectively.
We are currently implementing a new tool, called Redmine, to manage our Product Backlogs and assist in the Sprint management. The new tool is lighter than our existing solution, but still gives us full traceability over the development life-cycle as required by our Quality Management System (QMS) and development procedures. We hope to evolve the use of Redmine and our Scrum process to delivery even more efficiency.
Scrum is undoubtedly versatile, and as a result I think it is an approach we can consider for other areas of our business. I can anticipate running some customer projects under Scrum, and even using the framework for managing more of our internal workloads.
I hope reading about our experiences with Scrum has given you an insight into how our development processes have evolved over the last eighteen months. Perhaps you will be able to consider learning more, and incorporating some aspects of Scrum into your project management processes?
Thanks for your interest!
Nic