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

Infusing Some Kanban (follow-up)...

A week ago, I posted about infusing a few Kanban concepts into our team process and making other tweaks to our standing meetings. Here is a follow-up for those of you who are interested in how it turned out.

In parallel to the previous bullets:

• our cards on the wall have not been restricted to 5. BUT, the good news is that every time we go over 5 the team yells penalty at the CEO (the product owner) and requests that we swarm on existing cards before moving to new ones. The intention is there. (improvement!)
• the CEO is doing a better job of throwing things into the queue as we pull instead of having a weekend brainstorm and puking out a whole new set of priorities on Monday morning (improvement!)
  
• Our standups are more efficient and effective. At first I thought we were missing things because less was said and we ended early, but I'm slowly growing confidence that we are simply focusing on the correct things, consolidating topics into single threads, and reducing the noise. (improvement!)

Also:

• We are definitely focused on the "what" now instead of the "who".
• Standups are easier to follow for outsiders (if desired)
• It is easier to see where things are getting delayed

I will also say that it has become easier for me to coach. Instead of focusing on all the things I am trying to understand and piece together, it is easier for me to keep an ear for anti-patterns and push the team a little more.

So far, a success. I guess I am now a heretic for morphing the standing meeting away from the 3 questions per person. I can live with that.

Individual Scrum (follow-up)...

The other day I posted here about Pomodoro which I called individual scrum.

A couple days later I read a copy of "Getting Things Done" and posted about that on my personal blog (since it wasn't agile specific).

This pushed me to search for electronic tools to support some new ways of working that I was interested in achieving. That led me to a Facebook comment and some discussions around that. This is when I realized that my Agile blog readers might be interested in this information since it is about tech tools.

If you are interested in GTD, Pomodoro, or time management in general...check out the following:

• Nozbe
• Vitalist
• Remember the Milk (RTM)

All 3 have iPhone / Mobile apps to help you on the go.

I'm heading in the direction of RTM simply because it has a lower total cost and it seems to fit my needs (thought Vitalist was my other preference).

Peers of mine suggested looking into these also:

• Jott
• Evernote
• Todo
• Things (Mac only)

(Thanks Mike and Michael)

Enjoy!

2 great links...

• You get what you measure posted on Daniel Brolund's Weblog. It's a good factual background on a point I've made previously about not abusing your metrics.
• The product owner and the product-shaped hole posted on AgileProductDesign.com. Very thorough post about the role of an agile product owner or customer and how it is much more than stories and software functionality. Actually, it is a good follow-up to one of Jeff's past posts about the backlog.
  

Enjoy!

Individual Scrum...

I've been hearing about Pomodoro for awhile now. I can't say that before today I really got it. I've always felt I've had good time management skills and can tell when I need to adjust work habits to be more productive.

But that doesn't mean I'm as good as I can be...

Today I read a draft of the Pomodoro Book. I'm realizing that it is like TDD or Pair Programming in the sense that you can read what you want about it and form an opinion, but until you try it... you won't really get it. And by try it, I mean for a few cycles (most people don't get TDD or Pairing for at least a month or more of commitment).

The simplest way for me to describe the technique is that it applies techniques familiar in scrum to the individual through the day. Each day is a sprint, and each Pomodoro is the space between standups. That's not really accurate, but you'll see what I mean if you read it.

Kudo's to Staffan for working on this. I was surprised by the information held within. It not only focused on the technique, but it also covers a lot of good information about how we recall memory, keep focus, and how our brain processes information.

Infusing some Kanban...

The team I am working with was starting to have a few issues. We had too much on our plates, lots of noise, and the CEO was raising concerns that we weren't focused on the right things. We also had a feeling that the sprint end and begin was a magical flurry of stressful activity.

So we've implemented some changes:

• Our cards on a wall board is now restricted. Only 5 things can be in flight at a time. Everything is still in VersionOne; but only the top 5 get the explicit visibility of being important enough to be covered every single day.
• The CEO (highest level product owner) is responsible for filling and prioritizing the +5 queue whenever there is an opening. These are the next 5 things expected to move into flight.
• Our standups are no longer going to be asking the 3 questions going around the circle in the sequence we lined up around the room. Instead we are going to first talk through the top5, and then use the time remaining to discuss other notables as people need to. The team is responsible for taking their turn by importance and not going in sequence.
  

Our hope:

• This will shift focus from what "I am working on" to what "the team is delivering for the company".
• We might not get to every topic since not everyone will have an explicit turn, but we guarantee that we are talking about the right things.
• Outsiders can attend the standing meeting and easily see certain items and their status as opposed to hearing about an item across people throughout the meeting.
• We force the business to shift from magically identifying 5 things every Friday (1 week sprints) to constantly filling a pipe of work every day as we empty it.
• It is easier to see if our commitments of date and cost are at risk and communicate that to stakeholders because the topic is covered at once. (Our commitments are more safely limited to the top5.)
  

We see how it goes... (like many issues, we'll implement changes and slowly snap back to a happy medium as we learn and grow)

SM vs. PM...

Great thread on the VersionOne user forums-


Question from Andre L. Nelson

We have been having a big debate at my company about what is the role of the Scrum Master and the PM/Supervisor in Scrum. We are uncertain if they should be the same person or if they should be separate people. ... I'm kinda just throwing out a line and hoping for some insight from the community about either what they are doing with this or if there are any other posts or blogs I could read for insight.

From Skip Angel, SolutionsIQ Agile Coach:

Here's what I usually ask to determine if the person can be effective
as a ScrumMaster:

• Will the team have autonomy so they can truly self-organize?
• Will the team be able to make their own commitments each sprint?
• Does the team trust the ScrumMaster to protect the team so they can have focus?
• Will the ScrumMaster allow the team to determine the best solution and approach to work that makes sense for them given their collective team skills, knowledge, experience?
• Will the ScrumMaster uphold the Scrum process when things get challenging?
• Is the ScrumMaster somebody the team feels comfortable bringing impediments and bad news to help resolve?
• Is the ScrumMaster a good facilitator that will help the team get through meetings but not be a participant in those discussions?
• Does the ScrumMaster have the authority to do whatever is needed to resolve or escalate impediments the team is having?
  

If there are more No's than Yes's above, I would seriously consider looking for another person that is better suited for the role.

My thoughts:

• For me, the scrum master is dedicated to a scrum team (or at most two).... the project manager may not be.
• Project managers should focus more on resources (hiring/firing/vacations), managing dates (setting expectations), and managing risk
• Scrum masters should focus on the team, process, and impediments.
• I can envision a person doing both roles if the project is supported by only one scrum team (or two).

In my last company, we had 8 scrum teams working on 8 modules that built up to one product (and one release schedule). In this case, we had a product manager and a separate project/release manager working across those 8 scrum teams. I was the scrum master for one team. I dealt with the issues that Skip mentioned, and the project manager dealt with the scrum of scrums issues. This is one example where both roles are needed.

Some people argue different viewpoints on this topic, but I believe the answer differs greatly based on the size of the company, the alignment of scrum teams to products, and the culture of the company.

I wish I worked there...

Actually, I'm [probably] on a cruise ship in the middle of the Caribbean right now... so I'm in no position to complain. But, there are days where I ponder if it would be more fun to work a specific role for a company that is successfully agile, or to work in a company-wide Process/Project Coordinator role like my current one where I can constantly infuse agile concepts into the business in a stealth manner.

I'm undecided...

But, if I were to look for an agile company... it might be a little bit like this.