Definition Archive

1

Ready and Done

Are we ready?When leading development teams, I see most of the wasted activities happen during the development phase.  If work is not ready, before the team begins development, there can be delays waiting for clarifications from the business.  If acceptance criteria is not clearly defined, before the team begins development, work can go on and on trying to appease the customer.  What your team needs is a clear definition of “Ready to Work” and a clear definition of “Done with Work”.  Though definitions vary from team to team and organization to organization, it’s imperative that you do it.  It’s also imperative the team writes the definitions, not someone in an ivory tower.

As with all of our clients, I stress the need to have a minimal agreement on both definitions before work is started.  When defining both the entrance and exit criteria, all major parties within the team need to be involved, to lower risks that something will be missed.

Below are examples of the definitions or ready and done.  Notice that we consulted Analysts, Testers, and Developers.  For your team or organization, you may consult UX designers, DBAs, Architects or others.  Don’t make your definitions overly onerous.  Just create something that is just good enough and go from there.

Example of a Definition of Ready

  • Analyst – User story sufficiently defined and mapped from requirements
  • Tester – Acceptance criteria developed
  • Developer – User story is estimated and no known blocking dependencies exist within the sprint

Example of a Definition of Done

  • Analyst – Working system reviewed and User Story accepted via Automated Test or Manual Inspection
  • Tester – Test cases pass.  All critical and high severity bugs fixed and other bugs identified and tracked
  • Developer – Deployed to test environment and Code Review complete

So, what does your team require as part of your definition of ready or done? Do you have definitions?

As a side note, if you’re preparing for the PMI-ACP exam, remember the team is responsible for the definition of done.

Image Sources: Pictofigo

2

Hawthorne Effect

The Hawthorne Effect is something I’ve seen numerousness times on projects.  When auditing or introducing a new process, do you tend to see people doing a better job than you expected? The Hawthorne Effect refers to the tendency of some people to work harder and perform better when they are participants in an experiment. Individuals may change their behavior due to the attention they are receiving from researchers, auditors, or coaches.

hawthorne effectThis effect was first discovered and named by researchers at Harvard University who were studying the relationship between productivity and work environment. Researchers conducted these experiments at the Hawthorne Works plant of Western Electric. The study was originally commissioned to determine if increasing or decreasing the amount of light workers received increased or decreased worker productivity. The researchers found that productivity temporarily increased, regardless if the light was increased or decreases. They then realized the increase in productivity was due to the attention given the workers by the research team and not because of changes to the experimental variable.

Do you audit your processes?  How do you ensure you get a true representation of project efficiencies and not suffer from the Hawthorne Effect?

HT: Wikipedia

Like the drawing? Get it at Pictofigo

3

Parkinson’s Law

When I was growing up, I was told the bigger the goldfish bowl, the bigger a goldfish would grow.  Keep the bowl small if you want to limit the goldfish size.  Thinking back, it’s a pretty good metaphor for my understanding of Parkinson’s Law.  The saying “Parkinson’s Law” was first coined by Cyril Northcote Parkinson in his essay published in the Economist way back in 1955.

Work expands so as to fill the time available for its completion

This is what I see happening when developers or others have not decomposed their work to small enough chunks, in order to properly estimate their work.  The same goes with meetings if people don’t stick to an agenda.

Yesterday, I saw a (vendor’s) manager trying to break the Parkinson’s Law.  Granted, I shook my head at his proposal but I admire the fact that he knows there is a problem and is trying to do something to correct it.

This manager has provided a (non-resource-loaded) schedule that has activities planned to conclude on September 30.  The customer is not happy because new work of higher priority has appeared since the vendor provided their 5,000 lined schedule, several months ago.  The customer does not have more money it can commit to new scope and they are unwilling to drop scope from the existing timeline.  Yes, we all know customers do this.  So, what was the vendor’s proposed solution?  Going forward, all estimates of work (previously identified and baselined in the schedule) will now have 10% less time to complete. Since they never allocated any slack for activities in their existing schedule, this will become their schedule reserve. Don’t ask me where they got 10%.  Tada!  Now they have time to complete more work.  Oh wait, you mean they shouldn’t use schedule reserve in that way? No, they should not! And they shouldn’t look at management reserve in that way either.  I know some out there are going to have a heyday with this.  It’s not up to me.

I have to say, the vendor has done a very poor job with their predictive planning.  But who is to blame them?  It’s not easy!  I’ve found adaptive planning to be much more accurate. That 5,000 line schedule was out of date the day it was published.  When I first looked at their estimates and later at their schedule, I new the efforts were grossly over-estimated.  But, both the estimates and schedule were accepted by the customer.  I do think the customer will now get more value for their money.

I got a kick out of the manager’s response when someone in the meeting challenged him on the probability of people being able to complete the work in less time.  Though I’m paraprasing, his response was

It’s surprising, if I tell people to have their work finished by Friday COB instead of Monday COB, somehow they just seem to get it done.

That is a clear indicator that people on his team did not do their own estimates and the original estimates were more on the level of a rough order of magnitude (ROM).  If it was my team, and I had made the same proposal, I would have had a revolt on my hands.  The difference here is my team estimates their own work, within a few weeks of actually doing the work, and we ensure the work is in small enough chunks that the customer can see something of value in a very short period of time.

What kind of goldfish are you?

  1. Small goldfish in a small bowl? (small group, small timebox, small deliverable)
  2. Small goldfish in a big bowl? (small group, big timebox, big deliverables)
  3. Big goldfish in a big bowl? (big group, big timebox, big deliverable)
  4. Big goldfish in a small bowl? (big group, small timebox, big deliverables)

 

Image: PPT Presentations

2

The Story of Monte Carlo

Monte CarloOnce upon a weekday meeting, I had a story to tell.  It was the tale of a project manager, who’s name really rings a bell.

He quantified the total project cost, he didn’t miss a dime. He also computed the schedule, he was always aware of the time.

He used all these input values, with random amounts being his friend. He ran these simulations.  I thought they would never end.

The outcome was a distribution, a bell curve if you like.  On the edges we saw some low points, in the middle there was a spike.

Monte Carlo was this fellow’s name, he was a heck of a numbers guy.  We asked him if he ever made things up.  He said he would merely quantify.

Now don’t think Monte worked alone, he had a counterpart.  Her name was Jane Stake-Holder, he worked with her from the start.

Jane could be quite demanding, sometimes ignoring project scope.  But Monte managed the situation well, knowing creep was a slippery slope.

His technique was well documented, a change would make everything slip.  He told this to Jane Stake-Holder who you’d think would do a back-flip.

But numbers don’t lie and neither did he, Jane knew Monte would put up a fight.  She backed down and submitted a change request, the schedule would extend to the right.

Graphic: Pictofigo

2

Why You Should Use Common PM Language

I don’t normally drink coffee from Starbucks but someone gave me a gift card.  I like black coffee, with no cream or sugar.  I like my coffee fresh so I order a small size.  So, why on Earth did the person behind the counter not listen to me?

I ordered a small Caffè Americano. For those who do not drink coffee, that’s nothing more than a small espresso and water.  My expectation was I would get a small cup of coffee.  When I looked at my receipt it said Tall.  I brought this to their attention and I was dismissed.  “Oh, it’s the same thing.”

Well, no, it’s not.  Line up the cups and this is what you will see.  Extra-Small, Small, Medium, Large, and Extra-Large.  What does Starbucks call them? Tiny, Small, Tall, Grande, Venti. So, what I got was a medium.  I’m not going to split hairs here.  I’m trying to make a point.  There needs to be a common understanding between the vendor and the customer when you both define the same thing differently.  This is a financial transaction.  I want what I paid for.

How does this apply to Project Management?  From the customer’s perspective, what is the definition of done.  From the vendor’s perspective, what is the definition?  From every stakeholder perspective, do you all have the same definition of done?  You should!

It’s important to note, it doesn’t matter which approach you use.  Waterfall, RUP, Agile, or Kanban.  Everyone needs to understand and agree to what done means.