Delivering testing and software projects with Agile methods
I started my career in software development with projects that were delivered using the waterfall model. Providing the project was not a victim of scope creep or delays, it was a method that generally delivered on time and on budget. However, the waterfall model didn’t always allow for changes or delay, and it was responsible for projects running over time and over budget. With the best intentions and management, the waterfall model works and still has a place today for many software teams, however it can be the thorn in the side as well.
A little over ten years ago I was introduced to Agile software development, a way of working that I was initially sceptical and wary of; it felt very uncontrolled and susceptible to becoming a source of problems for project costs and timings. I stuck with it, and was incredibly fortunate enough to have some superb leaders to learn the ropes from; people who were advocates of Agile software development, specifically Scrum methodology. Thankfully I was learning from individuals who were driving the adoption of Scrum, and I soon became a fan of this way of working, and eventually an advocate.
The real turning point for me came when I joined a Scrum team who managed the entire software delivery and development process. Here was a team of 7 that had Scrum nailed down to perfection, every iteration of work that we embarked upon was successful in delivery content and quality as agreed with the team. It was a defining moment in my career as a QA and software development professional.
I’m now a Certified Scrum Master (CSM) and Agile advocate, and if I can see how the Agile way of working can offer improvements, I’ll happily drive this within software teams. I’ve used the Agile approach at many employer and clients now, I’ve learned from some great individuals who changed how software is delivered with Scrum and Kanban, and also with hybrid Agile processes that existed to work within certain restrictions of the organisations we were working with.
Having seen how the Agile methodology can improve software delivery (development and testing, release management etc) and also seeing how many teams have to adapt when some aspect of Agile doesn’t offer the best solution, I’m still a huge fan of this way of working.
Agile teams all have slight variations in how they work, it’s one of the features of Agile that I really like. Adopting Agile doesn’t always mean a massive change in how your teams work, but it can offer a huge improvement. Some projects are still delivered with more traditional project management methodologies, I’ve recently worked with a client who did not use an Agile approach; having been reminded of this approach, I’m still of the personal preference to the Agile way of working.