New Scrum Team Challenges

A while ago, I published a post titled: Simple Cheat Sheet to Sprint Planning Meeting.  Though I understand every team is different, I thought it would be helpful to those who are new to agile processes.  People are always looking for cheat sheets, templates, and stuff like that.  What is the harm of giving them what they want? In retrospect, I think the harm is the lack of context.  When people come to a training class, they are provided an ideal situation.  Even the Scrum Guide was written as though you've been doing Scrum for a while. It doesn't talk about things that happen leading up to your team's first Sprint.  It doesn't talk about the complexity of scaling to the enterprise.  It's just vanilla.

I just got back from coaching a new team and I'll be heading back next week to see how they are doing.  To get them moving forward, I facilitated release planning and sprint planning.  That's where things started to get interesting.  What if your team has never done release planning or sprint planning?

Release and Sprint Planning

The purpose of Release Planning is so the organization can have a roadmap that helps them reach their goals.  Because a lot of what we know emerges over time, most of what we actually know is that we don't know much.

The purpose of the Sprint Planning is for the entire team to agree to complete a set of ready top-ordered product backlog items. This agreement will define the sprint backlog and is based on the team’s velocity or capacity and the length of the sprint timebox.

You're new to Scrum.  You don't have a velocity (rate of delivery in previous sprints) and you are not sure of your capacity (how much work your team can handle at a sustainable pace).  What do you do?

The Backlog

The product backlog can address just about anything, to include new functionality, bugs, and risks. For the purpose of sprint planning, product backlog items must be small enough to be completed (developed, tested, documented) during the sprint and can be verified that they were implemented to the satisfaction of the Product Owner. 

Again, you're new to Scrum.  How do you know what small enough is?

Right Sizing Backlog Items

Product backlog items determined to be too large to be completed in a sprint, based on historical data of the team, should not be considered as sprint backlog candidates during the sprint planning meeting and should be split into smaller pieces. Remember, each story must be able to stand on its own (a vertical slice).  It should not be incomplete or process based (a horizontal slice).

Again, you're new to Scrum.  You have no historical data.

Determining Velocity

The velocity of a team is derived by summing the estimates of all completed and accepted work from the previous sprint.  By tracking team velocity over time, teams focus less on utilization and more on throughput.

If you have a new team, not only do you not have a velocity, you won't have any completed work to compare your estimates to and you won't know how many deliverables to commit to.  What do you do?  I think you just go for it!  You keep track of what you are completing and collect historical data.  You get through the sprint and establish some context for future sprints.

The first few sprints are going to be pretty rocky, until the team begins to stabilize. Just ask yourself.  WWDD?  What would Deming Do? Plan a little; Do a little; Check what you did versus what you planned to do; Act on what you discover.

FAR from accurate

This post is not specifically about FAR (Federal Acquisition Regulations).  It's about using relative grading or estimates (evaluations), before absolute grading or estimates (evaluations).  As an advisor to a source selection committee, I'm not allowed to write or talk about what is happening behind closed doors.  I can, however, write about the FAR .  Don't click away just yet!What exactly does the FAR say?

Subpart 15.303  Source Selection Responsibilities

Paragraph (b4) The source selection authority shall ensure that proposals are evaluated based solely on the factors and subfactors contained in the solicitation (10 U.S.C. 2305(b)(1) and 41 U.S.C. 253b(d)(3)).

That means is if you have 10 proposals, you are not allowed to compare them.  Based on content contained within them, you can not say one proposal is better or worse than another.  You may only grade the proposal against the solicitation, as if it was the sole submission.  So, this is where I see the problem with the FAR.  After reading Predictably Irrational, by Dan Ariely, I know humans don't think like this.  We compare things and then react (usually irrationally).  We're also pretty bad at estimating if we don't have something to use an a baseline or anchor.

The only proposal submission that will truly comply with the FAR is the first one read.  The rest of the proposals will be compared to all those read before it.  This isn't intentional.  It will happen subconsciously.  Though the FAR is attempting to be fair, I don't think that it's realistic.  If this was a scientific experiment, you would re-baseline after each test.  But the human memory is a tricky thing. You can't just reboot and clear the cache.

I've seen the same thing happen with providing task estimates.  You can spend a lot of time and money trying to get an absolute estimate.  For some projects, they require that up front. But, where there is a lot of uncertainty, relative estimating is commonly going to get you closer to where you want to be.  You many not be able to accurately predict how long it will take to complete a task but you can say if the task being estimated will be easier or harder than a similar task recently completed.  Use that as the anchor.

What I am proposing with the FAR and with estimating is provide a relative evaluation (bigger/smaller, better/worse, sm/med/lg...) based on all available information.  As more information becomes available, refine your evaluation or estimate to absolute terms (SLA1=4, Task1=Nhr(s), Task2=NDay(s)...).

If I were to change the FAR, I would require all of the proposals be reviewed once (establishing an overall baseline) and then focus my attention on the best proposals.  But, since I'll only be advising the source selection committee for two more days, I'll leave it up to the FAR.

Which do you prefer, relative or absolute estimates?

Yes, the book link is an affiliate link.

Don't be a Lumbergh

I'm plugging away on my presentation "Breaking the Law of Bureaucracy" for the upcoming Great Lakes Software Excellence Conference. Though I know I should be focusing on how to break this law, I can't help but think of the organizational bureaucracies we all deal with.  Two types of people within our organizations come to mind, the Zombies and the Bill Lumberghs (from Office Space).  Yeahhhh, you know that guy or gal.  They're heavy on style and light on substance.  They are more concerned about you having a coversheet on your TPS (Total Project Status) report than they are of refining the process so you no longer need a TPS Report or a coversheet.  He or she sits in a corner office telling you how much time you have to complete the work they have estimated and committed for you.

Yeah, I'm going to need you to come in on, ohh, Saturday. We need to play catch up. Oh, and you might as well come in on Sunday too. Thannnkkss..

Now that you know the type of person to look for, think of a way to lower the amount of bureaucracy you're dealing with every day.  I'm not suggesting you change the world.  Just look for one small change that is a pain-point or bottleneck for you, your team, or the organization.  In the case of being asked to come in on Saturday or Sunday, you're going to have to take control of who does the estimating.  If the people who are doing the work are the ones doing the estimates, there's a lower probability the estimates are going to be off and the team being over-committed.  Empower your team...and for the sake of us all, don't be a Lumbergh.

Brooks' Law

I was looking for something on the SEI website and came across a piece about Brooks' Law that caught my attention.  Brooks’ law is a principle in software development which says that “adding manpower to a late software project makes it later”. It was coined by Frederick P. Brooks, Jr. in his 1975 book The Mythical Man-Month.  You may have already experienced it but never put a name to it. I would fall under that category.  I've seen Brooks' Law happen first hand but didn't know it had a name.

The vendor was doing predictive versus adaptive planning.  They did a very poor job of estimating.  Since the customer accepted the estimate, it was just a matter of time that the house of cards would come crashing down.  As time progressed through the period of performance, we saw the vendor reach each milestone later and later. (They were following a waterfall approach)  At each status meeting the vendor was pressed for an answer to the question of how they were going to recover the schedule.   When it was painfully clear that the vendor could not complete the scope of work (within the alloted time), even if they convinced their people to work nights and weekends, they proposed to bring on more people to take care of the backlog of work.  That's right, they were going to bring on a small army with no experience with the customer, the program, or the product.  They were going to blow the budget, in the hopes to recover the schedule on the currently agreed upon scope of work.

One stakeholder was very candid when he said, during a status review

It sounds like the plan is to throw as much [something] at the wall as you can and see what sticks.

It's rather sad that the vendor looked at this as such a simple equation.

Team A (Input) + Team B (Input) = Team A + Team B (Output)

In reality, the equation looked more like this:

Team A (Input) + Team B (Input) = [(Team A * .75) + (Team B * .50)] Output

Have you seen Brooks' Law on your project?  What was the outcome?

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

Agile Traffic Analogy

The post today was brought to you by... my hellish commute and those in the Washington DC metropolitan area who help create it.  Thanks! Today, I'm going describe Agile concepts by using my commute as the analogy.

Goal

During any given day, spend as much time working or at home and as little time commuting as possible.

I'll write a User Story because I'm weird like that

As a project management advisor to a government PMO, I want to travel 55 miles in the shortest period of time so I can spend more of my life delivering value than wasting time sitting in traffic.

Predictive Approach

How long will it take to drive 55 miles to the office in the morning and 55 miles to my home in the evening?  We've all had to estimate our commute time.  Sucks, doesn't it!?  We're all terrible at estimating.  Why?  Things change...constantly!  You can spend as much time and energy as you want, trying to think of all of the possible scenarios.  You can break your commute into "chunks" and estimate those.  That could give you a better estimate, taking into account variances in each leg of the commute.  But, until you get on the road and actually start your commute, you just don't know.  We've got weather we need to deal with.  We've got that knucklehead in the far left lane, driving 10MPH under the posted speed limit (with his blinker on).  We have to deal with the occasional traffic accident.  Work on a project is no different.  You can try to estimate your time, up front, but when something happens (notice I wrote WHEN not IF) your original estimate is going to be wrong.  What are you going to do?  Are you going to try to make up the lost time later in your commute?  Is something else going to be sacrificed like hours of work or hours at home?

Do I personally think there is a more accurate way to estimate a commute, as the commute happens?  Yes.

Adaptive Approach

This was my Adaptive commute this morning.  My wife told me that the traffic report on the radio stated there was an accident 40 miles into my commute.   Good to know, I thought.  Information is good.  Communications is good.  So, did I change my estimate at that time.  Nope!  Why, you ask?  I was armed with my handy Droid X.  My Droid X has GPS and Google Maps with a traffic overlay.  Now, I still broke my commute down into chunks.  I still had the basis of estimate there.  But, the magic happened after the commute began.  I did see the traffic slow down (on the map) that my wife referred to.  But, the radio was still reporting that the lanes were blocked.  The map indicated that traffic was getting by slowly.  Good to know I thought.  Information is good.  Communications is good.  But now, I saw (on the map) that traffic was stopped much earlier and they were not saying anything on the radio traffic report.  By the way, the radio station only reports the traffic every 10 minutes.  By getting realtime feedback from the Droid, I was able to know when I was going to have take a different route, to bypass the delay. I took the next exit and my commute route and the map refreshed.  I could see, by the map, where I could get back onto my original route.  I actually arrived to the office, 20 minutes from my optimum commute time.  If I had not had the Droid and the constant feedback about the traffic conditions, it would have added a hour.

I still lost 20 minutes.  But that was unavoidable.  But I think I minimized my delays by getting real-time feedback.  I had opportunities to adjust my course based on information.  I was able to adjust my commute estimate every minute, not every 10 or 20 minutes.  If someone from the PMO had called me to ask when I was going to get to the office, at any time along my commute, I could have given them a pretty good estimate.  But that telephone call isn't necessary.  Here comes the kicker.  I share my location with Google Latitude.  They can see where I am at any time.

Here are some things to think about for your next commute

• Know where you are and where you want to go
• Break your commute into chucks
• Get traffic conditions as often as possible
• Be prepared to change direction
• Be prepared to reestimate your time of arrival, the closer you get to your destination
• Give people a way to know your location so they don't have to ask you every 5 minutes
• Feedback is good
• Information is good
• Communications is good

Like the image? Find them at Pictofigo

Zombie Estimating Techniques

Since we all know zombies don't count, we're going to assume you are the poor sap trying to get away from said zombies.  But what are your chances of survival?  Do you have enough ammo? Let's assume your survival is the project.   Since a project is a temporary endeavor, we'll go with that.  Our goal is not necessarily to create a unique project, service, or result, unless you count killing zombies.

How big is that unthinking horde or zombies slowly making its way toward you?

Do you have enough ammunition to kill them all, before they get to you?

Now, I don't know about you, but my estimating skills suck.  We're in trouble unless the unit of measure are digits on my body or comparing something to the size of my coffee cup.  But that's ok. We have bigger things to worry about. I mean, we do have a horde of flesh eating zombies coming after us. So, let's talk about two simple estimating techniques, hours and story points.  In this post, I am not going to tackle what I would define as advanced estimating techniques. I'm just going to limit it to the two below.

Technique 1: Hours

OK, who here hasn't estimated in hours?  Though this doesn't necessarily translate to zombies, it does to software development and other project activities.  Break efforts down in the smallest group possible, like tasks or user stories.  This technique is good but I think you need to really have a grasp of what you're up against in order for it to be effective.  If you provide an estimate on an Epic or WBS Level 1 item, it loses its effectiveness.  Try to decompose (not like zombie decompose) work if it exceeds 8 hours.  The more time that elapses on a given task, the higher the probability something is going to change.  Get it completed and delivered so you can base your next estimation on something you've already done.

Please don't estimate for other people.  Only provide estimates on things you're going to do.

Technique 2: Story Points

Rather than estimating in hours, story points help people get past the uncomfortable feeling of saying they'll complete something in X hours.  Sure, a story point could equal 1 hour but it doesn't have to.  Think of estimating work at a relative amount compared to other work.

Imagine  two groups of the undead are lumbering toward you.  I'll say group one is worth 8 points in size and complexity.  It takes you 20 rounds of ammo to take them out.  Though you didn't get a head count, you'll say the second group is 13 points in size and complexity.  If you only have 20 rounds of ammo left, how does that make you feel right now?  Do you run like hell in the opposite direction or do you think you learned something in the last round?

Once again, please don't estimate for other people.  Only provide estimates on zombies you're going to shoot.

Are you starting to see the parallels?

Like the image?  Find it at Pictofigo

Expert Judgment and Passing the Sniff Test

Looking for two very informative posts on estimating?  Check out one by Josh Nankivel of pmStudent and Glen Alleman of Herding Cats.  Both are discussing estimating techniques that work for them. I wanted to take a moment to add my two cents. Though I certainly believe estimating should be more science than art, I look at estimates from a different perspective. As a disclosure, I'm not the one doing the estimating on this project, therefore I'm not going to say I agree or disagree with any one technique.  Depending on your situation, one estimating technique may provide more accurate results than the other.

What I would like to add, from my perspective, is the need for expert judgment. If you are an expert in a given estimating technique and it gives you the results you and your customer(s) need, does that not validate it as an acceptable estimating choice?

If the estimating technique does not produce the desired results, wouldn't it fail the metaphorical sniff test?

Recently, I questioned a vendor's estimate based on a different technique.  I used a parametric estimate to see if the vendor's estimate would pass or fail my sniff test.

What exactly is a parametric estimate?

An estimating technique that uses a statistical relationship between historical data and other variables to calculate an estimate for activity parameters, such as scope, cost, budget, and duration.  Source: PMBOK Page 439

So, why did the vendor's estimate not pass my sniff test?  As part of a standard estimating practice, software vendors should include time for fixing bugs. Upon review of a recent status report, I noticed the vendor reporting half as many bugs were discovered in a current build than had been estimated. When asked about this, the vendor was very excited to confirm that they indeed found half as many defects in the code they originally estimated and predicted a cost savings of several hundred thousand dollars to the project.  Going into the current build, I knew what the standard deviation was and considered the possible variance.  This fell way below that.

So, why were they discovering so few bugs?  At first glance, I would predict two possible reasons.  [1] Quality through development improved.  [2] Quality through testing worsened.  Either way, you get the same initial result of fewer defects identified.

We'll know the true answer once initial user acceptance testing begins.  If there were no baselines to compare the actuals to, I might not have given it a second thought.

Graphic source via Flickr: pump