Change always costs money

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.

Advertisements

VS2010 – Automated Testing Cookie Management

Cookies

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

QA Chaos Management

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.
Continue reading

Agile is not a replacement for thinking

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.

What %$*! is Agile

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.

Where Agile Testing and Test Management Collide

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.