I enjoyed it very much apart from the few people that clearly didn’t want to be there and thus didn’t make an effort to contribute. One agile principle is to build your project around motivated individuals and trust them to get the job done. It is frustrating to realize that the project might fail because of the selection of people.

Contrary there was also a rather motivated group present. They started their agile project three weeks ago and had lots of good and detailed questions.

I also learnt a lot again. I need to extend the time for Q&A from 30 to 60 minutes although I answered questions along the way anyway. I think I will shorted the “User Stories” part. Frankly, I think it is not so important to have user stories if the requirements are given in another way. It is important to know the who needs what and why though and to have clear acceptance criteria. This can all be mentioned when talking about the product backlog anyway. I also need to improve the introductions to the Scrum form Hell and The Agile Hour exercise.

VersionOne conducted a global survey to highlight the value teams deliver from Agile development. Survey respondents work in companies of all sizes from small and mid-sized organizations to the largest global corporations. This survey summarizes the state of Agile Development in organizations covering every industry vertical from financial services, health care, and education to video games, government, and defense.

The “State of Agile Development” Survey Results

A bit more from the article:

How are open source software projects able to set their speed and quality on the best participants? That’s simple: “No meetings,” Berkus said.

“I’m serious,” he continued. “In a large proprietary software development environment, engineers spend four to nine hours a week in meetings, where they are given assignments by managers and expected to work on only their assigned project for the next week. Areas of responsibility are carved out carefully and elaborate quality control and review processes are enforced. The result of all this is to pace the engineers to the plodding pace of management, so that they can stay in control of the project.”

Another reason open source development moves more quickly is that engineers are on the projects they want to work on, limiting procrastination and “sandbagging,” said Berkus.

Lastly, Berkus explained that open source developers are less apt to work on incorrect or buggy code since the project is their own.

“Open source projects are less likely to follow ‘wrong’ specifications, because the same people who write the code are the ones setting the goals,” he noted.

• Ignorance
• Stress
• Boredom
• Human Frailties

were identified as some reasons.

Dr. Dobb’s | Avoiding the Most Common Software Development Goofs | September 17, 2006

The book summarizes the results of 2500 reviews of 3.2 million lines of code at Cisco.

“The book refers to a number of studies, some of which are relatively obscure. For instance, did you know that when reading a function developers repeatedly return to look at variable definitions? The implication is that short term memory doesn’t hold a lot, so wise teams will insist that all functions fit on a single page. Then it’s easy to glance up at the declarations without shuffling through paper or screens.”

“But engineers achieved the best results when inspecting at about 300 lines of code per hour or less. And after about an hour review effectiveness plummets. We get tired.”

“Expect to find about 15 defects per hour.”

“Authors who “annotate” and explain the code before the review have fewer mistakes. ”

“Best Kept Secrets of Peer Code Review,” is free (in US only, otherwise shipping rates apply) to order on-line at SmartBear. It’s a physical volume, not a PDF.