What Have we Learnt Today?

As usual during the Practical Scrum Course I’m giving. At the end of the first day I gather some feedback in the form of two questions I ask:

1. What was the most surprising thing you have heard today?
2. What is the most controversial thing you have heard today?

here are the (unedited) answers I've got this time:

The Most Surprising

1. How much client expectation can effect estimations
2. That in some projects a client can get a new version every couple of weeks
3. New approach to estimations.
4. That in 4 weeks we should finish X features (development, testing and documentation) and make them ready to be shipped.
5. Its important to leave room for “exciters” features.

The most controversial

1. Less documentation if at all.
2. Priority Poker technique
3. Everyone using a waterfall approach is following a “flawed" model
4. That “loaded” requirements document can cause estimation to increase
5. There is not enough consideration for the unexpected.

Read more »

Posted in: Feedback,Scrum

Gathering worthwhile feedback

Tobias Mayer has got me (and I guess several other) thinking about the common feedback process used by trainers. While I think that there's much to learn from the general purpose form handed out at the end of a training, clearly doing it only at the end of a training session means you cant use it for improving during a lengthy course.

Therefore I use two different techniques for gathering feedback during a course

Course Retrospect

this is actually quite simple and effective technique, towards the end of the second day. usually after I cover the sprint retrospect meeting. I conduct a short "retrospect" meeting with the aim of improving the actual course. My current favorite way is borrowed from Alistair Cockburn and we try to list out (together in an open discussion) the things which are:

1. Going good for us so far,
2. causing issues and difficulties,
3. and things that we want to try to do different on the next day.

That way not only do I gather feedback that I can use to improve on, we also get the chance to practice and witness the power of Sprint retrospect meetings.

Guided Questions

The second technique I'm using was inspired by Roy Osherove, and its a little more subtle. The basic idea is to ask a few (usually 2) open ended questions regarding the passing day. For a concrete example read these 3 posts: day 1, day 2 & day 3.

And this works really well. First, asking these question at the end of the day makes people go over and reflect on what they have learnt during the day. It take 5-10 minutes in which I see them going through the written material trying to fish out an answer. Just for doing this I think its a great practice. Second, I really learn a lot about how they grasp Scrum, what are the main difficulties, what is seen as beneficial, what they think will be easy and so on. And last in most cases the answers show me how well I did as a trainer. For example on the first day I got an answer saying that "Documentation is not needed." That was not the idea I was trying to convey (In fact I clearly specified that "its not that documents are not needed...." at least twice) therefore I need to improve on that (clearing that point again on the following day).

Both technique are simple, quite fast (takes between 5-15 minutes) and results in good feedback. combining them with the general purpose feedback form really works great for me so far.

Read more »

Posted in: Agile practices,Course,Feedback,tips,tools

What have we learnt today (last day)

At the end of the last day of the course I've asked two different questions:

1. What will be the easiest thing to implement at your company?
2. What is probably the hardest thing to implement at your company?

Here are the answers I've got (as is):

The easiest thing

1. Pair Programming
2. usage of Task Board (General purpose)
3. Stand up meetings
4. Creation of product backlog
5. Agile estimation Techniques
6. using Pair Programming to help bring a new team member up to speed

The Hardest thing

1. Automated unit tests/TDD
2. Division into Sprints (especially short sprints)
3. Locating people for scrum roles and creating a self contained team
4. XP
5. Building a true self contained team.
6. Pair Programming

Again almost no overlap of the answers (other then a few saying TDD /AUT is hard). I really enjoyed this cycle of the course, the people attending were really great and I would like to thank them for their feedback.

If anyone is interested in attending, next time will be toward the end of December. Just leave a comment.

Read more »

Posted in: Course,Feedback,Scrum

What have we learnt today/ (day 2)

On the second day I’ve added two more questions to the list:

1. What will be the be the most valuable thing to you?
2. What is the most useless thing you have heard so far?

Here are the answers I've got (again not edited):

The Most Surprising

1. A typical programmer manages 4-5 hours of ideal work per day.
2. The actual Scrum Master role in a Scrum process.
3. No hard delivery target (just an estimation), we commit
4. Priority Poker.
5. using Agile has brought companies to a defect rate of 1 per quarter.
6. that sprints can be 1 week long including planning.
7. that people can be involved/do tasks which are not in their main expertise area. (a QA helping a developer to estimate).

The most controversial

1. the SM doesn’t need to be a team leader.
2. The option for terminating a sprint.
3. a team which managed himself for a long period of time.
4. Vertical planning Vs Horizontal Planning.
5. a team leader should not be the Scrum Master.
6. sprint planning should take into consideration expertise of the various team members.
7. that the team allocate its own tasks.
8. no defined time for system analysis. no allocated time between sprints for turning the story into a requirement document.
9. That SM has no authority over the team.

The Most valuable

1. Techniques for estimations, task allocation within the team.
2. splitting the work into very short tasks.
3. Priority Poker
4. Vertical Planning
5. Group estimations
6. not using buffers.
7. the fixed sprint content that need to be formally approved at the end of the sprint.

The Most Useless

1. A manager should “keep” a private buffer and should be completely transparent with his team.
2. not allow people to multitask.
3. too much QA in the process (i don’t have enough QA people)
4. The Claim that “The Plan is worthless, Planning is important”
5. Team leader as the SM of a different team.
6. picking SM’s which are not team leaders.
7. that the team leader is not involved in the process of estimations which should be left to the team only.

What amazes me time and again that there is almost no overlapping between the different answers.

Read more »

Posted in: Course,Feedback,Scrum

What have we learnt today?

I've started today another round of the Practical Scrum Course. At the end of the first day I search for some feedback in the form of two questions I ask:

1) What was the most surprising thing you have heard today?

2) What is the most controversial thing you have heard today?

here are the answers I've got (not edited):

The Most Surprising

1. No true need for comprehensive documentation.
2. Estimations are done in units which does not represent time.
3. "Done" should be defined, sounds trivial but when one think of it ...
4. Agile can works for large groups.
5. Waterfall was presented as an example for a flawed process.
6. Scrum can be an appropriate process for most projects (90%)
7. Agile and Scrum, are established and well defined methodologies.
8. No Clear definition of who is the PO

The most controversial

1. Scrum can work for "Real Time" projects.
2. One of the goal of an Agile Process is to have Fun.
3. Velocity can't be compared between different teams.
4. Short iterations results in intensive management, in which we repeat many steps which lead to big overheads. (this is in response to the idea that short iterations are the bets way to develop software)
5. Stories should/can be represented by one sentence in the "customer language".
6. a process can work without "Requirements Documents"
7. Documentation is not needed.

Clearly there are some things I need to go over and refine again. However I also think that we are making progress.

Read more »

Posted in: Course,Feedback,Scrum