Over the past couple of months I have been delivering iSQI’s Certified Agile Essentials course, during which time I have been interested to see other people’s perspectives on Agile, and what it means to them.
Immediately reinforced was the fact that there are many misconceptions about what constitutes ‘Agile’. How many times have you encountered an organisation claiming to be Agile but, in reality, they have only implemented a select few elements of Agile processes? Most commonly, a company will cherry-pick activities like using task boards and daily stand ups without building a team which adheres to the Agile Manifesto and principles, thus diluting the true benefits of a fully Agile approach.
Similarly, the misconception that no documentation or planning is necessary was alarmingly common among those inexperienced with Agile, choosing this methodology on the basis that their project can be delivered more quickly and easily by avoiding these steps.
"Agile has many benefits but it is not an excuse for skipping documentation or planning."
Documentation as Needed
Documentation is just as important for Agile projects as it is for more traditional implementations, although Agile documentation is often more focused and condensed. The level of documentation needs to be contextually appropriate – that is, it must fit the particular project you are working on as well as the level of maturity of the team.
Moving to less documentation can be a difficult progression for an inexperienced Agile team to make. Often more traditional methods rely on many sets of requirements documentation containing numerous pages, detailing every nuance of a new system before development can be considered ready to begin. For teams used to working in this manner, moving to user stories can be a real challenge.
In Agile, some information will always need to be captured in writing. This should be conducted utilising various techniques that allow for reduced documentation while still giving customers what they want.
Agile’s principle of ‘working software over comprehensive documentation’ is certainly felt in testing, with a significant move away from detailed test cases and step by step instructions. But like all parts of Agile, this will need to be determined by the type of project, the criticality of the system, and the experience of the team. For instance, safety-critical systems are more likely to require extensive testing and documentation.
Initially, the move to session-based testing, test charters and test ideas, which aim to reduce documentation, can be just as challenging as creating exhaustive documentation for such systems, but in time can generate significant efficiencies. Session-based testing is one of the many valuable practical activities included in the Certified Agile Essentials course, delivered as as time boxed exercises to simulate the day in the life of a project.
Collaboration and Conversation in Planning
One of the biggest challenges of Agile is the focus on being a single development team, collaborating and working together.
By design, Agile creates greater team collaboration, encouraging frequent communication, sharing knowledge and building a comprehensive understanding of project status. In fact the user story template has been specifically designed in order to engender conversation.
Planning is conducted throughout the Agile project lifecycle, with a strong emphasis on adaptive planning. This includes planning at multiple levels of granularity – for example, release planning and iteration planning (in Scrum this is called sprint planning). This planning is usually visible on the Task board (Scrum board/Kanban chart), and is responsive to project contexts. Additionally, the Agile team gathers on a daily basis for a stand-up where they discuss progress with one another which may result in some re-planning at an even lower level.
Agile planning and having your team agree the priorities and complexities can be very challenging. First, business owners take full and sole responsibility for allocating priority by giving each user story a business value. It is then the task of the team to deliver the biggest business value as quickly as possible. Later, the developers and testers will identify complexities, taking these into account for the project at hand when they commit to the amount of work that can be achieved in an iteration.
At the release planning meeting, feature are grouped together, with details being refined at the iteration planning level. Achieving consensus on this can be difficult to achieve, but this process is a key part of building an Agile team. The whole team needs to be involved to ensure full commitment to the delivery.
Agile encourages collaboration with both the business and the team and this is something we should embrace. Even with non-agile projects, this adds to the success of projects and is a huge advantage. In agile, for testing, the focus is that each user story must meet its own acceptance criteria and also meet the quality standards defined in the definition of done. This means that we have a clear view of test coverage and when to stop testing.
The nature of Agile teams means that throughput or velocity improves as team members grow to know and trust each other. This can be further bolstered by conducting retrospectives whereby learnings and improvements are made continuously throughout each iteration. Again, task boards can, at first, appear challenging and time consuming to build, but these perceived roadblocks quickly work themselves out as teamwork improves.
By comparison, traditional projects only usually involve reviews at the end of the Software Development Life Cycle, when the project team are moving off to other pieces of work or projects. But at this stage it is too late to make adjustments. Not in Agile. Agile drives value by being highly adaptive, with a more immediate feedback and improvement loop happening every iteration (typically two weeks in duration).
During the course there is plenty of opportunity to put into practice the techniques that help build a truly Agile team. During the courses, there are always some interesting discussions about how to make agile successful especially considering the challenges above. It is good to be able to identify real situations, look at the reasoning behind the way organisations have taken their particular approach and then determine ways to improve the agile process so that it is tailored to their environment.
Conclusion
Agile is still a methodology – it embraces planning, modelling, documenting, and engineering but not in order to file some diagram in a dusty corporate repository. Planning still occurs, but Agile projects recognise the limits of planning in a turbulent changing environment. Documentation is needed, but not hundreds of pages, or never-maintained and rarely used documentation.
Agile is a different way of working, but fundamentally the same processes need to take place; only the value and prioritisation of these processes are handled differently. We still need to record requirements and defects, we still need to plan, but overall Agile gives us different tools to do this. Agile is not a silver bullet but it is an opportunity to deliver projects differently.