I get this asked quite often as well. 

Q: Are story points an excuse for teams not being  able to estimate correctly in days/hours? 

A: The effort and time required to arrive at an accurate number in days/hours for a story weighs against the benefits of estimating as such. Moreover estimating in days/hours puts undue pressure on the team to deliver within those number of days, leading to the team unable to reach a sustainable pace, and possibly burning out .

Additionally:

if we have an estimate in days:

• I see the “illusion of control” or the “pretend to be in control” phenomen
  and
• Developers tend to follow the “Parkinsons’s law”
  “Work expands so as to fill the time available for its completion.”

Great paper from ThoughtWorks
http://www.thoughtworks-studios.com/sites/default/files/resource/twebook-perspectives-estimation_1.pdf

This is something I get asked a lot in my current project.

Q: How do we know if the team is getting better at estimation when it is estimating in points?

It is a popular belief that if the team were to estimate in ideal days, then it would be much easier to track if the estimation is accurate, by checking the actual days elapsed on a story and the progress against it. This is however counterproductive as the team spends hours to estimate few stories to arrive at the magic number of days before being pressurized to deliver on that magic number.

When a team is relatively sizing stories in points, a trend slowly starts emerging where similarly sized stories start showing similar time to implement them. If there is a bad estimate, then that bubbles up automatically as an exception.

Great interview with Anand Vishwanath in this PDF from ThoughtWorks
http://www.thoughtworks-studios.com/sites/default/files/resource/twebook-perspectives-estimation_1.pdf

A fellow trainer pointed me to this post from David Anderson: “EXTENDING THE FIVE CORE PRACTICES OF KANBAN” 

As I’ve identified in presentations and key note speeches I gave in 2010, 2011 and earlier this year, the biggest oversight is leadership. Small acts of leadership from any member of the team need to happen regularly. It is these acts of leadership that make change happen.

So the 6th practice is: Leadership - give permission for ideas and encourage process innovation from any and all team members.

Sounds like building a team ;-)

There is also a need for explicit feedback loops. The Kanban book identifies these at two levels:

• the daily standup meeting at the team and individual contributor level
• and the operations review at the organization and inter-team or across services level

So the 7th practice is: Implement Organizational Feedback using Quantitative Measures of Demand and Capability

Sounds like having short feedback loops is a good thing

http://agilemanagement.net/index.php/Blog/extending_the_five_core_practices_of_kanban/

Look at the background of those 2 images. 

http://www.gizmag.com/boeing-battery-final-certification-test/26956/pictures#2

http://www.gizmag.com/boeing-battery-final-certification-test/26956/pictures#4

• Are they visualizing their work flow?
• Are they not using an electronic tool, but a physical board?

James Shore and Diana Larsen describe a model of Agile fluency including 4 stages of Agile Teams:

1. Teams Create Business Value
2. Teams Deliver on the Market’s Cadence
3. Teams Optimize Their Value
4. Teams Contribute to Optimizing the System

Great read!!

Full article
http://martinfowler.com/articles/agileFluency.html

Great article that describes common obstacles to agility in large organizations.

• Obstacle #1: Naive Resource Management
• Obstacle #2: Teams Organized by Functional Specialization
• Obstacle #3: Teams Organized by Architectural Components
• Obstacle #4: Distraction
• Obstacle #5: Reluctance to Continuously Refine, Reprioritize and Rescope
• Obstacle #6: Rampant Technical Debt
• Obstacle #7: Lack of Commitment to Transformation

Article in PDF Format
http://scrumreferencecard.com/Obstacles_To_Enterprise_Agility_255033.pdf

Or this URL
http://www.gantthead.com/article.cfm?ID=255033

Some previous lessons learned about this project in: 5 Lessons Learned from the FBI’s Sentinel Project

According to a GAO expert,
“It was a classic case of not getting the requirements sufficiently defined in terms of completeness and correctness from the beginning,” and
“had there been an [up front] architecture, the likelihood of these requirements problems would have been vastly diminished.”

Lots of people draw this quick conclusion.

Full article
http://blogs.collab.net/agile/case-study-of-a-difficult-scrum-project-fbi-sentinel

Gunther has some great visualizations of ”Lean” and “Scrum”.

He calls it the “The House of Scrum”: Standing on “Transparency” and 2 pillars: “Inspection” and “Adaptation” with the goal of the “Product”.

The House of Scrum is a great and energizing place where product development prospers from the combined, creative intelligence of people.

Who would not like to work there?

I really like the way how Gunther shows the compatibility between “Lean” and “Agile”

Lean  —- Agile

• Respect for People —- Self-organizing Teams
• Kaizen —- Inspect & Adapt, short feedback cycles
• Prevent/Eliminate Waste —- No unused specs, architecture or infrastructure
• Pull inventory (Kanban) —- Information Radiators
• Built-in Quality —- Definition of Done, Engineering standards
• Customer Value —- Active Business Collaboration (Product Owner)
• Optimizing the whole —- Whole Team Together (incl. stakeholders)
• Deliver Fast  —- Timeboxed iterations with working Increments
• The manager-teacher —- the facilitating servant-leader

Full article
http://ullizee.wordpress.com/2011/10/22/the-house-of-scrum/

Great insights into Elisabeth’s daily troubles. Worth the 30minutes

My favourites (which I see a lot)

• Why doesn’t separation of duties between engineers and testers work?
   (01:49)
• What’s wrong with the approach of writing and executing manual test scripts?
  (07:53)

http://continuousdelivery.com/2012/10/elisabeth-hendrickson-discusses-agile-testing/ 

“If i write something and it doesnt get used, i get angry”

The ultimate test for a tech lead:

Does the codebase look like it was written by a single person?

We need consistency in what we are doing

Read More

Great essay via Allan Kelly

Dear Customer,

I think it’s time we in the IT industry come clean about how we charge you, why our bills are sometimes a bit higher than you might expect, and why so many IT projects result in disappointment. The truth is that when we start an IT project, we don’t know how much time and effort it will take to complete. Consequently, we don’t know how much it will cost. This may not be a message you like to hear, particularly since you are absolutely certain you know what you want.

Full article
http://agile.techwell.com/articles/original/dear-customer-truth-about-it-projects 

1. Private sector expertise is valuable.
2. Agile development gets things done.
3. Commercial software plays an important role.
4. Agile development is cheaper, too.
5. Don’t deploy new software on old hardware.

Sentinel is “arguably the most important application at the FBI,” and agile development turned out to be the right way to complete it, Fulgham told me this week.

Full article
http://m.iwgov.com/264939/show/d46f562ca736be435abad7fc5e595bc3/ 

Great quote that recaps the thought: ”Demand Technical Excellence”

From Venkat Subramaniam found here
http://www.citytechinc.com/us/en/blog/2010/10/a_springone2gx_chres.html

2 great ideas by Arialdo Martini:

• Rule #1: write commit comments before start coding
• Rule #2: write what the software should be supposed to do, not what you did

Full blog post
Preemptive commit comments
http://arialdomartini.wordpress.com/2012/09/03/pre-emptive-commit-comments/

Great quote that highlights a delusion with Agile/Scrum

Put some high-school students in a hospital operating room and say: “OK, self-organize and perform brain surgery on this patient!”

Full article
Scrum, Skill and Dead Bodies
http://blog.chadalbrecht.com/post/2011/12/13/Scrum-Skill-and-Dead-Bodies.aspx