The memo that started this firestorm stated in part -

“To become the absolute best place to work, communication and collaboration will be important, so we need to be working side-by-side. That is why it is critical that we are all present in our offices… We need to be one Yahoo! and that starts with physically being together.”

I’ve worn a lot of hats over the years.  In each instance, there has been a common goal:  Be as successful as possible.  Being “successful” is unique to every situation so that’s why I include ”as possible”.  But when you add happiness to the equation, what does that mean?

If you are in a job where you are rapidly iterating a product and continuously collaborating with others on your team, being face-to-face or side-by-side with your teammates will provide an opportunity to be as successful as possible.  Being collocated is no guarantee for success but being distributed (dislocated) is going to certainly limit your chances.  Leaders should focus actions more on making their companies, projects, or products successful and less on trying to make employees or teammates happy.

Now, don’t get me wrong.  I’m not saying we shouldn’t be empathetic to the needs of others.  I’m just saying there comes a point when you need to look at the costs and the benefits of remote work.  If the team is not realizing its potential, because one or more of them are working remotely (because they want to and not because they have to) we have a misalignment of goals.  Why would they sacrifice potential success for their personal comfort?  Well, businesses are trying to find ways to incentivize their employees. They hope that by incentivizing then, they will be happier and more productive.  But see, that is part of the problem. There is a belief that the incentives will make them happy.  Happiness is one of the byproducts of satisfying work, which can be derived from feelings of mastery, autonomy, and purpose (link to talk by Dan Pink).  I believe (in some cases) the work-from-home incentives will have a negative affect.

When companies hire us, they are NOT hiring us to make people’s lives better.  They are hiring us because there is value locked up in these companies and they are unable to produce.  They are hiring us to help them unlock that value.  Period.

What’s one of the first things I would propose if I coached teams at Yahoo? Bring the team together, face-to-face or side-by-side.  The only thing I disagree with in the Yahoo memo experpt  is where it states “…we are all present in our offices…”  I propose they get out of the private offices and into a team space.

Balanced piece about the pros and cons of working at home on Fast Company

Image Credit: Pictofigo

The post My Perspective on Remote Work appeared first on The Critical Path by Derek Huether.

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. I am given the 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.  If there is a lead time between the start of one of the eight processes listed above and its execution (completion), there is a bottleneck.   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.

The post Value Stream for Business Travelers appeared first on The Critical Path by Derek Huether.

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.

The post New Scrum Team Challenges appeared first on The Critical Path by Derek Huether.

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

The post PMI Puerto Rico Simposio Anual appeared first on The Critical Path by Derek Huether.

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

The post Demonstrating Leadership appeared first on The Critical Path by Derek Huether.