This is continued from my first post on Agile Software Development with Scrum.

I've skipped over chapter 2 because I honestly didn't get to take any good notes. I might have to go back and skim over it.

Chapter 3 has the following to say that stood out to me:

1. Mix people with different strengths and weaknesses
2. Scrum is empirical - The team can still break the work (functionality) down and meet their goals, as long as they are working on something.
3. Teams should be about 7 people, plus or minus 2. Less than 3 reduces productivity gains.
4. Have lots of white boards

Daily Scrum Standup Meetings

Every morning the Scrum Master visits the team amd they hold a 15 minutes scrum meeting. Only team members get to speak during this time. Others can watch, but can't interfere. The topic stays on the current sprint, except when there is something that is interfering with it. There are no side conversations. Members can either sit or stand.

The following 3 questions are asked by the scrum master and answered by each team member:

Q1. What have you doen since the last daily scrum (24 hours)?
Tell of any impediments or anything not related to a teams work.

Q2. What will you do for the next 24 hours?
This applies to only the current sprint.

Q3. What might have gotten in the way to stop you from getting your work done?
This could be personal or work related. Maybe you had to learn something new and additional training was required of you. Or there was existing software that needed attention. List any impediments on the white board and revisit the next day (i.e. meetings, tech issues) If there are too many impediments, the sprint may be cancelled

The team should make its own decisions
If the desicion is risky, then the scrum master needs to get outside advise. If at the end of the sprint the decision was deemed wrong, then it will only affect the past x days (30?) of the sprint. Any discussion of a topic should be done after the daily scrum.

Empirical Model of Process Control

I had to write down this term because it kept coming up and I agree with it very much through and have experienced it with just about every project, big and small. I quote from the book: "The empirical model of process control provides and exercises control through frequent inspection and adaptation for processes that are imperfectly defined and generate unpredictable and unrepeatable results or outputs."

In other words, programming is not a predictable process. There are too many variables involved that can make it change along the way. Technology changes and decisions change. You may think you know how you are going to design a piece of code and find it doesn't work that way at all or that there is a multitude of different ways and the one that is better is not know until actually put into practice.

Even on the business side. The requirements drawn up with likely change, as new ideas are added, old ones are scrapped or changed. Half way through the project whole new parts can be added to the requirements. Scrum and its Sprints try to reduce this interfering with productivity by not allowing outside changes. At the end of the sprint the decision can be made to add the new requirements for another sprint if time allows.