New Scrum Team Challenges

Velocity ChartA 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..

Bill Lumburgh and the Bobs 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