Managing Technical Debt

Really good discussion about Technical Debt by Michael Halls from Three Beacons
"Technical debt" term coined by Ward Cunningham in 1992 also called design debt

1- Unintentional
Examples:

• Lack of Training
• Wrong skill mix in the team
• Less requirement clearity
• Platform rewrite when we don't know current technical debt

2- Intentional:
Examples:

• Valid business reason (Limited budget)
• Generic variable name
• Not following conventions
• Code hacking
• To Dos 

Watch complete video:

Mistakes from New Agile Teams

I attended really good event last night London Agile Evangelists arranged by Arrows Group presented by Paul Bowler.

From his previous experience he explained some good bias about the teams new in Agile how they usually fail to achieve the product and velocity.

1- Texas sharpshooter fallacy:
You tend to ignore random chance when the results seem meaningful or when you want a random event to have a meaningful cause.

2- Confirmation Bias:
Your opinions are the result of years of paying attention to information which confirmed what you believed while ignoring information which challenged your preconceived notions.

You keep asking people until someone confirmed the answer you looking for.

3 - Subjective Bias:
Decision making or evolution based on personal, poorly measurable, and unverifiable data or feelings.

4- Interloper Effect:
Tendency to value third party opinion without motive. We value third party opinion as being more objective and trustworthy.

5- Survivorship Bias:
Tendency to ignore failures or overlook failures it can lead to overly optimistic beliefs.

6- Optimism Bias:
Causing people to ignore failure and what ever happend they will achieve this even though they can see the big failure but just ignoring it.

7- Bandwagon Effect:
This is an observed social behaviour in which people tend to follow what others are doing and thinking without considering their actions.

8- Correspondance Bias:
Blame other people and their behaviours.

9- Information Bias:
It comes from less information and some measurement errors.

There were some more bias in Paul Bowler presentation bit these are the one which I picked best from my experience.

Agile Team Roles

One of the best explanation video of Agile Team Roles 

Wiki's link more for distributed teams

I don't believe the agile teams, which are situated in same building, and same room should help out one another by sending Wiki's link. Agile is all about communication and face to face communication is the best way if you can do. I did notice quite a lot people like this trend to share wikis and ask to read through and come back with questions. Communication is a one of most important key for Agile team to understand and help each other to progress well towards sprint goal.

Agile Manifesto about communications:

"The most efficient and effective method of conveying information to and within a development

team is face-to-face conversation."

PMBOK about communications:

“Face to face meetings are the most effective means for communicating and resolving issues with stakeholders”

Scrum values

I was reading book in train this morning The Software Project Manager's Bridge to Agility and found these scrum values which are so well explained. Agile team should understand these values and dedicate to these rules.

• We believe in openness; therefore we will share project status as visible as possible
• We believe in respect; there we will treat everyone with courtesy and fairness and will not waste time in finger pointing
• We believe in courage; therefore we will not stand back in difficult conversation and say 'no' when we must
• We believe in focus; therefore we will organise our work in sprint and give priority
• We believe in commitment; therefore we will committed to our promise and will assume the accountability and authority we need to get it done and deliver