Hallway feedback

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.”

While it is a perfect way to do quick usability testing (especially if the team works in individual offices or cubicles, rather than in a war room), it can be used for fast getting a peer for the micro-brainstorming, peer review or just chatting about the architecture. And if you develop software for the mobile devices, sometimes there is no need even to invite the peer to your place.

This practice looks simple, is simple, but also is effective. Though to make it working, you might need to encourage people to come to the hallway more often. For example, by placing there couple of sofas and a coffee machine.

Multiple options for success

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.

A little unexpected way of solving this challenge would be to delay the decision as long as possible. The later you make a decision, the more information you have, the more time you can spend or research and eventually you can make a more educated choice. In some cases it is even reasonable to simultaneously develop several solutions in order to make sure that at least one succeeds.

A Toyota Prius Case

One time when Toyota was starting the development of the first mass-sold hybrid car in the world – Toyota Prius, they had three engine options: one not so good option, that could be developed on time for sure, one ok option, that was somewhat more complex to develop and one potentially brilliant option, that could be developed on time only if everything went well.

Toyota engineers decided to simultaneously develop all three options. Even if the best option wasn’t ready, they still would have the acceptable option on time. I don’t know which of the three options eventually went into sales, but many have heard an unbelievable success of the Prius hybrid car. Three engine development teams took a lot of money, but missing a market window would cost a fortune more.

Your experience

Have you ever tried simultaneous multiple options development? Did the invested efforts pay off?

I’ve heard this Toyota story from Mary Poppendieck on XP2006

Pros and cons of short iterations

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.

Pros of the short iterations

– Very tight feedback loop. Feedback is gathered early, customer corrections are easier to integrate
– First deliveries are released real soon. Tight feedback loop is always important. The first feedback is even more important, than usually
– Strong focus. One or even two weeks are usually two short amount of time to loose the initial commitments and to start working on something not agreed with the customer

Cons of the short iterations

– High overhead. The shorter the iteration is and the more ceremony the process has, the more time is spent on retrospectives, reporting, re-planning, etc.
– More difficult to get resources on time. The shorter your planning horizon is, the more difficult it is to order the external resources like consultations or prototypes on time
– More chances to miss the big picture while digging in the small details
– Relatively high level of automation is required. Not to loose too much time on procedural overhead, everything that could be automated, should be automated. It is much easier to go for short iterations with the continuous integration and automated releasing in place

What iteration size is right for you?

The agile-style answer would be to try couple of different values and see which is working better in your situation. Start with smaller iterations in the beginning to get the most important first feedback early and then extend if you feel that too much time is spent on transactional issue.

What is the iteration size in your team? Why did you choose this size?

Precision and accuracy

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.

Accuracy tells about the level of confidence. A promise to implement a new feature next year can be a very accurate estimation while promise to complete it on May 12 is likely to be inaccurate, though very precise.

When planning, both accuracy and precision are the important components. Don’t miss one of them while specifying another one.

Agile Web Search Engine

Ever wanted Google to return poppendieck.com, when you search for Mary?

I was a bit tired of seeing a lot of rugby results, when I search for Scrum related sites and created the Agile Web Search engine. It is built on top of the Agile Web Search a try. Details and proposals on how the search results are/should be boosted up can be found on the forum.

Comments and proposals are very much welcome.

I also added the “Search Agile Web” block to the right side bar. It leads directly to the Agile Web Search results

How two hours have to waste two weeks

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.

Well, the agility is really about agility and there are several options of handling the urgent requests:

1. If external requests come more or less constantly (e.g. if developers have to support the old projects) team can plan for loosing couple of days of the every iteration for the support stuff

2. As Dmitri correctly noted and Joel somehow missed, there is a possibility to cancel the iteration and to focus on the external request if it was really important. The only thing the agile process facilitator (e.g. Scrum Master) has to do is to carefully explain the potential losses to the product owner or whoever is deciding on what is more important. There are extremely urgent requests that must be handled as soon as possible, just be aware that it might delay the main project two weeks, not just two hours

3. If the team iterations are not mini-waterfalls, but rather team develops the committed code feature by feature, there might be a possibility not to cancel the whole iteration, but to cut out the not yet touched features, complete the iteration as soon as possible and switch to that very important request.

There are very many situations when two hours can waste two weeks. However, there are situations when these two hours just have to waste two weeks. Agile processes don’t mind, they just want the decision maker be informed about the consequences.


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.

Project retrospectives

Project retrospectives are carried out at the end of the project or after the important release. The main goal is to improve the major issues. At this point team reflects deeper and gets chance to share its learnings with the whole organization. It is a good point to propose a new practice that would require a reasonable amount of learning and trials. Since project retrospectives presume major, possibly organizational changes, it is often ethically easier when the project retrospective is conducted by a third party and not a member of the team.

Killing the waste

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.

  • Less temporary artifacts, more verifiable results. Waterfall-oriented processes focus a lot on documented artifacts like requirement and test specifications, design documents, etc. While this information could be useful with the elimination of a big upfront design there is less need in producing long documents. The less time is spent on writing documents, the more could be spent on both coding and results verification. Agile processes use automated tests and demos as the specification replacements whenever possible.

Does your current project produce anything that nobody is going to use? Do you try to identify such issues?

Costs of the legacy code

“To me legacy code is simply code without tests.”
Michael C. Feathers “Working effectively with legacy code”

The legacy code is a known software developers’ headache. The legacy code is the difficult to change code that the developers don’t really understand. This code often is inherited from the old developers who left the company, it usually has little to no documentation and little to no testing code. Legacy code can slow down the development speed up to the real competitive problems. When it takes eternity to make a required change, a company can hardly stand a competitor that is able to release life-critical software every month.

I’ve heard about a company that used a brand new RAD tool to build a product blazingly fast. The development speed was impressive and they were able to release on time. Everything was fine until they decided to build the second product, partially using the first product code. Then they “suddenly” hit the maintenance problems: the tool didn’t have an automated testing support, nor it was possible to put in the external testing framework. The refactoring became a persistent headache and maintenance costs skyrocketed.

Unfortunately it is not always easy to make the legacy code maintenance visible until it is too late. Maintenance costs are often planned into another “maintenance” budget and too much software is planned as if there would be no second version.

Do you hit the legacy code maintenance costs often? How do you explain the need to do the refactoring to the high management?