Group Thinking clouds decision

Recently I read this article, "Group Thinking Clouds Decisions" on live Science.
"http://www.livescie nce.com/humanbio logy/070221_ friends_memory. html

As per the above research, "People have a harder time coming up with
alternative solutions to a problem when they are part of a group, new
research suggests." and also, "When a group gets together, they can
miss out on good options,"

As agile practioners we encourage people to come together and make decision as a team. I am not sure, what is the impact of above research on Agile practices. I have put this question in Scrum development discussion forum, and one of the respondants came back with the following response

There is a natural tendency for groups to seek a sort of median, but
with a group of exceptional people, that can be a fairly high mark.
A single study does not decide much in science


Even I am not sure of the impact, but time could decide !

Agile Retrospective meetings for new scrum teams

Retrospective meetings are the heart of agile methodologies. Scrum teams follow this religiously at the end of each iteration.

When a team starts practicing Agile methodology, how should they conduct the retrospectives, what should they cover during their first retrospectives ?

Here are my thoughts
1. Take the help from an agile coach if you are doing the retrospective for the first time

2. Do the +/Delta analysis for the time already spent on the project in the past i.e. cleanse the past !. This session might take anywhere between couple of hours to a day, depending on how large the past is. Let the team select important times lines from the past(release dates, company meetings, customer visit presentations during project kickoff,etc) and create +/D for those events. At the end of retrospective, the information can be merged together.

3. Let the participants spend some time on thinking about the past events before attending the retrospective meetings. Let them have a brief summary of things that went well, and didn't go well and things to improve. This would save some "thinking" time during retrospective sessions.

4. If the managers are coming from command and control background, it would be better to do a separate retrospective for managers and development team. Read Diana Larsen's book on Agile retrospective for further information.

Semantic Diffusion

A nice article by Martin Fowler about thoughts, trends and future of Agile. He discusses the topic, if Agile just a buzzword ? where are we right now ? Are we on the right track ?

Testing Private Methods

Testing private methods was posted here

agile Vs Agile

Here is a nice article on Agile Journal trying to differentiate between Agile Vs agile

Traditional Planner Vs Agile Planner

How do you differentiate a traditional Planner Vs Agile Planner. Here are some of my thoughths about them.

Traditional Planner during planning

• Considers that the developer works 8 hrs per day.
  
• Allocates tasks to the development team and allocates features to fit into 100% of resource budget available

Agile Planner during planning

• Takes Ideal Engineering Hours (IEH) into account. It could be anywhere between 6 - 61/2 hrs per day (from my personal experience)
• Allocates tasks only between 70-80% of the resource budget available. For ex: if there are 6 developers working on 2 weeks iteration. He would then plan for 70% of (6 * 10 d * 6 IEH). (ofcourse, keeping holidays, planned leaves into account)
  

The 70-80% buffering is context dependent. Even though there is no standards available, Mike Cohn suggests, 70% of the planned effort needs to be targeted. There are various techniques to calculate the size of the buffer, and one of them quite often referred by Mike Cohn is "Square root of sume of squares" approach. I felt this is too mathematical and complex to apply during planing and many people have felt it is time consuming.

I have created a rule of thumb, if the iteration length increases, then the buffer needed to handle uncertainty needs to be increased accordingly.

I have tried with 80% planning in a 2 week iteration period, and it worked well.

One of the columns in Product Backlog(PB), we have been using at Valtech is "MoSCoW rule". This rule is extensively used in DSDM community. This column is being used to prioritize the requirements. These rules are very handy and easy to understand, as comapred to "High, low, Medium" Or "1, 2 and 3" numbers. It is advisable to fill 70-80% of the PB with Must Have requirements, and the rest with Should/could have requirements. Customer needs to be made aware that, if new tasks get discovered during iteration, the 20-30% of lower priority(SCoW) would be dropped.

More info. on MoScoW rule is available here

Tips during Requirement Workshop

While I was coaching one of the teams on Requirement workshop at Valtech, I jotted down some ideas, and here they are:

1. Once the feature team completes their "Questions", "Assumptions" part , ensure to do the Show and Tell exercise

2. During Show & Tell (ST) exercise, ensure to remove the duplicate questions/assumptions immediately as soon as they are found. This would help the team to consolidate in the end

3. During ST, If anybody in the team answers the questions(from the questions column), and found to be accepted by others, move the same to "assumptions" section.

4. If you are working on UI related application, keep the mock or prototype of the screen handy. This would immensely help the teams to visualize validations/screen structure, etc

Features and Tasks

I have seen many programmers getting confused between Features and tasks. Features are going to be part of Product Backlog and Tasks, are added by the developers into iteration backlog.

Features/Requirements are given by the Product owner. Iteration Backlog should contain only those tasks that would add value to the customer. There are certain tasks that need not be mentioned explicity. For ex: Refactoring, if you are following TDD.

It is assumed by default that Refactoring is going to be part of TDD(TFD + Refactoring). But, until the team gains profeciency in this area, they might have to explicity mention it in iteration backlog.
Similarly, Unit testing. If you are following TDD, then adding a task like "Coding..." would imply by default that, unit testing is done.