Clients are paying you to think as well

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

Continue reading

Why Agile becomes [Fr]agile

Its a bad joke, that’s been around for a few years – usually as comment on how Agile has failed, or is perceived to have failed, down to the methodology itself, rather than people/implementation.

What really frustrates me around Agile is the misuse of roles, and and creative accounting around Agile process. Continue reading

Agile Business

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

Agile pretender

The title is sometimes how I feel – I have worked in Agile projects for many years, and seen it implemented in many different ways – to varying degrees of success. I am not formally trained in Agile, but because of my development QA background, I see project processes as logic exercises – is the way we do things logical? Agile has great logic – Waterfall had logic geared to business drivers – the business expect a product that they ask for, they were not really interested in how it arrives. This is the big mistake, treating software as predictable path to the end product, based on original requirements at the beginning. This is how the Agile “chicken and pigs” analagy came about.

As a testing consultant/contractor, your remit is not to shake the whole company upside down. If they think they are Agile, then they are – in their own defintion. What is better to focus on, rather than harping on about Agile principles is to improve processes. Processes may be based on methodology, but are in fact methodology-agnostic. There is no ownership of logic – you can’t own a process. “Standing on the shoulders of giants” is a phrase worth remembering, as process improvments are on the back lessons learnt over the years. The Kano Analysis emthod, devides in the early 80’s could be transponded onto any product, not just IT projects.

Daily meetings are considered SCRUM, but arent they just a sensible idea? A lot of process is logic – and that logic is built of software engineering fundamentals. The technologies evolve by system logic doesn’t change – while we are still tied to machines that only truly understand binary, we have to be wary of wheel-reinventing.

It is important to consider company culture when coming in as a contract QA/Test Manager – primarily you have been hired to help, not hinder. Too often, testing is seen as an area that causes delays, and over-documentation. The primary perception should be that testing is ESSENTIAL and HELPFUL to the process. Bleating about Agile principles will simply put peoples backs up – no-one likes a whiner. Instead of dictating methodologies, examine current processes, and SUGGEST improvements – in real-life demonsrable fashion if possible. For example there may be a loose release process that works, but has loose ends. More than likely, the team would be grateful of a diagramatic representation – and within your diagram you can add steps/criteria. Getting buy-in is also critical to this activity – people generally agree with logic, but to get them to follow it, they have to feel engaged with the process. And feel the benefit. A developer will feel the benefit of a structured end to end process for issue resolution. All Agile roles will benefit from structured test reports.

Agile suffered from this perception, when all Agile was trying to improve was the SDLC in relation to efficiency in devlopment, and adherence to requirements (i.e. what the cusotmer wanted), and primarily communication across the board. Waterfall was the most popular because of it’s focus on milestones. Agile also has milestones, but more of them – common release (Sprint) period is 2-4 weeks, AND also daily dev->testing activity. So Agile is Waterfall with more granularity, and more focus around roles/responsibilites.

tinyeyes

TinyEyes will show you how a baby sees an image that you provide. Our baby-vision simulation method is based on scientific studies of infant visual perception. Please remember that this is our best scientific guess about how a baby of a particular age would see the world. There is quite a bit of individual variability, so any particular baby may see things differently.

Continue reading

User Stories Approach to Web Development

user_storyA User Story can be written by any User. The User Story should have a short but descriptive title and a longer description. The decription should include the 5 Ws: Who, What, When, Where and Why. This will also make requirements clearer to development teams, as the focus is not only on the functional, but on the audience.

User stories also free the developers to be creative in providing a solution, because they are focused only on the business need and not on the analyst’s perception of today’s (or yesterday’s) technical constraints.

WHO: Usually, the type of user
WHAT: What the user in the WHO is going to do
WHEN: “When” may describe a time or date or relative time (e.g After logging in or after performing a search)
WHERE: Where on the page or in the application.
WHY: What was the trigger for the user (user wants to suggest a change to the blog post)

Example 1: A user (who) clicks the article comment button (what) after reading a article (when) located at the bottom of the article (where) in order to make a comment about the article (why).

Example 2: An administrator (who) has determined which users to put into which discussion groups (why, when). Viewing the user listing for a group (where) clicks the checkboxs next to several users, selects a discussion group from the drop down and clicks the add to discussion group (what).

Example 2 is a bit more complicated. The “what” is a bit more protracted and the “why” and “when” are combined. For more complex stories it may be easier to list the 5 Ws first:

Who: An Administrator
What: Selects multiple Users(at once) and adds them to a discussion group
When: After determining what Users go in which groups.
Where: From the User listing screen.
Why: To get Users into discussion groups.

Using the 5Ws method can greatly reduce the amount of time it takes for users to produce good stories. When all stories are written this way they become easier to estimate and the why element give valuable insight into what a user expects from the application. This is a modern way to gather requirements, user-driven rather than technically driven.

Example Scenario:

Example of why User Stories are a better approach overall

The Functional Spec includes a non-functional requirement for an overnight batch run to create a particular database report.

Upon evaluating the user requirements it is discovered that this report was for only one person, who liked to begin each day by looking over yesterday’s figures. So we turned the requirement around and wrote it from that user’s point of view. Now the non-functional requirements is replaced by a user story concerning this persons’s wish to read that report. It completely replaces the earlier non-functional statement, which was clearly a solution, not a requirement.

Do I care about web 3.0?

After disseminating the wealth of information on web 3.0, the focus is a true implementation of Semantic Web. While I get a general annoyance from buzzwords appearing before any qualifying explanation, the fundamental philosophies of web 2.0 and 3.0 are sound and welcomed. To join in the the general free-fo-all for defining web 3.0, I see it as a marriage between data and intelligence to manipulate that data. web 2.0 is more of an starting effort, a draft for web 3.0.

Web 2.0 has already got many critics, and many criticisms on the shallower elements are deserved. Marketing and the “Nathan Barley”‘s of this world love latching onto the snappier technology terminologies. But its important not to lose the focus on the concepts behind it, or web 3.0. The people who work in newer technology know there is something good happenning with the web – a return to it’s original purpose, with all the benefits of the technology and philosophy that is around today. The paranoia of the web, and people’s almost comical perception of the www as a haunt of evil and peverse people, only serves as a hurdle, not a barrier to advancement.

web 3.0 will get here …… eventually