With Waterfall step-down process, a lot relied on skilled people – skilled analysts to interrogate clients for requirements, skilled project managers to keep project on track, skilled developers to code the requirements and skilled testers to ensure the beta release fulfilled the requirements to the letter. And with Agile, it is exactly the same. A change in Waterfall costs more money, and same with Agile. The point with Agile is that change was easier to introduce, and clients did not have to necessarily get all their requirements done from the outset. I am not sure if this was a good attitude to have, given that Agile required a continual feedback loop that included the oft-unavailable client. While clients and management liked the idea of Agile principles, at the same time, they behaved as if they didn’t apply to them. More often than not, clients would become indignant if change involved cost, even though naturally increased time = increased cost. Getting vision right from the outset is a sensible thing to keep in mind – whether Waterfall or Agile.
One of the values of automated testing is being able to run a set of tests as part of a suite or load. However, if you have sensibly built in some good protection using MVC anti-forgery or SAML tokens, then there is strong possibility tests can fail due to security functionality disallowing tests run too rapidly. Continue reading
A lot of developers would prefer to be out-of-range of testers – if you want to get into testing, then be prepared to justify your existence by any means necessary. Developers are awash with different types, from geniuses with Aspergers, to self-taught amateur with insecure chip on their shoulders. It’s not your job to judge, it’s to adapt – testing is always about adapting, and in some ways mirrors the demands of a developer career. But without us in QA, the SDLC can descend into a private club, excluding those perceived as “in the way”. It’s a fine line between squashing developer creativity, or allowing developers to run amok. Of course a decent Scrummaster should prevent this, but we are in the real world here.
Why do I hate Agile? The same way I am irrationally hate Microsoft and Apple? Well, close, but my mentality is a little more culture-based. My resentment of Microsoft is largely down to the abominable software. Apple may do it in a slicker and prettier way but the same proprietary software hell-hole as Microsoft. Regards Agile … I am English, so by default root for the underdog. I was drawn to Linux because this was first case I had seen of opensource in action. Software designed with passion rather than for demand. Technically brilliant, usability flawed – but still improving. Agile is in same bracket for me – a group of people deciding to do things in a better way, and challenging previous methods of doing things. And much maligned and misunderstood. I can only talk from UK perspective of course, but Agile’s arrival signalled a wave of buzzword frenzy around the subject – it had perfect soundbites for its unofficial salesmen.
Agile wasn’t sold to us – we adopted it. It is easily sold as it not dictatorial, and focussed around the importance of the team, and the processes behind it. It made sense to people. But then did it. In principle, in diagrams, in sound-bites it sound clear and logical. I mean, who could argue with more stakeholder involvement, more communication, organised sprints, adaptive planning, rapid development. No-one – but as with any method, its in the application. And mostly its in the team itself. More communication, people can manage – but its needs structure, it doesn’t happen organically; human beings slip.
First major, and I mean major, booboo was Agile weakened the project manager role. There was a thorough misunderstanding of project management in Agile, and in earliers days it was less clear, as Agile Management evolved a little later than the original Agile definitions. Project managers still existed on Agile projects, but generally less powerful. Power had shifted too far to development, which meant those outside the core SDLC were looking in rather than involved.
Over time this weakness was realised – and Agile was blamed. Why, I do not understand – people made assumptions, followed, realised error, then blamed Agile for putting them there to start with. So SCRUM become more prominent, with its clearer focus on the management side. Again clear diagrams, simple explanations, how could you go wrong? Well, just bacuase you fill the roles, it doesnt make the process magically work.
Waterfall has been slated so much, its become some kind of pariah – Agile is evolution not replacement. Now people are paying the price for that arrogance, and treating Agile the same way. A CEO at a Startup I was comntracted at last year, whined to me one day “the process isnt working, you are supposed to be managing this!”.
“How do you mean, its not working?”, I replied.
“It just isn’t working!”.
“So what is missing for you? All the issues and tasks are in there, assigned to Sprints”.
Of course, silence. Because he didnt know the first thing about having a project process, he was used to people just jumping when he complained. He liked the idea of SCRUM, but in hindsight, he expected it to mean he didn’t have make effort in the process. He was effectively the stakeholder, but behaved like a cavalier project manager. And let the largely weak development team do what they liked (who struggled with such lofty concepts as source/change control – but I dont expect much from flash/flex developers). The CEO was also expecting someone to wipe his proverbial rear as he lumbered along.
Know what happens when you taste 99% pure chocolate? The taste is so powerful it can be unpleasant. The same is true about agile software development lifecycle (SDLC) methodology and testing. Between Scrum Masters, schedules, specifications, requirements, sprints, test first, and user stories, many forms of testing – including load and performance testing, stress testing, and integration testing – can get lost.
Agile is a philosophy, and SCRUM is the most popularly adopted practice (project management methodology). The popular misconception is that SCRUM is a development methodology, when it’s not – but it has become one. I have been guilty of same confusion, but I don’t think this is necessarily a bad thing. Project management and development do have to work in sync, to achieve common goals. Agile has muddied the water, through its adoption as a fashionable term. Agile itself was inspired by the XP approach in Open Source development – rapid development, peer reviews, and a lot of creativity.
Agile software development is an appraoch to software development characterized by an emphasis on people, communication, working software, and responding to change. It does not define plans or process, just means to achieve them. The key lessons learnt from Waterfall approach was how the hiearchical nature of the methodology left no room for adapting quickly, and how requirements are sometimes lost or diluted in the chain. Very much dependant on arriving at “finished” product. In development, it is definitely the journey, not the destination, that is most important. To achieve goal in software projects, the path to the solution is never a straight one, and nor should it be. Shortcuts in development were more likely to happen in Waterfall environment, as if a project is working in Agile fashion, impacts of code changes are more readily found and fixed, that in the more rigid release to test framework of Waterfall.
Regards day-to-day development – this is largely left to developers to organise themselves in terms of dealing with user stories and associated tasks. Can you see the weak spot already? The mistake commonly made is simply apply Agile/SCRUM label to a project, and somehow things would magically happen. Hence why on projects development can end up running riot, or simply following part-paths, and maintaining a closed-shop to “outsiders”. Now that is where the Scrummaster is highly valuable – to ensure that both stakeholder expectations and development planning and managed in parallel – it takes a unique set of skills to do this role.
Now Waterfall didnt get it that wrong – it just aged badly, and like most archaic systems, is taking a while to leave. Which is why by far the most common term (first picked up around 2006), is “Waterscrum” – SCRUM implemented with Waterfall style
When an organization moves from Waterfall to Agile processes, they have to change more than just how to track the delivery of code. They have to change the practices of coding as well as the methods used to govern investment and manage risk. Waterscrum vs Scrummerfall
It has been on many websites, but here they are again: the 4 fundamental principles of 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
Unfortunately too many people read “instead of” for “over”! I am more familiar with unstructured and sometimes chaotic project environments, and I am usually brought in to do a bit of testing firefighting at the same time as defining and promoting process changes in project and development management. I like that style of working – bringing order to chaos. In spite them being latecomers to world of QA, they are willing to embrace what it has to offer, and Agile/SCRUM has gone a long way to both damage and promote perception of testing. I have lost count of the number of bizarre implementations of Agile/SCRUM I have come across, and applying a few good QA principles can work wonders.
Having a bad experience of Agile implementation can put a company off trying again. Whatever the issues with the implementation of the methodology, the methodology itself is generally blamed. Agile doesn’t suit all companies, as there is an assumption of everyone’s dedicated time and effort on the project, and the different working cultures.
Agile development methodology attempts to provide many opportunities to assess the direction of a project throughout the development lifecycle …. In an agile paradigm, every aspect of development — requirements, design, etc. — is continually revisited throughout the lifecycle. When a team stops and re-evaluates the direction of a project every two weeks, there’s always time to steer it in another direction.
Top 10 Open Source Web-Based Project Management Software
When a manager comes whizzing through the cubicles to see if you need anything from him/her without stopping to listen to your answer. Way for manager to know what his/her people are doing.Example: Every morning Sherwin swings by our area to say hi and pulls a management by driveby.
I struggled to find anything close to an Agile/SCRUM defect management cycle diagram, so have done one (click on thumbnail to see large version). What struck me as I was doing this, is it was largely no different to any other defect management lifecycle. Just substitute the following.
- Scrummaster=Project Manager
- Product Owner=Client
- User Story=Requirement/Use Case
The only addition I have made, as it seems to be forgotten in most modern methodologies, is the test manager role. Developers need managing so it seems a little odd that it is assumed testers are basically just “developer pets”, according to Agile/SCRUM. Not so – testers should have an impartiality, not be totally lost in same world as development. I could be harsh here, and say that Agile is an excuse to get testers to do developers unit testing 🙂 but that would be churlish!
ANother great testing tool from the makers of Selenium suite of products. This one netaly ties in the testing process, from requirements through to execution and reporting. Fitnesse did do this to some degree, but this is a much more user-friendly product, and at reasonable cost for a supported and stable product.
As one of the many (no doubt), who try and catch the internet waves, I realised my own personal weakness – tangents. In the latter part of 2004 I started a venture mullshrimp, whose aim was to provide an online DAM (Digital Asset Management) System, providing services to upload video of multiple formats types, rought-cut edit, and stream online. It was based on sound open source servers,encoders,decoders, cms. I am sure now I wasnt alone in that "idea" – in fact of course we have the cream that rose to the top in youtube – s truly user-friendly and clear service, and still is. I, on the other hand, became obessed with supporting as many formats as possible, and attempting to build a revenue model when just getting people to just use a service like this was a challenge. The question is have a I learnt from my mistakes, now that it seems media 2.0 is upon us.
Asides the unfortunate 2.0 tag, I see media 2.0 as convergence between web 2.0 technologies (microfomats, social networking) and digital media. I also note that these movements happen, regardless of fashion. So the original mode of web 2.0 is now proved in the field, so to speak, so time to incorporate more than just the generic. And so onto microformats … this is the web 2.0 area I latched onto to begin, albeit late! I have long used rss/xml as forms of aggregation, but now there are extended formats designed to support different purposes. Media, regradless of type – video, audio, photo, presenetations needs metadata, and it is this data that needs to be in machine-friendly format in order to be read easily by current and future microfomat SOA’s.
What my mullshrimp-bruising has already taught me is that just because you find a good application of technologies, what really forces the sell is adoption by the masses – the impatient ipod-generation ( a large market sector now). Eschewing the virtues of a DAM that supports multiple file formats, when instead I should have presented the public with a fait-accomplit. Why should they care what format their video file is in – they should just be able to upload and view it. THey want to be able to tag it easily, and also be able to rate the videos. I am forgetting that adults also have the "look at what I made!" drive. In many ways, I am victim of my generation – in a era where only outcasts used computers.
I have more or less given up trying to start a company in the UK – the environment and atmosphere is poor, and at many points over the last fgew years I have felt thoroughly ashamed to be english. Why i have latched on to technology so much, and the communities it is only place where you can truly count yourself as a "world citizen".