I’ve been working in the software testing industry for around 14 years. The vast majority of the time, the projects that I’ve been involved with have not followed any clearly proscribed methodology, but typically leaned towards the Waterfall model where requirements lead into design, design into development, development into testing, and finally into Production. This is often followed in tandem with the V-Model or better yet, the W-Model which I don’t think I can describe better than Paul Gerrard of Gerrard Consulting.
So am I qualified to comment on whether to use agile or more traditional practices? Even though I haven’t been deeply involved in agile testing, I have been involved in projects that liked to think they were following an agile methodology. In a lot (read: nearly all) of these cases, the agile process failed, and resulted in the project mired in chaos, forced to react rather than be proactive, and costing far more than it should. Am I going to blame agile methodologies for these failures?
No, for the simple reason that there is nothing wrong with agile methodologies, just as there is nothing wrong with Waterfall or V-Model. What was wrong in each of those projects was the decision making process that led the project to believe that agile would work.
In my mind, there are four key points that are absolutely essential for any agile methodology to work, and if you can’t tick all the boxes, then I wouldn’t recommend choosing agile.
Project Maturity
A lot of companies go into agile believing that it will save them time and money, because everything is done quickly, in small increments and documentation comes later. What they don’t realise is that agile requires an implicit implementation of process and structure around the System Development Lifecycle (SDLC). Everyone involved in the agile process must know and understand their role, and how everything interrelates.
Agile doesn’t mean that configuration or change management goes out the window: it just means that it is handled differently to a more traditional model. Documentation is still required, but evolves during the development cycle.
Authority
Agile methodologies demand that decisions are made on the spot whilst development is being carried out, whether it’s a modification to the technical implementation, the correction of an identified fault, or improvement in User Experience (UX) design. That means that each and every person involved in the development cycle (developer, test analyst, business analyst, business representative, DBA, etc) must be authorised to make an immediate decision, without recourse to higher levels or outside their immediate team. All too often, this is where implementations of Agile methodologies fall down, because that authority has not been delegated. Consequently, as decisions are made elsewhere, the timescales are impacted.
Experience
Experience is a natural driver of project maturity and authority: in order for authority to be delegated and the SDLC processes to be implicitly recognised, those involved must be experienced in the role that they are taking. They must be comfortable in their own knowledge to be able to make independent decisions, secure that they know the project lifecycle and are therefore not breaking the model.
Colocation
I’ve recently worked on a project where the development and test functions were offshored: in my view, agile methodologies do not lend themselves to offshoring, or rather, that it is extremely difficult to do so. With offshoring, not all of the SDLC is handed off: quite often technical leads, business analysts and the client are onshore.
This can cause problems because the time difference will lengthen the decision making process, but also interfere with the communication of ideas and requirements. If you take into account the often different cultures involved in the offshoring process, miscommunication and misunderstanding frequently arise.
Agile methodologies work best when you have face-to-face contact: the nuance of facial expression increases the understanding level significantly, but also the turnaround time is hugely reduced. Even when working in the same office, but on a different floor, I have preferred to talk to someone face-to-face to gain understanding because of this. Similarly, the throughput and quality of delivery hugely increased on a recent project when I travelled offshore to communicate with the team.
0 Comments