C-3P0 Timebox

My family and I recently went to Walt Disney World’s Magic Kingdom and Hollywood Studios. My wife was extra excited because it was going to be "Star Wars" weekend at Hollywood Studios while we were there. Imagine parades filled with Star Wars characters, Storm Troopers and Clone Troopers everywhere...and the force being with us (or maybe not). My wife was very excited when she found out she had a chance to get a picture taken with and get an autograph from Anthony Daniels of C-3PO fame. This is how it was to go down. When the park opened, a predefined amount of tickets would be given to those people standing in a line. Once those tickets were gone, there were 30 remaining "standby" tickets. There would be two autograph sessions, lasting one hour each. IF Mr. Daniels got through the "guaranteed" group of ticket holders in less than one hour, he would then start to greet the standby ticket holders in the order in which they arrived that morning. We were standby ticket holders #19, #20, and #21 (out of 30). Everyone was required to stand outside in the sun until their ticket number was called. They were then allowed into an air conditioned building to meet C-3PO. When they were done, the "beaming" fan exited the building.

Well, the morning session (in close to 90 degree heat) came and went. The first 10 or so standby ticket holders did get in. We were told to return in the afternoon. Upon returning in the afternoon, the guaranteed group came and went and as we watched the clock tick closer and closer to the one hour mark, they accepted standby after standby. We had convinced ourselves that certainly Mr. Daniels would understand that there were only a few people left in line and would stay the extra 5-10 minutes it would take to greet us and sign a quick autograph. Unfortunately, after #17, a representative walked outside and told us that Mr. Daniels had to leave for another scheduled engagement.

At first, I was pretty pissed. Seriously? He couldn't accept just a few more people and get through 100% off ALL of the people standing in line? No, later I thought about it. He had a timebox. He had exactly two one-hour sessions. He was going to get through as many autographs as he could but he still had to leave after one hour, regardless. He agreed to sign a specific amount of autographs and he met that commitment... and he exceeded it.

Have you had that situation happen to you as either a ScrumMaster, Project Manager, or Stakeholder? As a stakeholder you feel ripped off because someone else got something delivered and you didn't. As a ScrumMaster, you have to allow the team to commit to do the work. You can't force work upon them. As a Project Manager, you have to explain to everyone that if you let the time constraint slip, you would be asked to do that every time there was a commitment. You've heard it before. Please, just one more thing. Please, just one more day.

Mr. Daniels, you did the right thing. You kept your commitment. If that gig as protocol droid doesn't work out for you, I'd hire you.

Teaching Agile to a 5-Yr-Old

If you ever thought it was too early to teach your children Agile terminology or good management/leadership skills, you can stop now.  I wanted to teach our 5-year-old son a few new concepts.  If you can teach a 5-year-old, you should be able to teach a 45-year-old....right?  Well, let's not get ahead of ourselves.  I actually think kids grasp these concepts better than adults.  They don't have years of baggage to contend with. Now, let me preface the bulk of my post by saying, that at age 5, I could not read at all!  I think our son's teacher has done an amazing job of getting the kids in her classroom reading at the level they do.

So, what is our goal?  Our son's Kindergarten teacher sent home a "by the minute reading log".  She identified how many minutes of reading she wanted each student to read in a month.  For February, the target was 50 minutes.  At first, our son acted very overwhelmed.

Oh Daddy, 50 minutes is SO much!

I assured him, he had a whole month to get there.  Let's call this month a timebox.  In the timebox, the teacher wants you to finish as many stories as you can in the time given.  That's it!  Now, some stories are going to be harder than others.  But, let's focus on doing a little bit at a time and getting each story done.

To really understand the complexity of these stories, they were written for a 5-year-old.  They only take about 5 minutes to read.  So, each story will equal 5 minutes.  To make it fun, let's use story points instead of minutes!

story_velocity2

The last concept I wanted him to grasp was velocity.  Velocity is the number of story points we can get in the timebox.  Just know, you don't get credit if you don't finish a story!

feb_reading_log

If you look at the "reading log" image, you'll see our actual total velocity was 120.  The stakeholder in all of this, his Kindergarten teacher, would be happy if our velocity was a mere 50.

What was really exciting was telling our son, by the end of week 2, that he had met his goal.  If the stakeholder is satisfied with the 50 point velocity, I think we will start having a FedEx Day once a week.  Just like my teams, I don't want to burn him out.  We need to find a balance and a stable velocity everyone can be happy with.

Imagine if this was you and your team.

Understanding Agile Scrum and common terms

I've been in a few meetings this last week where people were mentioning Scrum terms but didn't know what they were. It's not their fault. The person introducing the terms into the project vocabulary should have provided an explanation before referencing them.

For those of you new to Agile Scrum, here are a few basics:

What is Agile Scrum? There are many specific agile development methods. Most promote development iterations, teamwork, collaboration, and process adaptability throughout the lifecycle of the project.  Agile methods choose to do things in small increments with minimal planning, rather than long-term detailed planning.  There is a heavy emphasis on face-to-face communication over written communication.

Agile Scrum is not ideal for every project.  If the project has high criticality, is using junior developers, has clearly established requirements that do not change often, employs a large number of developers, you should think twice about using it as your method of choice.

I've seen it work very well with small (5-9 member) teams, where all the stakeholder knew they wanted "something" within a short period of time.  They did not know specifically what it was nor how to get from start to finish.  We used a lot of wireframes and prototypes to get us in the ballpark, until we could lock down clear functional and design requirements.

I think it's important for people to understand key terms in Agile Scrum as they relate to other project management methodologies.

Roles

Product Owner The person responsible for maintaining the Product Backlog by representing the interests of the stakeholders.  This owner could be a project manager, director...  Whatever their title, they must have the authority to make decisions on behalf of the project.

ScrumMaster The person responsible for the Scrum process, making sure it is used correctly and maximizes its benefits.  This is NOT a project manager.  This person is a facilitator.  They are merely there as a communications bridge and to offer motivation or remove impediments.

Team A cross-functional group of people responsible for managing itself to develop the product.  This is a small team (5-9) consisting of at least one person from each area (BA, QA, Risk, CM, Software Engineering...)  This team traditionally sits in the same room or area.

Scrum Team Product Owner, ScrumMaster and Team.  Everyone directly involved in the project, with the exception of users, stakeholders, and managers.

Artifacts

Sprint burn down chart Daily progress for a Sprint over the sprint's duration.  This chart can replace a Gantt chart in illustration of progress.

Product backlog A prioritized list of high level deliverables assigned to teams.  This list is similar to milestone deliveries you'd find in a Work Breakdown Structure.  These deliverables will still need to be decomposed (in the sprint backlog).

Sprint backlog A list of tasks to be completed during the sprint and assigned to individuals.  These are the actual decomposed items from the product backlog.  This list must be agreed to by the entire team prior to the sprint actually beginning.  If there is a change in the scope of the sprint backlog during a sprint, the sprint must be immediately stopped and scope redefined.

Other

Sprint A time period (typically between 2 weeks and 1 month) in which development occurs on a set of backlog items that the Team has committed to.  Sprint time periods are established to provide enough time to deliver something, get feedback, and begin another iteration.

Product An output requested by the customer.  It is a completed document, process, web page, database...  Regardless of what it is, the customer believes that it has value.

Other terms to be listed in a later post: Sashimi, timebox, daily scrum, chickens, pigs, retrospective, user stories...