I am starting to think I am caught up in the same illusions around Agile as I think others are. We have been snowballed by this holy grail of methodologies, leading us to believe that Agile is somehow above all. But it will fail if applied without understanding. As would SCRUM. If developers are working in Agile way, and the SCRUM format is properly applied, then you can see the real machine working. Agile has its own management principles, but I (personally) find SCRUM much clearer in this area.
There is common assumption that is rarely mentioned. It is assumed that developers work Agile by default. Given the amount of coders I come across who don’t unit test, I would say this was a gross exaggeration. When it works well you have cohesion from Stakeholder/Product Owners down to the tester. Agile/SCRUM has just got 10 times harder; how to put a team like that together – and for a whole project.
Though SCRUM implementation issues are not country-dependant, I can say from UK side, there is too much made of benefit of mixing roles. This generally is a benefit for budget savings reason, however misguided. Too often than not you will have a Developer/Scrummaster with a Product Owner (full-time if you are lucky). The Product Owner role is rarely assigned on skills, and it should be, as it is akin to a Business Analyst. One of the dangers is the Product Owner becomes Project Manager. Most likely is development of Waterscrum, when release milestones are introduced, rather than Sprints. This kind of project can be successful – as long as Product Owner has become effective Project Manager.
The development team can code in Agile fashion either way, but Waterfall does not easily sit with Agile.
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Especially the last line – changing plans in Waterfall is not encouraged. This was how Agile evolved; to deliver software to the stakeholder in a better way technically, and to integrate changes to plan (for whatever reason), and additional requirements. Translating that benefit to a stakeholder during a project is a lot harder, and that is what the Scrummaster and Product Owner should be managing as a team – not one domineering the other. Waterscrum works because the team adapt (assuming they don’t fight back, of course). The two benefits the development team can retain from Agile is the daily meetings and improved communication line to the business. Generally the psychology behind people working on Agile projects is that they have to be more proactive.
Lets be clear, Waterfall was not wrong – but change needed to happen due to increasing demands from business, and more aggressive schedules. The web and opensource were the main instigators of this change. Agile has turned into a monstrosity, and I have heard so many variations on Agile, and how people manipulate it to suit their purpose. I have mentioned many times how I get fear of dread when I start on project and hear the words in first meeting “We’re working Agile!”. “I’ll see myself out” is what I would love to respond with sometimes, but I enjoy the challenge presented by chaos – or seeming chaos. Although people may get it wrong, sometimes you have a team which transcend this – bizarrely working without a methodology or formal roles. But they have the skills and they communicate. And deliver projects; a little scrappy to the finish line maybe, but the job gets done.
This isn’t that surprising – when human beings aren’t given a goal and/or direction, then they will find one. It’s in our nature. Agile/SCRUM harnesses that natural instinct. And then of course there is always a natural leader. If you think about the roles now, it fits with our primal urges to have goals and find paths to them. SO what do I think is needed in the team as a whole.
A strong Agile developer, at least one in the development team.
A qualified Scrummaster
A RELEVANT Product Owner – if they have decent business analysis skills, all the better
Tester(s) (of course!)
Damn – does that make the Test Manager redundant? Not at all, in fact, beneficial to have a Test Manager in the team, who have a wider scope than simply the daily testing, and provides input at planning stages such as risks, weak areas, testing schedule concerns. Test Automation is too big a subject to bring up here, but it is the only way forward for testing.
I still believe Agile works as a philosophy, rather than the stricter guidelines inherent with SCRUM. Different languages and source control tools can provide differing levels of features and functionality. And coding optimally with re-usability in mind is effective coding, whatever the methodology. So by default, the method of build and release should adopt Agile software development principles.