Agile Software Development:
It's NOT working. Oh Yes it IS ... 'partially'.
Call yourself 'Agile'? That's not enough.
Doing it without any management support? That's foolish.
This is an article by a tester. About testers' opinions on Agile. About testers' opinions taken in a survey by a tester.
After the success of this poll on testers' skills I ran another short survey to find out what testers really feel about how Agile is working for them. On their projects.
We read all the time about how to 'do Agile'. How to 'be Agile'. That we can be coached to work in an Agile way to deliver software faster. How you must be missing something if your deliveries do not run like a well oiled Agile machine.
Let's see what my LinkedIn community of Tester folk really feel about Agile. Let's get the "warts 'n' all" story.
Just short of 300 people gave me their valuable time for this survey. Thank you to all of you. The results were largely pro Agile. However, there are a lot of places that have not fully embraced Agile but their senior management team thinks they have.
As you can see, nearly a quarter of respondents said Agile is not working, for them.
Many of the reasons are quite worrying, really, and often boil down to not having fully embraced the Agile way of working. So, you can't blame the method if you are not following it fully. I'm not saying it is the best method to follow but first try it with complete commitment before writing it off.
A third of participants were perfectly happy with their Agile workplace and commented on close communication; complete buy-in from top to bottom of the company; and a shared endeavour. The benefits they saw were the promised quicker delivery; faster fixes; Continuous Integration; valuable lessons learned from retrospectives.
The majority, 43.3%, said Agile is only partially working for them. Their situations were where deliveries were solid but could be quicker. Or they experienced having to fight against managers who were still used to the 'command and control' style of management. Other points I will mention later.
As illuminating as the 'Yes/No/Partial' voting results are, the comments received are where I got the most value from this exercise.
Here's a selection whose sentiment appeared many times throughout the responses.
These are from those who are having less fun in their Agile working! Most require no commentary but I'd be keen to hear if you have seen or experienced them yourself and how you improved things.
Due to frequent releases and developers being late, there is no time for thorough testing
A common complaint, and not just in Agile.
The software released during sprints has lots of bugs
There are no decent requirements, so we are unsure what we are developing
Dev and QA are the same people but it works better if testers do the validation
No-one documents the User Stories, so it is chaos
Management forced it on us with no support and hence there is no team cohesion
Senior management don't understand it but force it on us
Where it doesn't work it seems to be controlled by Agile 'Experts' who have never coded before
It is mandated but may not always be the best model each time
Performance of the software is not considered early enough due to the focus being on the evolution of the UI / Functionality
This is quite a common complaint and I've seen discussions on LinkedIn where many have not found a clear way to plan for and test performance in Agile.
Agile in name only. Crisis driven Waterfall describes it better!
Agile works on small projects but doesn't scale to bigger projects
Automation from day 1 wastes time. Only automate when there is some stability
Wastes time communicating across many geographical areas just to keep team working together
Over commitment to delivery without considering resources available to do it
The team should co-locate
Get estimates from all teams before committing
We are Agile with sprints but software still delivered with big bang at the end
Should all share the same tools. Not some on Excel and others on a proper test management tool.
Command and control behaviours still exist which holds us back
Agile should be driven from the top down
Agile requires MORE discipline not less
No justifications documented for postponed user stories
Tests are written and executed after the user story is closed
There is no 'real' customer representation at sprint reviews/demos
The code for each sprint is not ready for release at the end of the sprint. Goes against the ethos of Agile.
Expectations are too high
Agile development schedule does not fit with IT department's quarterly release schedule
This came up several times and it is heartening that it is less a problem of the functioning of Agile but more to do with scheduling and aligning with other IT functions.
Organisation is not mature enough
Quality not good due to lack of documentation. No common understanding of minimum viable product
No customer so only feedback is from PO product owner and not the business
Here's some slightly more constructive comments:
Those involved should get training
Only use tools to support the process, not adopt a process to fit a tool
Those happy to embrace change make it work. Others create blocks and do not like being 'managed' differently
If the project is not that suited to Agile then use Wagile for the best of both worlds
We need to improve planning and estimation
From those with a more pleasurable and successful experience of Agile there came the more positive comments. These should reaffirm you have started along the right path, if you are on your journey to being Agile:
Will work OK if the commitment is there
Improves communication and cooperation within the teams
Stay Agile. Create more business requirements
Team is working collectively with input into planning and the way of working
We need an electronic status board as we are geographically spread
Good shared work with creating documentation
Continuous Integration environment is easier to deploy
Quicker to respond to change
Able to deliver more projects at the same time
The whole team owns quality, so we all have a vested interest in it
Agile is a mindset and the team needs that mindset to succeed
Some old fashioned test metrics need to be let go of. Management needs to implement Agile metrics.
Retrospectives and lessons learned need to be held
100% regression suite is automated!
I did not make this last one up. Some people reach that Nirvana!
I wanted to hear from real testers, anonymously if they felt safer, about how they experience working in an Agile way. Many will not comment publicly if things are not going well, for obvious reasons. Almost half of those saying Agile was NOT working responded anonymously.
I found that most of the negative experiences of Agile were highlighted by complaints linked to an incomplete adoption of the Agile 'ways'. Someone in these organisations has decided Agile is the chosen way, so perhaps they need to look into enlisting some help. An alternative is to revert back to Waterfall/V Model. They have their place too.
For others, Agile is delivering on its promises and the benefits of speed and greater team cohesion, and a better fitting product are being reaped.
Let's not lose sight of the purpose of software deliveries and that there may be more than the Agile way to achieve them.
Where does Agile go from here?
It's clearly not working for some and is working perfectly well for others.