Kano questionnaires

December 5, 2006 by Artem

One of the simplest ways of dividing the product features into must-haves, linear, exciters and even wrong features is to gather the potential customer's opinion with the help of the Kano questionnaires ( PDF ).

Kano model of customer satisfaction

December 2, 2006 by Artem

According to the Standish group research on average 45% of a software features are never used and only 20% of features are used always or often. It means that on average you could develop two times simpler product and sell it for the same price. Potentially gains can be even bigger, for the enterprise scale systems two times simpler product often means four times shorter schedules and ten times simpler integration and testing.

Hallway feedback

November 29, 2006 by Artem

Agile software development processes by any definition encourage the in- and-out team communication via various practices from pair-programming to informative workspace to retrospectives. With the respect to all the usual practices there is one more often underestimated way of getting the in-team feedback - the hallway testing. The term Hallway Usability Test coined by Joel Spolsky stands for "grabbing the next person that passes by in the hallway and forcing them to try to use the code you just wrote. If you do this to five people, you will learn 95% of what there is to learn about usability problems in your code."

Multiple options for success

November 27, 2006 by Artem

In a lot of large software projects there are some very critical requirements that require very critical choices be made early. For example, when building large web-application that has to sustain millions of requests per minute, a choice of the database, database schema and scalability options can play a critical role, yet it might be impossible to decide upfront which option suits your needs better. Typical agile-style decision would be to run a couple of architecture spikes to stress-test the potential solutions. Unfortunately sometimes such trials can take as much time as a half of the whole project.

Pros and cons of short iterations

November 23, 2006 by Artem

All the agile software development processes are iterative. Iterations are used in order to release complete increments of software within predictable periods of time and get customer or pseudo-customer feedback early. Different processes recommend different iteration lengths. Scrum is very strict in this sense and requires exactly 30 calendar days long iterations. This period of time is considered being a typical amount of time that product owner can allow the team go independently without the external control. eXtreme Programming brings the idea of frequent customer feedback to the extreme level and advocates for shorter iterations down to one week long.

Precision and accuracy

November 20, 2006 by Artem

High accuracy, low precision

High precision, low accuracy

Any plan is in essence a set of steps to perform in order to reach a given goal. Every goal and task has two important, but unfortunately often mixed characteristics: accuracy and precision.

Precision tells about the level of the detalization. A promise to make your database handle four simultaneous requests tomorrow at 9:30 is a very precise promise. A promise to make it handle hundreds of requests sometime next year is not very precise.

How two hours have to waste two weeks

November 15, 2006 by Artem

Today Joel Spolsky criticized the agile software development methods a hypothetical story by Dmitri Zimine.The story tells about Sarah the programmer, that had to spoil the whole two week iteration by complying to the urgent two hours long request of her project manager.

The issue that bothers Joel and makes him suspicious about the agile camp is the fact that the request could be really urgent and failing to implement it really soon might have cause a huge sale loss.

Retrospectives

November 12, 2006 by Artem

Every agile software development process by definition requires periodical retrospectives in order to pause, have a look at the current practices and improve the way of working. There are two kinds of retrospectives: major retrospectives that happen at the product release or major milestone and minor retrospectives that are carried out at the end of iteration.

Iteration retrospectives

Iteration retrospectives are carried out at the end of the every iteration. The main goal is the daily habits improvement. By discussing of what went wrong, what went well team gets a chance to share the individual observations, aid daily problems and eventually grow as a constantly improving team. Not to loose the power of periodic retrospection it is very important for an iteration retrospective to result in a specific set of changes. Reviewing own work takes emotional energy and people would not be willing to invest it if it won’t result in a visible outcome.

Killing the waste

November 10, 2006 by Artem

The goal of any project is to produce the best possible results at the minimal possible costs, while releasing early enough. Agile processes strive towards both maximizing the value produced and minimizing the amount of wasted effort.

Typical agile process ways of minimizing the wasted effort

• Do exactly what is most important to the customer now and nothing else. Requirements and the project requirement change. It is the fact proven million of times. Therefore too detailed requirements engineering and heavy upfront design are in the best case a big pack of wasted customer money. In the worst case they can result in a product perfectly conforming to the original specification, but useless at the moment of the release.