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-
Agile teams are constantly running toward goals, requiring constant planning, monitoring, and re-planning. Metrics can help support these efforts by providing useful information about the health and progress of the project.
There are a few common metrics we use in agile teams: sprint burndown charts, release burnup charts, team velocity. They’re common because they communicate practical information, but they’re not the only metrics we can employ.
In my recent articles for TestRail blog, I described 3 Uncommon metrics you can easily create that will be very useful for your agile team. I also wrote about 3 Metrics that are not useful and you must stop using now!
Metrics are supposed to help and support an agile team by providing useful information about the health and progress of their project. But not all metrics are always beneficial. Going overboard with them can sometimes cause more harm than good.
In this post I have described three metrics that can impede your agile team instead of motivating you.
Agile transformations can be a challenging undertaking, and many organizations struggle with what is probably the hardest part of the transition: adopting an agile mindset. It is imperative that teams embrace the agile culture before they can fully embrace agile.
As I always like to say, agile is more a mindset than a process. It guides you to a better way of working and collaborating in order to deliver the most value to your users. But how you choose to implement those guidelines is up to you, and most teams coming from a traditional style of software development find this aspect the most challenging.
Teams are left to find ways to work together rather than having a process forcing them to do certain actions, follow certain processes, or organize specific meetings. There are no templates or techniques to adhere to and no rules to follow strictly.
This may come as a surprise and leave teams guessing since they are used to being told what to do and how. Agile drives them to think on their feet as they plan and replan their way through the development process. Read More–>
Being Comfortable with Visibility & Exposure
Agile gives everyone a voice and values every person’s opinion. Many teams have been used to only the manager speaking for them or having one representative in most meetings. As a result, some team members may feel flustered now that they’ll occasionally be in the spotlight. People who are not used to voicing their opinion are expected to speak in all forums. Hiding behind the team is no longer an option in agile.
This also means team members are valued as individuals and everyone’s contribution is recognized. Agile treats all team members as equals, whatever their role or designation. They are expected to estimate their own tasks, pick things to work on, collaborate with other team members, and provide value by the end of each iteration. Continue Reading–>