Based on whether the IT is doing the right thing (aligned with business goals) and whether it is doing it right (effective), the researchers divided the companies in four groups:

The figures in the picture are comparing to the average and over three years – so, for example, the group that has IT aligned with the business but not effective has 14% less sales growth than the average of all surveyed companies, but they spend 13% more than the average on the IT. On another hand, the group that has a mismatch in what IT does and what the business wants, but with effective IT, spends 15% less on IT then average but sees 11% more sales growth than the average over three years.

A very important note from Allan’s talk is that the transition from the top-left corner into the top-right corner is virtually impossible, unlike the transition from the bottom right corner into the top-right corner. Doing the wrong thing but doing it right turns out to be better than doing the right thing poorly.

For more information, see Allan Kelly’s post on this topic.

See other articles about Xp Day 08

When hiring through recruitment consultants, they got candidates who were very polished as consultants were asking people after interviews about the questions and preparing the following candidates, but rarely shared the values of the company. Rather than easily measurable features such as technical skills or years of experience, Rae and Shiell said that they were looking for team fit and eagerness to learn. Skills can be taught, but new members of the team must fit in otherwise the whole thing is not going to work (although they said that they were looking for people with some level of technical skills, as they expected new team mates to be productive very quickly).

Looking for people on job boards also wasted a lot of time, but advertising on specialist web sites (they gave an example of Joel on software) did give them a better signal to noise ratio. Referrals are a good way to find people as the reputation goes both ways, and people tend to recommend their friends who are genuinely a good fit for the company and the team. Unfortunately, the pool of people available in this way is very small. A very good solution which they suggest is hiring through the community. People coming to community events often share the same values as the community, have a keen interest to learn and are generally more interested in software development. This pool of people is relatively large and has a very good signal to noise ratio. However, this group of people is also more demanding and expects more out of their working place. Getting the company involved in organising community events is, according to Shiell and Rae, a very good way to get others interested in working for you. It is also a good way to share ideas and get introduced to new people. As an examples, they said that their company organised coding dojos and invited people from the outside to participate.

One other interesting idea that they presented is putting together a short technical coding challenge that is sent to candidates by the HR, even before any programmers review the CV. This allows them to quickly filter out people that do not have the basic coding skills or do not work in a way compatible to the team. For example, if candidates had agile and TDD on their CV and sent in the test result without any unit tests, they were filtered out immediately. This idea helped them save a lot of time by not interviewing inappropriate candidates, although they suppose that it also put off some good candidates who did not have time to do the test.

As a way to make the most out of the in-person interview, Shiell and Rae also suggested organising a pair-programming session during the interview. This helps to filter out people who did not do the test themselves and also allows them to check whether they can work with the candidate and whether he will fit into the team.

See other articles from XPDay 08

The discussion that followed turned out to be very indecisive. Some people thought that pair programming is appropriate for all the tasks, whenever a line of code was added, removed or changed. Most people argued that pair programming is not always justified, for example for mundane tasks or for simple tasks where the second pair of eyes does not really bring any benefit. We tried to define it more precise, but every time someone came up with an example when pair programming should not be applied, someone else presented a different view. We ended up agreeing that code refactoring and cleanup is something that pairs should do in all cases, but for any other tasks we did not have a general agreement. Drawing a precise line when to apply it and when not turned out to be virtually impossible.

On the end, we came up with a proposal to start pairing on all tasks, and then five or ten minutes later decide whether the task actually justifies having two people to work on it together or not. That way we turned the question upside down. We concluded that we should not really think of deciding when to pair program, but splitting the pair temporarily if they both agree that for a particular task there is no benefit.

see more news from xpday 08

Ambler talked about his engagement as the European QA director for Electronic Arts, where he tried to get the business leaders define what quality is in order to be able to assure it. The effort ended up concluding that people really did not know how to define quality. Quality means different things to different people, Ambler concluded. He defined his meaning of it as:

• Progression: people can get through the software from the beginning to the end
• Stability: people should not have unexpected problems with the software
• Experience: emotion that people get out of it

Taking the first letter of each word and inverting it, he said that it’s like ESP – very hard to define precisely. According to Ambler, and this is consistent with what I’ve seen in a number of places, lots of effort gets wasted because people involved in different roles do not talk to each other. Ambler said that designers, testers and developers each think that their part of the business is the most important and they do not communicate effectively together. The way to achieve quality is to get these people to work together. He concluded that as quality is individual requires collaboration, rather than automation. As some practices that have significantly improved the quality on his projects, he cited getting test leaders to participate in developer scrum meetings, getting developers and testers involved in the specification process and focusing on collaboration, not automation.

Ambler said that historically, from mainframe systems to modern web and online games systems, the amount of development on projects is reducing and the amount of testing is increasing. This is due to the fact that we have better and better tools available for development. In the games industry, Ambler sees blending of these processes with design going throughout the project from start till shortly before the end. Development starts a bit after design and ends a bit after, testing as well. These processes no longer have separate phases and there is a blend between them on the projects. This is how the games companies keep up the quality of their products in spite of the technical challenges that they face, and Ambler sees this trend as more and more important for the traditional software industry as well.

From my personal perspective, it was interesting to see this talk as it explores a lot of ideas that I am discussing in my upcoming book Bridging the communication gap, where the key point is that communication is the key issue in getting to software quality.

For more on XpDay 08, see a list of XpDay08 articles.

This year, most of the programme is decided on the spot. There are just a few planned sessions, and the rest is going to be organised in the open space format. During the first day, a lot of openspace topics are focuised on soft skills and improving agile teams, including making money by rescuing scrum teams, discussing Yagni + Wisdom, aspects of software craftsmanship, and identifying qualities of agile developers. Tomorrow’s topics are focused a lot more on practical topics such as pair programming, acceptance testing, code quality and architecture.

As at the last Alt.Net UK openspace conference, there are quite a few sessions dedicated to acceptance testing which seems to be gaining a lot of momentum in the agile development community.

I’ll be covering the conference in detail on the blog, so keep reading. All posts will be tagged with xpday08.