Although evolutionary, iterative and incremental development (IID) in software is in the ascendance as the modern or agile approach to replace ad hoc or waterfall (sequential lifecycle) development, its practiced and published roots go back surprisingly far. At least as far back as the mid 1950s, as a contemporary alternative to the nascent waterfall model …
Iterative and Incremental Development:A Brief History
Every Agile consultant is standing on shoulders of giants. In fact, we all are.
It’s only recently I realised how much we tie ourselves in knots over process, and an obsession with adopting processes at a surface high-level, instead of properly analysing what is needed. Processes are generally treated as if it is not possible to integrate them into other methodologies. The classic case is the step-down approaches, which have long provided business with the milestone approach that makes them feel comfortable. Release or Sprint? How about a Release containing multiple Sprints?
The true history of software development methodology called Waterfall…
In memory of Winston Royce
There is a risk in adopting Agile, that is an historical issue not even related to Agile. The bigger a company is, the better they can suck up failure. And in a huge company, 1 project pass/fail is neither here nor there in grand scheme of things. With Waterfall (step-down) methodology, these types of failures would happen “gracefully”, due to the lumbering nature of the roadmap, and lack of visibility of progress until release points. In the larger companies, on Agile projects, something strange happens …
The phrase “The customer is always right” was originally coined by Harry Gordon Selfridge, the founder of Selfridge’s department store in London in 1909, and is typically used by businesses to:
1. Convince customers that they will get good service at this company
2. Convince employees to give customers good service
Waterfall … much maligned, and earned it’s label and reputation post-Agile. In QA, we know how easy it can be to slate anything in technology. In fact, being a critic is an easy position to be in, as the onus is not on the critic to provide a solution. The evolution of Agile did not happen on the back on Waterfall criticism – it was simply a move to provide alternative to the methodologies available at the time, that did not suit the demands of modern development.
There are some good articles around at the moment about Agile and Business. The business approach to risk needs to change, avoiding Waterfall type check-points (milestones) to measure risk. An Agile project will stress under pressure of differing objectives between the Agile project and the business, if the old ways are not changed.
Continue reading
What is the obsession with saddling people with combined roles in Agile – and often they do not even know they have two – it’s assumed. The project manager was split into two roles – Scrummaster and Product Owner. I do not believe there was anything wrong with the role of project manager, but the Agile division made sense utilizing development management skills of planning and maintaining momentum, with the (assumed) business analysis and planning skills of the Product Owner. It makes sense on paper, but with the splitting of roles, comes more risk as you have to have the right two people. Very often the Scrummaster or the Product Owner falls into project manager role, due to weakness in one or the other.
In industries still early to Agile, they retain the usual Waterfall role structure, though development managers have become a rare sight. This actually doesn’t have to mean a disaster – the Agile roles are still fulfilled to some degree, although the Scrummaster/Product Owners are recombined into a project manager. In those circumstances the Project Manager will have a stressful time – and highlights that there is a good reason for the PM role split. To work in a Agile fashion is more demanding on planning, and it’s a bad situation if the project manager is spending 95% of his day on MSProject (or something less hideous).
Even worse scenario is when the Scrummaster and Product Owner roles are “missing”. Either through inexperience within the team, or people rejecting their roles by simply not performing them. Sounds strange? Look in any corporation and you will find this situation. The onus is that situation is that the developer(s) understand what is required to deliver an Agile project. But the stress this time is firmly in development camp – just the place where you not want a stress-overload. You will end up with a project that bounces around (and largely on the spot).
Comining roles can sometimes be sensible business move, but in Agile the roles are seperate for a reason. Ingore them, and dont’t even think “we’re agile!”. At best you will end up with a faster Waterfall struggle. If you are struggling to fill roles effectively, then maybe the methodology isn’t for you … not without changing your approach.
I hear and use the phrase “keep it simple” a lot. Yet struggle to follow my own advice. In dissecting Agile, I get lost quickly in various (relevant) tangents, but ultimately the same problems in testing remain. Agile fails to properly specify the role and benefit of a tester, demoted to a developer add-on. And as a lot of developers fail to properly unti test, the tester can quickly become a unit tester. Since when did a developer need a PA? Unit testing is a given, regardless of methodology.
My first instruction in testing 16 ago, was to:-
1. Using requirements document, outline test cases from it.
2. Cross-reference requirement to test case
3. Expand test cases in test script(s)
3. Review test cases every release (for amendments or additions)
5. Always regression test with every release (remember this was waterfall era!).
6. Document every issue
7. Document every release test.
Fast forward 16 years and this approach is still very valid, and adaptable for Agile or any methodology you care to mention. Testers are within the SDLC, but also tracking progress at requirements level. That requires a degree of distance from the daily world of development. The UK is sorely lagging behind in Agile evolvement, caught up in the same mess that started a decade ago.
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.
jaffamonkey 