Value Stream for Business Travelers

The more I travel, the more I find myself observing how business travel (particularly flying) is a lot like application development. Process the flow of travelers (business value) through a system much like ideas flow from inception to delivery.  When reviewing the processes of  the business traveler (delivery), I keep asking myself why the system has so much room for improvement and why we as participants within it don't fix it.  I notice many travelers do few things that provide direct value (save time).  Rather, we do things that either provide little or no value but are necessary or are just wasteful.

As a business traveler, I want to arrive to a destination as quickly as possible without violating identified constraints.

Constraints: Quality and Cost 

Quality (safety thresholds):

We want to make sure that some knucklehead does not get on a plane and do something destructive.  Rather than quality, the FAA calls this security.  In the end, the underwear bomber who unsuccessfully detonated his skivvies mid-flight is like discovering a severity one bug in Production.  It would have been a lot cheaper, if this guy was stopped at a security checkpoint and prevented from getting on the plane in the first place.  As a result, I have Bubba the TSA Agent measuring me for a pair of pants every time I opt out the body scan. Do these theatrics actually increase quality?  I'm not sure. But I digress. [TSA Removing Body Scanners?]

We want to ensure planes don't fall out of the sky, due to mechanical issues.  In an attempt to ensure we don't go below this quality threshold, the FAA requires airlines to conduct regularly scheduled maintenance on aircraft.  As stakeholders, both the airlines and passengers see maintenance translate as on-time departures.  As this relates to application development, customers don't always think (or care) about code refactoring, fixing bugs, or paying down technical debt.  Still, if they don't want the system to crash or have a delayed launch, this out-of-site process has to take place on a regular basis.

Cost (budget thresholds):

As a business traveler, I expect my costs to fluctuate, based on quality and the speed in which I move through the system.  If I want to move through parts of the system faster, I can pay more.  In the end, local optimization just makes the process seem less painful.  It is, until you get to the next step or stage of the process.

The overall system:

1. I arrive at the airport (park in the Daily garage) [every 15 minutes a shuttle arrives]
2. I stand in line at the security (TSA) checkpoint.   [1-30 minutes]
3. Choice of x-ray or full body scan [pay more for express search] [1-20 minutes]
4. I opt out? [doesn't necessarily increase quality] [5-10 minutes]
5. I arrive at gate and
6. Board flight by "zone"  1st Class, Zone 1, 2, 3 [0-20 minutes]
7. Fly to destination [varies]
8. Land at destination and disembark the aircraft [5-15 minutes]

Though you can have several local optimums within the system, like any process we need to look at optimizing the system as a whole.

Look for bottlenecks and address them.  There is a bottleneck if a lead time exists between the start of one of the eight processes listed above and its execution (completion).   A lead time is the latency (delay) between the initiation and execution of a process. For example, the lead time between getting into the security (TSA) checkpoint line (process step 2) may be anywhere from 1 to 30 minutes. In industry, lead time reduction is an important part of lean manufacturing.  In application development, it allows us to shorten our iterations or feedback loops.  In travel, it allows us to get on with our lives with less impact to events happening outside the system.

One way I've seen people shorten the lead time at this process step is to just be ready.   Sounds obvious but you would be surprised.  There are signs and videos leading up to the security area.  TSA instructs you to have your boarding pass and photo identification ready.  They inform you what is allowed and what is not allowed (step 3).  I've seen countless travelers wait until they are at the podium before digging through purse or pocket, only to have a minor panic attack because they can't find a drivers license.

I've seen the same thing with application development.  Teams don't have their work ready and then there are delays in getting it done.

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.

PMI Puerto Rico Simposio Anual

Imagine barely missing the Nor'easter up in Connecticut, only to land in sunny San Juan, Puerto Rico 24 hours later for the PMI Puerto Rico Simposio Anual. That was me last week. My time in Puerto Rico was short but I met some amazing people and had a great time.  I spent one day offering a seminar on Agile Project Management and one day as a Simposium Speaker.  There was a lot of interest around Agile and what it is (and what it is not).  It was exciting to have the opportunity to interact with a completely different group of people, not focused on U.S. Government related work.  Just to confirm, not everyone is Washington D.C. is, but I would argue a large group I spoke to last month at the Washington DC PM Symposium were.  The people I spoke with this last week were entrepreneurs, company presidents, and managers...  What I found as the common thread was not on keeping a schedule or staying on budget.  It was about satisfying customers, maximizing ROI, and responding to constant change.  Regardless of the language barrier on my side, they could understand what I was talking about, confirmed by the nodding heads and mouthed "sí." I want to thank PMI Puerto Rico for being such amazing hosts.  There is something very notable I want to point out about their symposium.  Much like the symposium attendees, the organizers' primary concern appeared to not be keeping the symposium on a tight schedule.  The focus was ensuring the people attending got as much value as they could provide in the time they had.

Originally published on LeadingAgile

Demonstrating Leadership

As Hurricane Sandy approaches the East Coast, we're already feeling its impact.  You can't find batteries, milk, toilet paper, or bread anywhere. The only thing I went out looking for yesterday was coffee.  Strangely enough, I didn't have to fight anyone for it. It was interesting to watch people and see how they handled the stress of the situation. What I find even more interesting is how leaders are handling all of this.  By title alone, they should lead, right?  I see this as an opportunity for us to distinguish the wheat from the chaff.  Some leaders are doing just what they should. They are leading.  They are establishing states of emergency, they are closing schools, and shutting down public transportation.  Others are just waiting to see what others are going to do.  Though I am a strong proponent of waiting to make a decision until the last responsible moment, it feels like that moment has passed.  Has your leader stepped up?

I'm curious how this weather event is going to impact local elections.  I'm not referring to people not having electricity.  Hopefully, we'll all be on the mends by next week. No, I think Hurricane Sandy is bringing attention to where there is leadership and where there is a lack of it.

Image Source: Weather.com

PMI Global Congress Presentation on VMS

I am back from the PMI Global Congress in Vancouver, British Columbia. My lack of fancy pants went pretty much unnoticed.  I brought plenty of energy (and coffee) to my session and it appears people were very happy with the results.  I was referred to, at one point, as the Energizer Bunny and even the PMI quoted me.

I definitely left people wanting more.  It was an introductory talk and I only had 1:15 to present.  With 20 minutes dedicated to people in the audience working together to create their own Visual Control Systems, I found myself all over the room and loving every second of it.

It was great to meet people I've known for several years via the blog and through the PMI Agile Community of Practice.  It was also great to meet so many new people excited about Agile becoming more mainstream.

An Introduction to Visual Management Systems from Derek Huether

Side note: If you saw me limping during my session and at the Congress, it was because I may have a fractured heel.  I guess my OJ Simpson run through the airport to make my flight did it.

Favorite Project Management Quotes

There isn't a week that goes by that I don't hear some awesome quote or analogy.  I put as many as I can into my mental back pocket, hoping for an opportunity to pull one out at a moments notice.  When you're stuck for a quote or analogy, to help someone understand what you're trying to say, do you ever ask yourself what's that awesome quote that I just heard the other day? Here are 10 that I keep handy.  Are there any quotes you would like to share?  Please add them to the comments section.

---

• Because the needs of the one... outweigh the needs of the many. - Star Trek III: The Search for Spock, Captain Kirk.  I like to use this quote when explaining the contrast between egoism, utilitarianism, and altruism (servant-leadership).
• The more they overthink the plumbing, the easier it is to stop up the drain. - Star Trek III: The Search for Spock, Scotty. I'm admittedly a Star Trek geek.  I've used this once when trying to articulate Lean thinking.  I also segway into the untrue but compelling story of the Million Dollar Space Pen.
• The thing is, Bob, it's not that I'm lazy, it's that I just don't care. - Office Space, Peter Gibbons.  I like to use Office Space quotes, particularly when referring to empowered teams and while drinking from my Initech coffee cup.  Mmm'kay? Greeeeat.
• Luck is not a factor. Hope is not a strategy. Fear is not an option. - James Cameron.  This quote was on the back of the LeadingAgile t-shirts we all wore at Agile 2012.  I still have strangers walk up to me and ask about its origin.
• That which does not kill us makes us stronger. - Friedrich Nietzsche.  I think of this quote during almost every run I take.  After taking an inventory as to my physical condition, I have a mental debate as to stopping or keep pushing forward. I keep pushing forward.
• We keep moving forward, opening new doors, and doing new things, because we're curious and curiosity keeps leading us down new paths.- Walt Disney.  I've told my son over and over again to challenge the status quo (I don't call it the status quo because he's seven) and when given the choice, try new things.
• When we go into that new project, we believe in it all the way.  We have confidence in our ability to do it right. - Walt Disney  The power of positive thinking and an empowered team.
• Plans are of little importance, but planning is essential – Winston Churchill.  Another almost identical quote came from Dwight D. Eisenhower: Plans are worthless, but planning is everything When I talk about the Agile Manifesto and how we should be responding to change over following a plan, this becomes one of my most commonly used quotes.
• Stable Velocity. Sustainable Pace - Mike Cottmeyer.  This quote appears on the back of the LeadingAgile running shirt. It has become the unofficial motto of my life, as it applies to work, family, and running
• We don’t need an accurate document, we need a shared understanding - Jeff Patton. I was attending Jeff's session at Agile 2012, when I heard him say this.  It really resonated with me.  I don't know if the quote was scripted or impromptu.  Regardless, when I recently quoted him at a Project Managment Symposium in Washington DC, I saw over 400 project managers nodding their heads.

This post was originally published on LeadingAgile

Agile 101 – Presented at the PM Symposium

I want to thank everyone for coming out to the PMI Washington D.C. Project Management Symposium. It was a great crowd. The ballroom was full and I was told there were up to 400 people in the room for my talk. As promised, here is the SlideShare of my presentation.  If you go to the SlideShare site, you have the ability to download it.

Agile101 - What Agile Is and What Agile Is Not

from

derekhuether

Thank you VersionOne for the content for two of the slides.

My Lesson in Process Improvement

Regardless of your organization and goals, everyone is trying to do things better.  I commonly hear about management asking its people to do more faster, often with less.

One major mistake I see time and time again are organizations trying to do things faster before really understanding their own processes.  If you don't stop and really ask yourself if you've optimized the whole of your processes, before trying to go faster, any successes will be short lived.  I can assure you that speed without optimization is not sustainable.

Recently, I got back into running.  I haven't ran consistently for a few years and honestly, I always hated it.  The goal was never to run a half or full marathon.  The goal was always to stay under 28 minutes for 3 miles.  That was the minimum speed requirement on a Marine Corps PFT back in the late 80's, when I was enlisted.  Without fail, my feet and knees always hurt.  So, I did what any novice runner would do. I bought really cushioned running shoes.  I was able to run a couple miles at a time, at the pace I wanted, but I had to stop due to sharp pain in my knee and lower back.

A few weeks ago, I had lunch with a friend who is also a former Marine but he does a lot of distance running.  His goals include running half and full marathons.  I told him of my pains and he said I needed to read the book Born to Run and consider barefoot running.  Now, barefoot running includes both running barefoot or wearing minimal footwear.  Remember, the modern running shoe wasn't invented until the 1970's.  By getting rid of my cushy shoes and changing how my feet strike the ground, suddenly the pain is gone.  It was that simple.  A few days ago, I ran five miles and I could have kept going.  Suddenly, three miles in 28 minutes is no longer the goal.  Because I have a stable velocity with no pain, I now have a sustainable pace.  I know I can now go the distance.

Think about your organization again.  Do you meet your commitments, but it's painful?  Do you sometimes not meet your commitments, because your pace is not predictable or it's just too fast?  Stop and think about what you're doing.  Really take a fresh look at how you're doing things and consider making some changes.  Don't use the excuse of "this is just how we've done it in the past".  Once you find and address the root causes of your pains, you can refocus on what you're trying to accomplish and reaching both those short and long term goals.

The picture above is of me in a LeadingAgile running shirt.  Thank you Mike Cottmeyer for the slogan (and the shirt).  This blog post was originally posted on the LeadingAgile blog