Unlearn what you have learned...

For people right out of school... no problem. For those of us who suffered through years in the workforce, I agree with Nimesh that going Agile is somewhat about unlearning what we have learned.

9 good points in his article on the Scrum Alliance site found here.

Create a Proper Estimate Scale...

Tuesday I pointed at Jim Schiel's article about using an abstracted story point scale instead of calendar time (days/hours) for estimation. This morning I read a new article by one of his colleague's at Danube about their issues with their current internal estimation scale.

So, the question is, how DO you come up with a good abstract scale? Here are the main points I believe you need to address when attacking this discussion -

• Atomic unit of measure - the unit of measure needs to be atomic. This means that a value of 2 needs to be 2 times bigger than the value of one. A ten is 10 times bigger than the value of one. Why? so that when you know your team's velocity equals 10 and you select a 1,2,3 and 5 point story for a sprint, you know they actually add up to a sum velocity of 10.
  
• Restrict allowable numeric selections - don't allow just any old number to be assigned to a story. Poker planning estimation decks can't contain every number between zero and one thousand, and you don't want it to. Human brains are very bad at estimating. The larger the estimate, the larger the error. It is easy to state that something will take 1 minute to do... it is very hard to state with confidence whether something will take 60 minutes vs. 62 minutes. The higher your number, the wider the gap between confident values. Most teams use a doubling sequence (1,2,4,8...) or a Fibonacci sequence (1,2,3,5,8,13...). When estimating, you are not allowed to pick a number that doesn't exist in the sequence. Why? it is a waste of time to watch your team bicker over the 12 vs. 13 estimate value on a story when their estimation error is larger than the delta between the two sides of the debate.
  
• Create non-numeric selections - not all estimates can be covered by a value on your scale. Most poker planning decks include a few others. Examples: Question Mark (I don't understand enough to estimate with confidence), Infinity (I understand but it will take longer than we will ever have), Coffee cup (If I don't get a bio. break first, then my estimate will be whatever you want it to be), Zero (it can be done quicker than it will take to have this conversation). Why? This facilitates the conversations that planning and estimation need to flush out. Remember that estimation is not just about predicting, but also about understanding and committing.
• Pick a reinforcing name - pick a metaphor that will invoke interest and understanding. Many people call them points, but some use more interesting terms. Examples: headaches (bigger is bad), donuts (reward I'll get for delivering), dings (times I hit a bell when I deploy), dukets, dolla, goats, bricks, cans of jolt, etc. Why? It not only engages a team, but can put focus on a positive (or negative) part of the process that needs to be used as motivation.
  
• Allow adaptability - remember, this is an abstract scale. It can be adjusted. If after two weeks you find yourself using decimals because you need units under one... then shift your scale. I've done this twice and found two good options. Add a zero (multiply by 10) so that people don't lose reference to the old scale and can transition with ease, or make up a new scale and spend an hour quickly re-estimating the whole backlog. Why? When people have to think about what a value means, then they are losing their ability to do comparative estimation.
  

Feel free to add your comments about other concerns that need to be covered.

Note: If you are interested in other posts about why to use story points, I've also posted about it myself here and here.

Collaboration OVER Documentation...

Triggered by this good post by Fabien at the Server-Side Pad...

Folks... the Agile Manifesto does NOT say that we should throw documentation out the window.
Similarly, it does NOT say that collaboration REPLACES documentation.

Fabien's points are important since both of these misconceptions are common in newly transitioned agile environments. Teams seem to forget that anyone on their team can be pulled off at any moment and replaced with someone else. If enough of this happens, then their tests, code, and DOCUMENTATION are the only thing left after they are gone.

Part of my comment left on Fabien's post:

The manifesto clearly states that documentation is valued, but conversation is valued more. (Hence your important qualifier is already built in, people just overlook it!) What they were really trying to combat was the old-school philosophy of writing a set of requirements, believing it was done and pitching it. This lack of review and collaborative thought always led to a breakdown and finger pointing somewhere later in the process.

Failure condition...

People have beat this topic around for awhile now, and I have seen some interesting content about what will force an agile approach to fail... but I've never seen such a simple boil-down of this topic for both agile and waterfall side-by-side.

Thanks to Udayan for posting this simple chart.

Summary: unstable requirements + unstable team = FAIL!

Story Estimates...

Story estimates should be estimated in story points... not hours. I'm a strong believer in this. I have been ever since I went through my Agile "conversion" at Siemens Medical. The formal part of my education was mostly provided by Jim Schiel.

From a recent post on the Danube blog by him:

If your estimates are consistently incorrect, you are perfectly predictable.

Click through to read the full post.

The Principles of Common Sense Project Management

Reposted from the LinkedIn discussion group "PM Toolbox" for all the world to see:

The Principles of Common Sense Project Management

1. The process of Project Management is basically the same on EVERY project; it is the intangibles that make the difference in the success of the project.
2. LEADERSHIP is not synonymous with Project Management.
3. CREATIVE PROBLEM SOLVING is essential to Project Management. The SIMPLEST answers are usually the best one.
4. If you are not part of the SOLUTION, then you are part of the PROBLEM.
5. Bad news is not like an expensive bottle of wine; it DOES NOT get better with age.
6. Communication should never be MANAGED from stakeholder to stakeholder.
7. Of all of the project constraints … TIME controls the Cost, Quality, SOW (Statement of Work) and Customer Satisfaction.
8. It is better for your project, if the TECHNICAL EXPERT is not the Project Manager.
9. Your TEAM is the most important resource you have on a project.
10. Documented Lessons Learned are MANDATORY after the closure of a Project.

Common Sense is not common; otherwise more people would have it !!

Copyright © 2009, A.Sloan Campbell, MBA, PMP, P.Mgr, F.CIM

Additionally:

if you don't have time to do it right...how will you find the time to do it over? - Tim Bidlack PMP

RP: 10 activities of PO

Repost: From Jack Milunsky on the ASD blog, post about the 10 activities of a Product Owner. Bullets summarized here, read full post for details.

1. create/maintain product backlog
2. prioritizes backlog
3. assists with epics->story breakdown
4. conveys sprint/release goals
5. represents, interfaces, engages customer
6. participates in standing and sprint meetings
7. accepts/rejects sprint deliverables
8. can redirect team/project with each sprint
9. communicates status externally
10. can terminate sprint early if drastic change is needed