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.

Agile on Non-Software Projects

Regardless of where I coach or teach, there is always someone who approaches me and says something like, "Agile is great for software projects but what about projects that aren't software related?"  When asked the question, I usually give examples like a U.S. Marine fire team or air crew or a home construction site. (I'll save those stories for another time).  I now have a new story to tell about a cross-functional, highly collaborative team, which competed for the Progressive Insurance Automotive X Prize. While I was at Agile 2012, I met Joe Justice of Team WIKISPEED and had a chance to actually touch a car that was designed and built using Agile methods. (see cool photo enclosed)

Here is some back story from a 2011 press release:   Based in Seattle and led by Joe Justice, WIKISPEED is a collaborative team of over 50 experts and volunteers dedicated to offering ultra-efficient, ultra low-cost, mass-production road-legal vehicles. In 2010 the team's SGT01 prototype placed in the top 10 in their class out of 136 cars overall in the Progressive Insurance Automotive X Prize.

Joe was able to build his first functional prototype in just three months.  The car that competed in the X Prize got 114 MPG (Highway). Compare that to the Toyota Prius which currently gets 51 MPG (Highway) and was introduced in 1995.  The reason auto manufacturers are so slow to "better" their products is because change is very expensive for them.  It is not uncommon for auto manufacturers to operate on 10 to 25 year development cycles.  Before Object-oriented programming methods were introduced, software teams used to operate much the same way.

By modularizing how we build software, we're able to shorten our development cycles down to days.  By shortening our development cycles down to days, we give ourselves the opportunity to get feedback from our customers and create things that they really want, not things that we think they want.  We save ourselves and our organizations countless dollars in wasted development, due to waiting too long to get feedback from our customers or by operating in functional silos.  My breaking our teams down into small, cross-functional, empowered teams, we shorted feedback cycles as much as we can.

Being Joe is a client facing software consultant, building Agile teams and practices, why would he limit the benefits of Agile to just his customers?  Joe and his team have a car that has a development cycle of seven days.  They do this by modularizing the car.  They can switch the gasoline engine to an electric one in about the same time it takes to change a tire. They could change the car body from a convertible to a pickup truck.  All of this allows them to make changes and develop quickly.

The car is safe (passes road safety standards), because Team WIKISPEED developed safety tests before building the actual parts.  This helps them lower waste (Lean).  Next time you say you can't afford to do test-driven development, think about that.  They do all of their work in pairs, avoiding time training that is not productive. (XP Practices) Again, the next time you say you cannot afford to pair people, think about that.  Pairing also helps lower the need for most types of documentation.  If everyone has a shared understanding, you have less need for it.  They visualize their workflow to help identify hidden delays and deliver something every seven days (Scrum).

So, do you still think Agile is only for software projects?  The fact that they use 7 days sprints on hardware, when I hear people say they can't do anything less than 30-days on software, just goes to show you where there is the will there is a way.

Check out Joe's session from TEDxRainier

Post originally appeared at LeadingAgile

Chasing After The Latest Fad or Evolving

This last weekend, I had an interesting exchange on the PMIWDC LinkedIn Group discussions board.  This healthy exchange of viewpoints came about from the following message:

In June, PMPs numbers are down by over 4000 while the PMI Agile certification numbers are on a steady rise. What is preventing the ACP from really getting traction?  http://ow.ly/i/NRLD [link to graphic showing the upward trend of the PMI-ACP]

Because that LinkedIn group is not public, I won't include the persons name.  Rather, I will refer to him as "Mr. PMP, CSM, ITIL" and include his responses in red.  Even if I don't agree with everything he writes, I have to respect a differing viewpoint.

PMP numbers likely vary slightly throughout the year and 4,000 is less than 1%. Plus, in the current economy, I don't think a drop is surprising at all.

Now about PMI-ACP. In my opinion, the PMI-ACP has no market (no one asks for it and, as you note, no one is really seeking it even after PMI lowered qualifying standards to get it). It is simply a me-too certificate competing with already established certifications by Scrum.org and ScrumAlliance.org. Besides, it is mislabeled as Agile when all it talks about is Scrum without ever using the word Scrum--making it even less distinguishable.

Personally, I'd rather see PMI focus its efforts on strengthening the PMP, and the overall body of project management knowledge and practice, than chasing after the latest fads.

[Mr. PMP, CSM, ITIL], interesting opinions. I always find these "corrections" compelling. Everyone can read the August edition of PMI Today (the source of my numbers) and draw their own conclusions. It could be there were 4000 people who really weren't project managers in the first place, thinking they needed a PMP, and then realized they really did not. We'll never know for sure.

As for the PMI-ACP, the qualifying standards were corrected while the certification was still in pilot. I know this because I was in Miami with PMI when it happened. It just took several months to get the change implemented in the application process. At least there is a qualifying standard. You and I both have a CSM, yet we both know there is no qualifying standard for that.

The PMI-ACP is not all about Scrum. Again, I know this because I helped create the ACP and because I am the Co-Lead of the ACP support team at the PMI Agile CoP. I won't disagree that a large percentage of the ACP is Scrum related but in VersionOne's latest State of Agile survey, a majority of Agile practitioners are using Scrum to deliver value to their respective organizations. I think the certification is pretty representative of contemporary Agile practices.

If you'd rather PMI focus its efforts on strengthening the PMP, I'm curious how you will feel about the upcoming PMBOK Guide revision and Software Extension. Both include Agile knowledge and practices. Does that mean PMI is chasing after the latest fad or is it evolving?

Derek, I'll admit the 5th edition draft PMBOK is troubling--almost as if some folks are trying to sabotage the PMBOK or simply making changes for the sake of changes. Don't get me wrong, I am not against change but some of what is occuring is not good, doesn't fix some problems in the 4th Edition and introduces some new contradictions and confusion. Waiting to see what the final release settles on. 

Stats can be fun and too often misleading. I don't think month-to-month changes in active certificate holders is very meaningful and PMI-ACP's less than six month track record is nonetheless too short. It's 7 to 18% month-to-month increases are already faltering, losing 32% of it's growth rate in the latest month. During this same time, PMPs dropped just under 1%. If both of these two latest trends continue, PMI-ACP will max out around 6,923 and reach parity (with current month declining) PMP in just over 38 years. 

As a reality check, PMP and CAPM make up 99.2031% of PMI's certificate holders. I suspect the overall number of 'traditional' projects is a not too dissimilar ratio. Adding in the few thousand CSM and other certificate holders won't significantly shift this ratio. And traditional project management is, if practiced well, agile and not the caricature painted by Agile and Scrum advocates.

Listening to people who are participating in the PMBOK revisions sounds a lot like legislation in the government. In the beginning, a bill with a bold new idea or fix is presented. In order to close the deal, the bill gets watered down and new stuff that really has nothing to do with the original bill gets introduced. I can totally see that happening with the PMBOK. But I do think common agile concepts and practices should be included. The question is, will it be a square peg in a round whole, based on the format of the PMBOK?

Speaking to the certification stats, I once presented a correlation graph claiming an increase in ice cream sales caused deaths by drowning. It was merely illustrating that metrics can be used to support just about any claim. If PMI gets more market penetration in India and South America, I think the overall growth rate for the PMP (and ACP) will continue. With PMI being the marketing machine that it is, I see the ACP cannibalizing market share from ScrumAlliance and Scrum.org, not from the PMP.  Only time will tell.

It's my belief that "Agile" practices will be accepted as "Traditional" practices over time. Until then, the misinformed will believe it is a silver bullet. It's funny, when I coach new clients, I always have at least one project manager tell me that he or she proposed similar changes to leadership but was ignored. I've also had attendees of my training tell me that having PMI offer an "Agile" certification legitimizes it as a possible delivery mechanism. This isn't new stuff! Whatever gets people talking works for me.

HT: Project Management Institute

HT: VersionOne

What is Agile, anyway?

The parable

Ever heard the story about the blind men and an elephant?  In various versions of the tale, a group of blind men touch an elephant. Each man feels a different part, but only one part, such as the leg, the tail, or the trunk.  They then compare notes and learn that they are in complete disagreement.

Agile, my friends, is an elephant.

The first blind man

I just completed an initial engagement with a client, for LitheSpeed.  Some of the people I interacted with were newly minted Certified ScrumMasters, some experienced developers, and some executive management.  In the mix, I met UX designers, architects, and more functional roles than this blog post should list.  The catalyst of this post happened on the first day of the engagement.  To set the stage, the organization was very clear the team is to "do" Scrum.  Due to user stories not being quite ready, the team pushed back at Sprint Planning and refused to estimate or commit to the work to be done.  I recommended the group visualize the workflow and maturation of user stories by way of a Kanban. I've made this recommendation before and it worked out quite well.  The response from one of the newly minted ScrumMasters was, "That sounds like waterfall!"  When I corrected him, confirming that it was not a waterfall approach,  he came back with an even better response.  "Well, it's not Scrum.  If it's not Scrum, it's not Agile".

If it's not Scrum, it's not Agile

A few days ago, I read a really great post by Joel Bancroft-Connors titled A Gorilla Primer: What the heck is Agile? Maybe this question is more common than I initially thought!  What I liked about Joel's post was it exposed the fact that Agile is different for so many people.  When asked what Agile is, I tend answer the question with a question.  Are you being Agile or doing Agile?  If you are being Agile, then how?  If you are doing Agile, then how?  Before I even attempt to answer the question, I want to know your perspective.  Why?  Because as with the parable and also reality, it's going to depend on your touch points.

Go read Joel's post.  I think you'll enjoy it.  When you're done, I'm sure you'll agree that if it's not Scrum, it can still be Agile.

Image Source: Pictofigo (Go get one. They're free)

Epics, User Stories and Tasks

I was working with a client this last week and I overheard one team member trying to explain the difference between Epics, User Stories, and Tasks.  He finally offered an analogy.

The Analogy

Epics are to User Stories are to Tasks as Rocks are to Pebbles are to Sand.

I thought it was a clever description of comparing relative size and complexity of work. But would it pass muster with the Agile Community? I figured I would send it out to the Twitter-verse and see if any conversations would result.

The result was an excellent conversation with David Koontz.

The Conversation

Though I will admit there are some challenges in communicating in 140 characters or less, it really forced me to think about what I was trying to say.  David did a really great job of challenging me to explain what I was thinking.  In tweet responses, David stated if it can fit in a Sprint, he calls it a User Story.  If it is too big to fit in a Sprint, it is called an Epic.  I have to say, if we all followed that model, it certainly would simplify things.

I find customers asking if they can call them sub-stories, major stories, and craziness like that. Customers take a stab at breaking down work to manageable chunks but when the team estimates the work, it's still too big to fit into a sprint.  To restate David's identifying criteria, too big equals epic; small enough equals user story.

David then asked me,

does Epic == collection of stories? Or some stories and some waste we should never do?

My response was,

I believe epic != collection of stories. I believe epic == placeholder of a goal or idea. Stories may result but no guarantee

The Clarification

To clarify my beliefs, I believe a User Story as merely a placeholder for a conversation.  I believe an Epic is a placeholder for a goal or an idea.  Along the way, there will be resulting value delivered and waste.

Though you should be able to map all of your User Stories (and waste) back to Epics, that's not the goal.  You don't just do tasks and then look for a bucket of stories or epics to group your efforts.

I won't say having something small enough to fit in a Sprint is automatically called a User Story.  What if you don't leverage Scrum?  What if you are leveraging Kanban?  In either case, we refer back to the conversations.  As long as your work meets your definition of Ready, I don't care what you call it.

Thank you, David, for an excellent conversation.  I hope others will join in.

Protective Collaboration

I was recently asked my opinion about collaboration within an organization.  Being I just completed an organizational assessment for a client, I have a fresh perspective of the topic. I was specifically asked:

"Is it healthy for Scrum teams to work in a bubble protected from the business around them? Should collaboration go beyond the team?"

There are two common threads that I see time and time again. One, what is the goal? Two, is that goal communicated?  Until these two threads are tied together, you can't have good collaboration.  I don't see this being unique to the world of Scrum.  To help illustrate my point, I'll try to use terms people outside the Scrum community can understand.

Strategic Mission (Goals)

Executive Leadership, in order to lead, needs to communicate the strategic vision of the organization.  Strategic vision translates into strategic mission or long-term goals. Strategic mission should be understood by the entire organization.  If you don't know the mission, how will you be able to help the organization reach its goals?  From there, the leadership needs to empower people tasked to do the work to figure out how they will accomplish the goals.

Tactical Mission (Goals)

This is where you keep lines of communication open but insert a protective buffer.  If you're leveraging Scrum, that first buffer is called a Product Owner.  This person understands the strategic mission of the organization and is able to translate it into tactical mission.  You could also refer to this person as an organizational liaison.  This person or group of people don't need to know all of the answers.  But, they do need to be readily available to answer questions from the team and to reach out to the appropriation organizational subject matter expert(s) when necessary.  The second buffer, when leveraging Scrum, is called the ScrumMaster.  If not leveraging Scrum, they could also be known as a process manager.  This person understands organizational process on a team level and is there to ensure the team consistently follows that process.  They also work to keep those who do not aid in tactical execution from derailing the team from getting work down.

Collaborative Team

It's time for me to answer the first direct question. Is it healthy for Scrum teams to work in a bubble protected from the business around them?  Though I do believe the team should be protected from the business directly trying to change their tactical priorities, you should never operate in a vacuum. If people from within the organization do try to change team short-term priorities, the process manager (ScrumMaster) should be right there to impress upon them the needs of the organization and to respect the agreed upon processes.

Collaborative Organization

The second question was, should collaboration go beyond the team? My short answer is, yes.  Communications is different from collaboration and it needs to flow up and down the organization.  With information flowing freely, I've seen good (strategic) ideas become bad ideas overnight.  All it might take is one executive standing in the back of the room during a daily (stand-up) meeting.  Once the appropriate information is presented to the appropriate people, real collaboration can take place.  The entire organization, which includes all cost and profit centers, needs to collaborate to discover the best solutions and work toward common goals.

What do you think?

Did I miss anything?

Jazz Hands at the Daily Standup

While doing an Agile assessment in Des Moines, Iowa, we noticed a team would periodically do "jazz hands".  When we asked the ScrumMaster (Iteration Manager) what was going on, she said others within earshot of the daily standup complained about the team being too loud. In the past, whenever there was good news, the team would cheer and clap.  As a result, in order to continue to show their excitement, the team members now all do "jazz hands". Team "Seniom Sed" (Des Moines backwards), it has been a pleasure watching you all work for the last few days. Actually, it's been a pleasure working with each of the teams. I get one more day to enjoy your addictive enthusiasm.

Keep up the great work!

Theme Park Pull System

If you've been to a theme park like Disney World's Magic Kingdom or Hollywood Studios, you will quickly notice the lines.  Depending on the time of year (or day) the line to a ride or attraction could be anywhere from nonexistent to 90+ minutes long.  As you approach an entrance, you'll see a line marked on the grounds and a sign that reads "N minutes from this point". You want the sign to read 5 minutes.  That's the time it takes, with no wait line, to get to the actual attraction.  What you don't see from the line on the ground is the maze of lines snaking their way through the building.  If the volume of people is low, everything except the direct line to the attraction is roped off.  The more the people, the more "side" lines are open.  The line outside the attractions are deceasing.  The real delays start after you cross that line marked on the ground and are committed. I noticed that attractions usually lasted less than 5 minutes and people were divided into groups, just prior to onboarding some kind of transportation.  The transportation ran at a consistent rate of speed.  All these factors included, Disney World has to know the maximum throughput of a ride, before the line starts to back up. Why do you ask?  Well, to keep the customer happy by keeping them moving, of course.

When I saw all of this happening, I thought it was an excellent example of a pull system.  We went on a ride called "Star Tours".  The vehicle capacity was 40 people and the ride duration was 4:30 minutes.  We noticed the sign said 90 minutes from this point.  Can you imagine doing that with a 5-year-old?

Star Tours Capacity=40 people per load Lead Time=90:00 minutes Actual Duration=4:30 minutes

So, what does Disney do to help resolve the issue?  They call it the Fast Pass.  Yes, the golden ticket.  When you see the line at its worst, go up to a kiosk and get a Fast Pass.  It will tell you to return to the ride at a designated time.  In exchange for doing that, it will allow you to go to the head of the line, when that time comes.  I am assuming they are having you return at a predicted time of day in which the line will be shorter.  Regardless, it eliminated the bottleneck for us.  Whenever we saw a hellish line, we got a Fast Pass and came back later in the day.

To prevent the Fast Pass people from completely stopping the line, it appeared a certain percentage of seats per load were allocated for Fast Pass ticket holders.

I think this Fast Pass option may also work with non-theme park customers.  Let's say you are working on an application development project.  After you have an optimum cycle time, if you reserve a little capacity, you could potentially negotiate with a stakeholder to postpone an activity to a date or time in which you know the workload will be less.  I'm not saying you are postponing adding the work to your backlog.  It's still there.  But, you could agree to make it a lower priority until more of the backlog gets completed.  This could keep the rest of the work moving at an optimum pace and keep the customer happy.

Drawing by Pictofigo