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.

Nice Article on Agile Contracts

Here is a nice link on various types of Agile Contracts (Fixed Price, T&M, etc)

Software Development Vs Construction of the house

A house is being newly constructed in front of my house. I have been watching this from the last few weeks. One day, I saw the owner with the architect at the site discussing about something for a long time. I am assuming the owner was trying to explain his requirement to the architect. After few days, I could see the plan with the architect and he discussing the same with owner and making corrections. After a while, I could see some construction workers starting their work by digging the foundation, building the house wall by wall. I know that this is pretty much the same process everywhere no matter where you are. Most of the time, the house gets constructed within the budget and within the time.

I was wondering, why can't we follow a similar process in Software development. In software too, we have the product owner, architects, etc. Why can't we deliver the software within the budget and on time (atleast 50% of the time).

I know we can't in software, here are some of my thoughts:

1. During house construction, there is mostly freezing of requirements during the initial stages

2. In waterfall model, freezing of requirements was tried and we know it was a failure. In agile methods, we tend to keep this open and ask the customer to prioritize and give the requirements.

3. Advantage in software development is, the customer can change his requirement at any time. So, there is a huge responsibility on the software architect to have a flexible architecture.

4. During house construction, since the requirements are frozen, there is a little room for the owner to change his requirement once the foundation is laid. It does not mean that the customer should not Or cannot change. But the key point to note here is "Cost of change" in house construction is more than in software development (assuming robust architecture is in place !!)

Good Books on Agile

Here is the list of some of the good books on Agile software development and related areas. I am hoping to keep this list updated:

1. Agile and Iterative Development by Craig Larman
2. Agile estimation and planning by Mike Cohn
3. Extreme Programming Explained
4. Test Driven Development by Example
5. Pair Programming Illuminated
6. Agile Project Management with Scrum by Ken Shwabber
7. Agile Project Management by Jim Highsmith
8. User Stories Applied by Mike Cohn
9. Rapid Development
10. Crystal Clear
11. Goal
12. Critical Chain

Scrum Vs Traditional Project Management

Here is a nice article comparing Scrum with Traditional Project Management

Traditional PM Vs Scrum Master

When agile methodology(specifically Scrum) is introduced into an organization, first question that is discussed is about the scrum roles. Many of the Project Managers(PM) get worked up about their new role as Scrum Master(SM) and lack of clarity around this new role(SM).

There are a lot of misconceptions and misunderstanding about role of SM. Most of the questions comes from the statement that "Scrum Master has no authority". It is the inherent nature of human beings to "Control" things around them. PMs start connecting that "No authority" means "No control". They feel powerless.

Some of the common functions executed by traditional PM include:

1. Assigning tasks to the development team
2. Estimating the features and tasks(by sitting with architect or tech leads)
3. Resolving conflicts among team members
4. status update on behalf of team members with the customer
5. Time sheet management
6. Resource management
7. Change request management
8. Single point of contact for the management for anything related to project
9. Single point of contact for the on site team for anything related to project
10. Leave approval

and many more...

Responsibilities of Scrum Master include

1. Ensuring that everyone follows the scrum rules
2. Bringing the scrum team and product owner together
3. Removing the impediments from the project
4. Helping the team to move towards self organization
5. Servant Leader
   

If you compare the roles of PM with SM, you could see that many tasks are missing in SM. Who would do those tasks ? Everything lies with the team. This is exactly the reason why self organizing team is critical for success of projects practicing Scrum.

It is critical that traditional PM is convinced and has understood the roles of SM properly. Any misunderstanding leads not only failure of the project but also, failure of the entire team in implementing agile. Traditional PMs with half baked knowledge of Scrum Master role would be causing more harm than anything else.

Can velocity be used to measure Productivity ?

I have heard many managers in software companies trying to measure productivity based on Velocity of the team. I think it makes no sense.

Here are some of my thoughts:

1. Velocity is measure of team's capacity to deliver certain functionality within a specified interval. This definition makes it clear that, one cannot use the velocity as the stick during appraisal and performance evaluation for individual members.

2. You cannot use velocity to measure the productivity between teams also. Reason being, each team is different. Two teams with 10 developers each, cannot be compared. Each team would come from varied years of experiences, domain knowledge, maturity, support from product owners, communication skills, etc.

Toyota and moment of Zen

Here is a very good article for all who would like to improve on a daily basis. I could related many of the practices in this article to scrum meetings and retrospectives. Must read for entrepreneurs and managers to create a learning organization.

http://www.fastcompany.com/magazine/111/open_no-satisfaction.html

Velocity and more

Here is nice article from Mike Cohn about Velocity

I find that one of the most common mistakes teams make is to use the
term "velocity" to refer to both
--the number of points (or ideal days) finished in a sprint
--the amount of planned work completed in a sprint

It is far more useful to use velocity to refer to the amount of
points finished in a sprint. The amount of work planned in a sprint
will be relatively constant sprint to sprint. This is essentially the
Y (vertical) intercept of a sprint burndown chart. If you need a term
for that call it "capacity." The tough concept for some teams to get
is that capacity (# of hours of work planned into a sprint) isn't
clearly correlated to the # of hours worked in a sprint. To make it
simple, consider me a team of one doing a one-week sprint. I will
work 40 hours this week. If I'm a perfect estimator (impossible) I
can say "I'll answer email for 20 hours this week (I wish!) and spend
20 developing; let me pull in 20 hours of work during sprint
planning." However suppose I'm not perfect and that my backlog items
have some uncertainty. Over time I may find that when I see a pile of
work and say "that's 15 hours" that this is the amount that perfectly
fills up my 40 hour workweek. I may get 25 hours of time on task to
do what I called 15 or I may get the 15 done in 12. It won't matter.
What matters is that what I call 15 fills up my week. That's how to
plan sprints and to work with capacity.

Pros and Cons of conducting retrospectives

Here is a nice article about retrospectives

Retrospectives

Written by willem

Tuesday, 14 February 2006

After an event or project, all the stakeholders come together to celebrate the successes of the project, and learn from failure in a constructive manner without finger-pointing. After a retrospective participants have concrete actions for the next event or project, and can contain broader organisational change. Retrospective benefits: Closure Learning from our own mistakes Learning from someone else's mistakes Acknowledging aligned practices and accomplishments Rewriting organizational stories Learning a healthy ritual Discovering strengths of the organization Clarifying aligned roles for players Allowing to connect emotionally Challenging each others assumptions Providing an overview of what's actually happening in the organization Building trust across boundaries Clear results, that lead to realistic commitments Retrospective risks: Emotional upset Unrealized expectations Lack of follow up leading to frustration and distrust Last minute sabotage Repercussions and retaliations Loss of control at the top Increase in awareness of personal responsibilities and accountability And of the chasm between responsibilities and accountability Can be a life style changing event Discovering that you waited too long to do aretrospective Discovering some of your assumptions are invalid Risks of not doing retrospectives: Emotional upset piles up Repeating mistakes over and over again Carrying forward unhealthy relationships Not using an opportunity for sustaining and reinforcing best practices Lack of adaptivity Less access to hidden wisdom Not having your assumptions challenged Would have could have should have thinking Learning organization is not learning Getting stuck in causality loops Less access to hidden resources Retrospectives can provide lessons on architecture, planning, communication, product information flow and possible early intervention points.

Tips on Iteration Planning

Stumbled upon the 17 tips to iteration planning . Even though there are more to it, one can add, but definitely these are the ones to start off with !!

Dos and Donts during Planning Poker

Here are some of the tips that could help during planning poker estimation sessions

1. Ensure that all developers show the estimation cards in one shot. If the cards are shown serially chances that it could lead to "estimation influence" factor.

2. Don't sit in crumpled space during this session. Try to use a large room, and people sitting in such a way that they can see each other

3. People who have no idea of use case or requirements can opt out of the session. They need not be forced to be present.

4. Have a spreadsheet open and the computer connected to a projector ready. This would help all the team members to see the requirements clearly.

Please note that, Planning poker estimation, even though more light weight and accurate than other estimation techniques, it could lead to in accuracies. The inaccuracies results from inadequate estimations in the technology or domain that they are working on.

Pair Programming benifit in a short sentence

Pairing takes about 15% more effort than one individual working alone, but produces results more quickly and with 15% fewer defects [Cockburn & Williams]. Fixing defects costs more than initial programming [Boehm], so pair programming is a net win. -- Jim Shore