Colin Dready, Principle Consultant, Capita IT Professional Services, discusses how organisations can adopt the concept of agility to achieve shorter delivery cycles.
Organisations wanting to adopt more flexible testing methodologies and achieve shorter delivery cycles face a crucial question: how far has agile drifted from the concept of agility itself? It’s the difference between agile with a capital ‘A’ and agility, where the ‘a’ is lowercase; the difference between following doctrine and proactively and positively absorbing the inevitable change that all projects experience.
Although more organisations claim to want to become agile, cost constraints and deadlines can see project teams falling back on unhelpful behaviours rather than examining ways to apply creativity to current challenges. Essentially, organisations often attempt to use agile principles to shift left, but end up bouncing right when things go wrong, with the agile methodology incorrectly blamed.
Capita sessions at the recent TEST Focus Group event facilitated discussions between senior testing and QA professionals about the practical application of agile techniques as well as user and business expectations of agile as a methodology.
Expectations of agile
Is your organisation even set up to be agile? We have worked with many businesses considering just this question. To ensure genuine agility, businesses need to embrace conversation, collaboration and working cross‑organisationally. Testers and other members of the development team should be brought into the project process earlier and concepts of agility explained and promoted throughout the relevant parts of the business. Those organising the work and running procurement departments should understand that being agile might entail earlier investment and some new overheads, while still delivering better outcomes at a lower cost overall.
The people you need
The ideal agile team needs complimentary skills from the technical and business sides of an organisation, and for those with specific skills to adapt and collaborate with others with different talents. A successful and effective agile team needs ‘T‑shaped’ people with a broad range of shallow skills and deep niche vertical skills in their chosen specialisms. ‘Linear’ people – i.e., those without the broader skillset outside their speciality – may be easier (and cheaper) to find but this often means that important aspects of agile delivery, such as test automation and test‑first approaches, are left by the wayside.
A successful agile team (not just its testers) immerses itself completely in the act of deliberate discovery, the active attempt to uncover ‘unknown unknowns’ at an early stage of each iteration and the search for features of business value to implement, while simultaneously reducing the extent of those unknowns via effective communication and collaboration.
Excluding testers from early conversations (intentionally or unintentionally) means that when the output is translated into documentation, these documents may lose the creative essence of the conversation itself, and will certainly prove harder to test, with testing falling back to a work as reactive function. And when documentation becomes defensive as suppliers, developers and those assessing business needs state their own case ‘louder’, it becomes impossible to read in a meaningful way. Smaller, more intelligible documents and communication make for more effective, more agile work. Behaviour driven development comes into its own here as conversations lead to living documentation that genuinely reflects business need. This is what it means to collaborate: don’t keep secrets, especially where those unknowns could have a material impact on delivering successful outcomes.
What do organisations need to do?
Agile projects intentionally look to refactor their outputs as the team works to create the best solution. This implies – in fact necessitates – that continuous implementation involving testing is required. This repeated examination of what’s been created doesn’t sit well with traditional testing models that focus on manual‑heavy approaches. Agile projects depend on automated testing to keep up with the pace of the work; organisations transitioning to agile need to budget the money and effort to get test automation up and running at all levels.
Agility also means being able to respond rapidly and positively to inevitable change, which can be dependent on wider agility in supporting capabilities. In our TEST Focus Group we extensively discussed the common challenge of test
environments. If you are working in iterations that last only a few weeks, then having to wait for a month or longer for someone to provide an environment clearly does not work. Many teams now look at self‑provisioning via the use of cloud services or similar, although some discipline is required here. This is a classic example of expanding the team to ensure it covers all the necessary skills and capabilities.
When thinking about agile versus agility, we also need to ask what people actually think agile means. People often consider agile methodology to be synonymous with scrum, whereas this couldn’t be further from the truth. Many different agile methods exist, unsurprisingly, each having different strengths. It’s also not the case that you must strictly adhere to the agile method you have chosen; again agility means positively responding to change. Tweaking your method to best fit your circumstances is a central cornerstone of true agility. For example, Capita has many teams deployed to various client sites, each demonstrating agility and each having implemented Kanban, DSDM, scrum, etc. in slightly different ways.
Plans and deadlines (yes, even when using agile) are the very essence of projects, and team sizes and goals will change as the project evolves. Our clients have successfully combined other approaches to agile with test‑first approaches such as test driven development and behaviour driven development. Our advice is: when considering agile, don’t stop your research after the first page of Google results.
Summary
Agile can regain its agility as long as those using the methodology embrace its inherent flexibility. Our conversations with delegates at the TEST Focus Group event reinforced our and Capita’s way of thinking: collaboration and conversations can make or break an agile programme.
Edited for web by Jordan Platt
