Sustainable Pace - Why should I care if they aren't "my" people?

#1

Not long ago, I started a new engagement with a new client on a new project. On day 2 of the job, I found myself in the office of a rather senior leader within the organization. His comments were roughly as follows…

“This is a rather odd project. Yes, we plan to execute the project using our Agile SDLC, but we’re basically implementing a COTS product and the vendor will be in charge of doing all the development. We have a fixed price contract in place for the next 2 years so, frankly, I don’t really care if we just keep everyone locked in a room for 2 years and slide pizzas under the door as long as the work gets done. Why do we care about sustainable pace?” (This quote is only minimally exaggerated. “Lock them in a room and slide pizzas under the door” is actually a direct quote.)

At the time, I was a bit surprised by the comments and not entirely prepared to provide a rebuttal.

What do you think of the comment? And what research, data, ideas, or philosophies have you found useful to convince leadership that sustainable pace is important even when they aren’t dealing with “their” people?

#2

There are several things I would take issue with in that conversation beyond the obvious one on pace. For starters, is that really the culture that leader would be proud to expose to his top customers? Looking at humans with heartbeats as cogs in a machine should have died off long before now. Beyond that, who touts fixed bid contracts anymore? They have been proven to be bad for both parties (one of many sources: https://robots.thoughtbot.com/why-fixed-bids-are-bad-for-clients-too)

But to your direct question: sure. This leader can likely sustain a staff of pizza devouring hackers to chunk together some software. But the engineers that will build an innovative, quality-first, scalable, and modern product have far too much integrity for the craft to waste away in such conditions. Happy engineers write better code. I say it all the time. Building a culture of engagement and balance maintains appropriate staffing levels of the types of engineers you want. Doing the opposite drives them away. Software is not a one time cost, nor a commodity. I don’t think the leader in question has evolved to this understanding yet.

(I love this post. Thank you @matthewholtry)

#3

Adding on to what @ryan wrote, I’d play a game of Dickens: Tale of Two Code Bases with the Senior Leader.

What’s the best that could happen?
Two years, a lot of empty pizza boxes, and a shipped product. Sr exec gets kudos and a promotion.

What’s the worst that could happen?
We all know when you fix the three sides of the PMO triangle only one thing can give: quality.
Two years later, a lot of empty pizza boxes, and a crufty code base, mortgaged out the wazoo w tech debt. Sr Exec doesn’t get that promo, and the first feature change cost 10x what it should, the next team is wading thru the swamp with concrete boots, and the slightest change might just make it all to come crumbling down.

#4

Adding to “what’s the worse that can happen”:
The only developers left are the ones you don’t want on the team. All the good ones left for more fulfilling gigs.

#5

I remember when you told me this story, Matt. It’s an unfortunate way of thinking and even more unfortunate that it’s so common. You and I both spent time doing government consulting work and I know we both used to see this often…it’s what I call the “class system.” I’ve seen similar behavior in the large corporations that I’ve supported so it’s certainly not restricted to a single type of organization.

Contractors/consultants/outside talent…whatever you call them…are all too often treated as second class citizens. IMO this is a leadership flaw. I believe that the more all levels of leadership create an inclusive and safe environment and treat EVERYONE with respect, courtesy, honesty the more successful the organization will become. @ryan is right…if they don’t do that then the good people will leave. It’s that simple.

#6

As soon as you hear “SDLC” you know you are dealing with an organization that values rigor (mortis) over change. Projects with “life cycles” have births, lives, and deaths and so inherently tend toward being death march projects–you’re marching straight to a post mortem. What that person is really saying is they don’t subscribe to agile values and, thus, I would say is probably an example of the impediment to adoption surfaced in VersionOne’s studies time and again that the “organizational culture” isn’t ready for Agile. Most likely the idea is that these sorts of leaders will “will” the end result they are looking for, imposing that will on the team, and not caring about collateral damage or even ready to take heads if the team isn’t scared enough to “make it happen.” Motivation by fear. Force the vendor…and get an enforcer to help force the vendor. Feed 'em pizza!

The question is how to convince this leader to think and work different. Or even can you do this. First probably need to see if this leader just mouthing agreement with using agile within this organization but meanwhile whole-heartedly fears change and believes that SDLCs can stop all that pesky change. You are a contractor yourself, a hired gun, so do not envy your position. Are you meant to coach this person or just the team? Or are you actually there to “manage the project” (read: beat the team with sticks to force them to be accountable and deliver).

If it is the last one, I’d take the prioritization, minimum deliverable amount of stuff approach. Try identifying the most important stuff this person wants out of the team, and get that person to focus on it. Keep them feeling happy about getting that most important stuff. There will by nature be things (features, etc.) that are less important to this person, and to the customer, and can slide down on the list of things you make. In that way you can potentially stealth work at a sustainable pace. It’s the art of getting the important stuff done and the stuff they actually aren’t that wedded to really finally eliminated from the project, if possible. Also, if you can, do a user-focused approach. If you can say “but does the user really care about ‘x’…” it can help with prioritization.

#7

In a prior engagement I was part of a contractor contingent that outnumbered the FTEs in the technology space by 4-to-1, and we were all treated like lower-caste disposables even though we did the lion’s share of the work and had almost all the tribal knowledge. To @andybacon’s point, you need to create an inclusive environment otherwise people vote with their feet and you’re left with the people you DON’T want (to @ryan’s point).

In anything in life (marriage, child rearing, careers, running a marathon) sustainable pace is KEY…too slow and you end up frustrated and unfulfilled, too fast and you get burnt out and look elsewhere. I love @andycleff 's Tale of Two Code Bases, that’s spot on.

My current engagement is a long-term contract with an external vendor to build an ERP application and I see this attitude here as well. My remark to my boss has always been “The business users dont care who wrote it, they care if it works. If we don’t keep them involved and treat them as equals all we’re doing is standing up a scapegoat. Shall we rename everyone ‘Lee Harvey’?”

Another way to look at it (to borrow from Candiria); constant velocity is as natural as being at rest. Which of those two options helps us reach our goal?

#8

So many awesome observations in here! It is probably worth noting that this entire organization is in the middle of a huge shift from a top-down (and waterfall-driven) culture to adopting Agile values. Over the course of about 6 months, I have seen this really interesting transition across 3 mindsets:

Mindset 1: Just get the work done.
This was at the start of the project (when I had the conversation mentioned above). It was all about "Get the work done. Who cares about the people?"
Key question asked in this phase: “How much faster can they make their Velocity go?” (My favorite answer to this question: “We can make Velocity go REALLY fast if you don’t care about quality…”)

Mindset 2: “Enlightened” Self-Interest
The people doing the work are basically still machines. Leadership starts to care about the people a little bit, but only because turnover can be expensive and slow down progress. But at least there is an acknowledgement that turnover is a bad thing and we have to start thinking about the fact that real human people are doing the work.
Key question asked in this phase: “Can velocity go faster…?” {with undertone of “…without someone quitting?”}

Mindset 3: I’m a Human Too
Leadership recognizes real humans are doing the work, and real humans should be valued. They should have free time and be able to see their kids and feel engaged at work and like what they’re doing. There is more “we” than “you”.
Key question asked in this phase: “Are you sure we can sustain that pace? Did you see your wife/husband/kids this week? Hey, are you going to the happy hour at 5 today?”

I am happy to say… Mainly due to a lot of happy hours, ping pong tournaments, and other social activities, we recently shifted from Mindset 2 to Mindset 3. But it is interesting how, even when the “tone at the top” changes, there is still a bit of a PTSD element to the team. (“What would leadership REALLY say if our Velocity was 10% lower next Sprint?”) It takes a while to (re-)build that trust.

#9

@JayHorsecow: I subscribe to a service (Blinkist) that sends me summaries of books. I just got this summary of Jim Collins’ Great By Choice in my inbox and it is such an awesome parallel to your Candiria quote:

In 1911, two teams set off on a race to become the first explorers to reach the South Pole. One team, lead by Roald Amundsen, got there first, planted the Norwegian flag, and returned safely. Englishman Robert Falcon Scott’s team arrived 34 days later, discovered they had lost the race, and tragically froze to death on their way home.

Companies could learn a lot from Amundsen’s success

Great By Choice examines the differences between the two teams and demonstrates that just as Amundsen’s strategies helped his team survive in the unpredictable Antarctic conditions, so too can they be applied to the turbulent world of business.

For example, Amundsen’s team had the habit of matching exactly 15.5 miles every day, whatever the conditions. When the weather and terrain were favorable, he would march this set distance and then stop and rest, even when his team could go further.

Conserving energy like this meant that even when conditions became difficult, his team was still strong enough to march the same distance and maintain a steady pace.

#10

@ryan: Thanks for this link! I was just giving some advice for a SOW for an Agile engagement, and I am going to send this along. Perfect timing!

#11

I’d encourage him to try it! Just lock them in a room and slide pizzas under the door for two years.

But warn that exec to get ready for the steady stream of shit to come out of that room!

Low-quality software (i.e. “crap”) will be the only thing that group will be capable of producing…that is, without sustainable pace and a humane work environment.