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

Is Scrum good for me?

The second question i get form most people (after "Does it actually work?") is does the Scrum process good for me?

Mike Cohn has showed a great technique for evaluation which of the processes out there is most suitable for your project. you can find the details here.

Read more »

Posted in: Scrum,tips

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

More Information about C.R.A.P

More details about the usage of C.R.A.P and what C.R.A.P is all about can be found in the following links:

1. Metrics of Moment
2. Clean Code and Battle Scarred Architecture
3. Alberto Savoia talks shop about C.R.A.P.

Read more »

Posted in: Crap4Net,tools

Crap4Net

Measuring code quality is a tricky business at best. More then a few attempts has been made over the years however still a single solution has yet to emerge. The C.R.A.P metric has been born a few years ago and tries to combine code complexity along with Code coverage to indicate (to some extent) the quality of a given piece of code. There’s much more to say about the C.R.A.P metric which ill leave for the experts . I will say however that more information can be gathered in the Crap4J website.

Over the last weeks I have been working on creating the Crap$Net project. The Idea is to bring the C.R.a.P metric into the world of .NET development by supporting the various tools used in this world.

I am happy to say I managed to wrap this effort into an open source project which was published today over at CodePlex, you can view the project home page here.

For now the tool is able to take the resulting xml reports generated for Code coverage and for Cyclomatic Complexity and generate a single XMl containing the C.R.A.P data. nothing too fancy but for starter this should do. the tool currently supports Coverage data generated by PartCover or by MsTest internal coverage tool . Cyclomatic Complexity data is generated by using the Code Metric add-in of Reflector. What was important to me is the ability to take this tool and plug it into a continuous build cycle and less the visibility of the data.

Future plans span two mains directions, the first is to include support of other coverage tools (if you have any preferences please leave me a comment) and if needed other formats of Cyclomatic Complexity reports. the second is to add some more fancy reporting which will include a basic html summary and maybe even some more stats on the underlying code.

So if you ever wondered how Crappy is your code, done wonder just download and get an answer.

Read more »

Posted in: Crap4Net,Metrics,Quality,tools,Unit Tests

Iteration Zero – using Testify

One approach when starting out a new project is to dedicate the first sprint/iteration in order to build in the framework for the development process. that is building in all the stuff which will be required during the time life of the product. things life setting up the build server, preparing the installer establishing the framework for unit and acceptance testing. in short all the technical details an agile development environment expect to just be there.

Today I managed to go into Mike Scott session in which he demonstrated his very nice tool called “Testify”.

I don't want to go into all the details since it appears that just today Mike has finished to ‘open source’ the tool. (can be found here). I would however say that during the short time in the session (about an hour), Mike has managed to create a new project which contained :

1. Some source.
2. Executable Unit tests (using NUnit)
3. Executable Acceptance tests – using fit
4. Setup a source control repository (Subversion based)
5. and Setup a continuous build server (using CC.Net)

Since I have done this kind of things a couple of times. i was really really impressed.

Read more »

Posted in: Agile practices,Conferences,TDD,tools

Agile Testing Days - ATDD

I went to Berlin for the Agile Testing Days Conference. I’ve join Elisabteth Hendrikson tutorial about ATDD, while is full day tutorial about the basic concepts and technique of doing ATDD. fro me this is a great opportunity to augment my knowledge about best practices tools and idea of how to improve my ATDD skills.

In the first part what really stood out for me is the time we spent about the various silos existing in a typical development environment. Specifically what i liked best is the emphasis Elisabeth puts about the need to break up those silos focusing on only establishing a clear separation between the role of deciding the “What” and the role of building the “How”. she quoted Tobias Mayer which defines in this post these roles as “The What voice” and “The How Tribe”

Read more »

Posted in: ATDD,Conferences