While continuous integration triggers a build and automated tests as soon as anyone checks in or integrates the latest code changes, it is still needed to check in frequently to stay out of integration problems.

Continuos testing however runs the automatic tests continuously in the background as soon as the individual developer compiles his code. This way the developer gets immediate feedback both on compiler errors as well as regression test errors and the time and energy to keep the code well tested is reduced.

Read more:
Continuous Testing - research and an Eclipse plugin for continuous testing.
Continuous testing and CruiseControl - article by David Saff, developer of the plugin

Uncategorized | No Comments »

Still most of my writing efforts are focused on the paper, but I did some reflections on process improvement that I would like to share.

Process improvement is not about changing the process. It is all about changing people. Three things are needed to implement a change, and all three of them are needed.

1. awareness – that a change is needed. If the awareness that something needs to change is missing, nothing will happen.
2. will – to carry out the change. Same here, if the will to change is missing, nothing happens.
3. action – if the awareness and the will is there all it takes is action, but it is still needed.

I.e. it is not enough to hand over some new nice process documents and wishing the customer good luck. It all starts with creating awareness to change the process and then continues to create motivation and will to change the process, within the people of the organization from management down to the developer team. This is done with coaching and mentoring on site in projects with the customer.

Comments are welcome…

Uncategorized | 2 Comments »

At the moment I am writing a paper on Agile CM and I have some great ideas. I’m not sure what will be the result of this but I will probably make an effort to send it for review to a conference. If it is accepted I will let you know.

Uncategorized | No Comments »

Most people aren’t promoted because they are good listeners. They get promoted because they are good workers, or worse, good talkers.

Sometimes we think of successful sales people as persons that are good at talking and being persuasive, when in fact they should be good at listening and being receptive. Listening is the most effective way to learn what customers value. Can we afford not to listen?

Many people don’t listen with the intent to understand, they listen with the intent to reply. As listeners we can think approx. 500 words per minute, while the normal speaking rate is 150 words per minute. This gives us room to formulate the response in advance, but doing so you might miss out valuable information. Formulate your response after you have listened out everything that is said.

Want to become a better listener?
The Art of Listening

Uncategorized | 3 Comments »

One of the foundations of agile methods are quick feedback loops. Agile development methods aim for quick feedback to the end users. Meanwhile continuous integration is a way to provide quick feedback to the developers about the quality of their code.

Continuous Integration (CI) is a practice within Configuration Management where the integration, building, testing and reporting is automated by tools. As soon as a developer has delivered any code changes a tool is triggered that automatically builds, baselines, tests and provides a report of the status of the code base.

Integration should be done often by developers to avoid any big bang integrations that are complex to solve. Frequent deliveries are valid here too.

The reason for introducing CI is to automate tasks in order to decrease manual overhead in an (agile) environment with short iterations, frequent deliveries and collective code ownership.

Learn more about CI by taking a look at these excellent links:
Continuous Integration - article by Martin Fowler
Continuous Integration - article on Methods & Tools
CI link list - a list of CI links in a CM wiki
Cruise Control - an Open Source tool for continuous integration
Cruise Control Wiki

Uncategorized | No Comments »

The agile track at the JAOO conference this year sounds really interesting:

“What makes agility work? Meanwhile agile methods are state-of-the-art. Many projects around the world are using Scrum, XP, Crystal Methodologies, or other known or self-made agile methods. However, not every project is succeeding using agility. This year we concentrate on the things that make agility work. Thus we’re looking at the readiness for agility of the development organization as well as of the client organization and at ways on how to measure and improve the effectiveness of agile teams.”

Especially interesting is how to measure the effectiveness of agile methods. I need proof that it works in my arguments with some clients.

JAOO conference

Uncategorized | No Comments »

The main problem with peer reviews (or software inspections) is that they belong to a traditional way of looking at software development. In agile methods there is no need for peer reviews.

In traditional software development (waterfall, V-models and RUP) testing is pushed to the end of the development cycle and because of the very long cycles/iterations it becomes expensive to find and correct errors. To cope with this problem it is often considered, by the QA, to be a good idea to introduce peer reviews to find errors earlier in the cycle. However this is only treating the symptoms instead of finding the cause of the problem. One problem is that the process is too heavy and instead of slimming the process, adding peer reviews makes it even heavier.

A better way to solve this problem is to introduce agile ideas into the process e.g. short iterations to get quicker feedback, working closely with the end users, collective code ownership and using testing to support the development instead of just finding errors i.e. test driven development.

Software Inspections - an article by a guy who is thinking in a box, and who probably doesn’t agree with my article since he makes a living from inspections. Read his article to see the waterfall approach and treating the symptoms instead of attacking the cause.

Update [2006-08-22] Some views on code reviews:
Code Reviews Considered Hurtful
The Spirit of Code Reviews

Uncategorized | 2 Comments »

The daily standup meeting is a common method within agile development, but could be utilized regardless of development method.

The Scrum meeting is a short daily status meeting described in the Scrum method. The team gathers each morning for a standup meeting where each team member in turn gets to answer three questions

1. “What have you done since the last meeting?”
2. “What will you do until the next meeting?”
3. “What obstacles are in your way for completing your tasks?”

The questions should be in relation to the backlog to always keep focus on the items on the backlog.

The reason that this works so well is that we expose problems as soon as possible. This is the same principle as the “Stop the Line” culture of the Toyota production system that the Lean Software Development is all about.

Read more about the daily standup meetings here:
Agile Meetings - a great article from the STQE magazine
Introduction to Standup Meetings – article from DSDM consortium
Lean Software Development – a gold mine of interesting publications by Poppendieck

Uncategorized | 2 Comments »