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
Lean is a manufacturing & production practice that considers the expenditure of resources for any goal other than the creation of value for the end customer to be wasteful, and thus a target for elimination.
… its a good idea to go back to fundamentals
Kano analysis was created by Professor Noriaki Kano in the 1980s and is used to optimise a product by categorising its features by perceived customer value. In a simplified form, a product’s features can be split into three types:
Essentials – those product features are essential for the customer to even consider buying it.
Linears – those product features that are linearly valuable, ie those where doubling an element of the feature is perceived as being twice as desirable.
Delighters – those product features that delight a customer – usually only a small number being necessary.
Human Factors International are running an essay competition, with a hard topic – How can the User Experience Community support the future of sustainability? My definition of User Experience may vary from others, as there are a lot of differing opinions as to aims and scope. This highlights the importance of the user experience, and as everyone sees the world a little differently to each other. But I believe in keeping things simple – User Experience incoroporates the design and functionality heuristics of a website. Pandering to users can be a disaster, so it is a fine line between Good/Bad User Experience. The “customer is always right” can be disasterous in software development. Just because someone knows what they want, it doesnt mean it is what they need, or indeed if they actually want it! How it can affect sustainability is a very (deliberate, I’m sure) open question.
Wonderful! The Post Office are obstructing our information on where Postboxes are, by refusing to list their locations – their techniques at delivering bad service has reached level of an actual recognisable business approach. And in keeping with turning Post Offices into some kind of Orwellian human cesspit. I always feel I am travelling to different parallel dimension. The banks are always following the “confuse the customer” appraoch, newer confusing layouts which give appearance of futuristic banking, without provising anyone who can help you beyond taking money out and putting money in. In the words of Roy from the IT Crowd, “What a bunch of b*stards!”.
Looking back at the original Agile Manifesto, outlined in 2001, it is very enlightening in hindsight …
In order to succeed in the new economy, to move aggressively into the era of e-business, e-commerce, and the web, companies have to rid themselves of their Dilbert manifestations of make-work and arcane policies. This freedom from the inanities of corporate life attracts proponents of Agile Methodologies, and scares the begeebers (you can’t use the word “shit” in a professional paper) out of traditionalists. Quite frankly, the Agile approaches scare corporate bureaucrats at least those that are happy pushing process for process sake versus trying to do the best for the “customer” and deliver something timely and tangible and “as promised” because they run out of places to hide.
The Agile movement is not anti-methodology, in fact, many of us want to restore credibility to the word methodology. We want to restore a balance. We embrace modeling, but not in order to file some diagram in a dusty corporate repository. We embrace documentation, but not hundreds of pages of never-maintained and rarely-used tomes. We plan, but recognize the limits of planning in a turbulent environment. Those who would brand proponents of XP or SCRUM or any of the other Agile Methodologies as “hackers” are ignorant of both the methodologies and the original definition of the term hacker.
Firstly “Agile approaches scare corporate bureaucrats” – the opposite is generally true now, but it doesnt mean they understand it! As with the now maligned 2.0, it is suffering from the increasing build-it-up-then-knock-it-down tabloid approach. Also it is very naive to think that a methodology can somehow change a corporation – bloated corporations will never be “Agile” – it is against the whole ethos of what a corporation is – a large company with no real responsibility or accountability anywhere, apart from the top of the tree – the place that isn’t even involved. To be fair, Agile Manifesto has been subsequently revised, and this first effort looks childish – the above has obviously been written by a fairly bitter developer. Mentioning the word “shit” in a blog post was no doubt shocking in 2001, but impresses me very little – and this is from the Agile originators!
So lets take the 4 core aims of Agile, still applicable in today’s version …
Individuals and interactions over processes and tools
Reality: Interaction has to happen across the board, and rarely does.
Customer collaboration over contract negotiation
Reality: This is assuming too much about the customer – for example, what happens if the customer cannot or is not willing to be fully engaged in process ongoing, apart from the initial PID (Project Initiation Document). That would lead to cries of where is the Project Manager (whose is primarily for passing the buck to on Agile projects, when things get complicated)? Oh, we forgot, we diluted their role effectively to observer. And unfortunately the Product Owner is also the client. Oh dear.
Working software over comprehensive documentation
QA Reality: Too little documentation, poor defect record maintenance, chaotic release management and shoddy release notes. It is a turbulent time for web development, with harsh timescales, but poor record will ultimately come and bite you squarely on your behind.
Responding to change over following a plan
Reality: See above two – it is only the first point that holds true, after the lessons learnt since 2001. Without the first, the other 3 will never happen.
In Quintessence: The fifth element for the Agile Manifesto, Uncle Bob states a fifth rule, which to me plugs the previous gap – ironically in development.
Craftsmanship over Execution
Most software development teams execute, but they don’t take care. We value execution, but we value craftsmanship more.
Agile effectively diluted the project and test managers role, instead of integrating these important roles. Development has an arrogance in approach of they-know-best. That arrogance is also good, as confidence in what you are building is important. But development do not understand business drivers outside of their own bubble, or more to the point, dont want to. This makes a joke of the manifesto, as the most common issue by far is development dictating direction too much, rather than the client requirements.
Many of the 12 Agile Guidelines are reliant on competent project and development management and a client/customer that is regularly engaged in the process. If anyone has been on a project with all these same time, please let me know!
Thanks to Agile (for all its benefits), testing has been thoroughly invaded by test consultants who use acronymns and terminology to build a shallow analysis or defence strategy. In fact, being adept at this can mean test consultants can remain on projects for a long time, simply pandering to project management who always like the idea of a methodology, as it can appear on face of it, so solve a lot of problems. People are always the problem, not the methodology. Hiring an ISEB tester or Agile-skilled tester will not guarantee quality – the standards do, but only if they are applied with expertise. The BBC is a classic case in point, suffering for a few years with obsession of hiring ISEB testers, regardless of background. Not wishing to tar all in same continent with same brush, but the most useless testers in my experience are generally ISEB-qualified Africans, who adeptly took advantage of this hole in the market. This led to some comical hirings, with some testers who could barely write coherently, let alone perform any qulaity testing. Standards and methodologies are all very well, but very open to abuse. BBC had no-one but themselves to blame, but then they have always had a blind leading the blind policy in IT.
Testing is a skill, it is not something an qualification gives you. You can pass ISEB by taking it a hundred times and learning parrot fashion from previous exams. Good testers come from different backgrounds in IT, and can bring that experience into testing. I have development and project management experience, which has added to my test skillset, as well as giving me communication skills with both technical and business parts of the project. I am also old and ugly enough to remember XP (Extreme Programming) in late 90’s, spawned from open source development methods. The following years saw a stampede of hybrids, with many Agile “manifestos”. Those who have been around longer than the web know projects have not changed that much – they are more rapid, require more regular engagement with releases from. The main issue with Agile is that it was largely designed by developers, who actually created this method so that project managers would leave them alone, and testers could be under some sort of development control. These are the parts I absolutely refute – development is a service to the project manager, testing is a service to the project manager to ensure the client (Product Owner) to ensure they get what they actually ask for.
I did some QA work for a company that suffered from the negatives of Agile – i.e. Agile bullsh*t was used as a smokescreen by external supplier Ixxus to cover up the fact they hadn’t a clue what they were building, and had no interest in finding out – they were waiting to leave, with as much money as they could get away with. Ixxus did it well by hiring two experts in the field, who proceeded to blind project and product managers with all the right kind of talk. Whilst the rest of us looked sadly on, and waited for the inevitable disaster. Does that hurt Ixxus? Tough – play the conman, take the blog post.
My approach? – I use experience – from success and failure, and aspire to provide companies with the best QA in terms of strategy and testing effort. Conning companies is not my business model, as I actually care about what passes through my QA-gate. Test Managers in general are harder to find these days – most sidestepped out completely or into other project roles. The role of the Test Manager has become the QA Manager, which is a larger remit beyond managing testing – managing releases, contributing to requirements, coordinating development team. Scrummaster is in fact a re-badging of QA Manager, just my opinion but they are only so many ways to project manage, develop and test software. Bizarrely, given the integration of the client/customer of a product, into Agile methodology, the client/customer always is most at risk of not being involved.