Many organizations take up the transition from waterfall to agile with the best intentions in mind. Like so many other companies, you might also be seeking to replace your traditional waterfall processes with agile in a quest to shorten the time-to-market and deliver high quality applications.
The road to agile, though, can be a rocky one! That’s why, in my latest refresh post for Ranorex blog, I have put together a few lessons and tips that will help you in succeeding in moving from waterfall to agile successfully!
This chapter is dedicated to talking about organisational problems with agile adoption, mostly from a cultural point of view- how people perceive changes, how they work, giving up control and also taking charge. It is a very comprehensive description of many problems we see on a daily basis at our work and in teams struggling with agile transformation.
Points to remember and Quotable Quotes
Agile teams are best suites for organisations that allow independent thinking.
Fear is a powerful emotion, and if not addressed, it can jeopardize the transition into agile
Testers who don’t change their approach to testing have a hard time working closely with the rest of the development team
If the organisation culture is to push towards release without caring for quality, the teams will face an uphill battle in working in agile
Companies where testers assume the role of ‘Quality Police’ will also have a challenge since teams will not buy-into the idea of building quality in, as they are accustomed to badgering it in later.
If your organisation focuses on learning, it will encourage continuous process improvement and will likely adopt agile much more quickly.
Testers need time and training, like everyone else learning to work in agile
To help testers adjust, you may need to bring in an experienced agile testing coach to act as a mentor and a teacher.
Agile focuses on working at a sustainable pace, all the time. In contrast to the ‘fast and furious’ testing done at the end of release cycles in traditional projects (often amounting to overtime). In agile, if overtime is required, it is an exception, and that too for the whole team and not just the testers.
In agile, the relationship between the customer and the development team is more a partnership than a vendor-supplier relationship.
Even if an entire company adopts agile, some teams make the transition more successfully than others.
About Introducing Change-
“Expect and Accept Chaos as you implement Agile Processes.”
Find the areas of most pain, determine what practices will solve the problem so that you can get some immediate progress out of the chaos.
The critical success factor is whether the team takes ownership and has the ability to customise its approach
Celebrate success- Acknowledgement is important if you want a change to stick.
Rather than managing the team’s activities at a low level, managers of agile teams focus on removing obstacles so that team members can do their best work
“Agile development might seem fast-paced, but the change can seem glacial”
“Beware of the Quality Police mentality— Be a collaborator, not an enforcer“
The highlight of this chapter for me was reading the ‘Testers Bill of Rights’
I had not heard about this before , so reading this was pretty cool, and for sure fundamental to any tester’s life. Check it out-