How to Deal With Software Development Schedule Pressure

Comments

My alarm goes off at 5:30 a.m. on a Saturday. I'm driving three hours to Dearborn, Mich., to the Agile and Beyond conference. Jim Benson, author of Personal Kanban , is giving a keynote on management anti-patterns.

I'm not getting up early just for Benson, or the 28 conference sessions, but, instead, for a gathering of the Council of Elders, an informal group of Midwest software development practitioners. We last met at the previous Agile and Beyond. Our purpose this time was to discuss schedule pressure and how to deal with it.

Nayan Hajratwala, principal of Chikli Consulting, was back from last year, along with agile coach and consultant Matt Barcomb, programmer David Hoppe and Michael Drzewiecki, a project manager from South Bend, Ind. The band had two new members: Todd Kaufman, co-founder of Test Double Consulting, and agile coach and consultant Sandi Keller.

Grabbing lunch-the only free time slot, as half the council were conference speakers-we found the speaker room and talked about how to deal with pressure.

When Deadlines Move Up, You Must Cut Scope

CIO.com: You know the project is going to be late. I know the project is going to be late. Someone else figures out the project is going to be late. The pressure's on. Now what?

Hajratwala: It's hard to give general advice, but I can give you a case study of what I am working on right now. It's a multi-year, multi-million dollar federal government project. It was about halfway through&when I got there, and nothing had been built--just architecture and a proof of concept that did nothing.

CIO.com: How can your proof of concept do nothing?

Hajratwala: The big concern was performance, so the team had built the capability to performance-test the application with massive amounts of client connections in real-time. It just didn't do anything yet. I&suggested the team build some features, and we did. After a few months, I looked at the number of stories, our existing velocity, and predicted it would take about six-and-a-half-years to complete. It really wasn't accurate at all, but it was the best we had-certainly better than wishful thinking.

How-to: 13 Tips for Keeping IT Projects Under Control

CIO.com: What then?

Hajratwala: Management did the right thing-cut scope-and managed to cut a few things. That, combined with a better understanding of our scope and a slightly increased rate of throughput, allowed my simple measurements to show we could be done around May 2014. That's when the email came from management: "How about you deliver it in December 2013 instead?"

Keller: How did you reply?

Hajratwala: I said, "It doesn't really work like that. We know the throughput, and that changes very slowly and gradually. You can't just throw a bunch of people on it to make the project go faster. The only thing you can do is cut scope. That's it." Management said, "But we need everything." I said, "Do you really need everything?" There we lots of discussions about that. They cut about 50 percent of the scope. Now December is starting to look realistic, but it's changing. We update every week with a more accurate prediction.

That's the big change in thinking. We can figure out now that we won't make the date and change plans instead of waiting until November to realize we won't make December.

Kaufman: Where did the original schedule come from? Why did anyone think they would be done in May 2013?

Hajratwala: That was before my time. Basically, someone picked a date.

Software Development Schedule Pressure Arises Because 'Time is Arbitrary'

Kaufman: We're still constrained by the iron triangle. Usually somebody up the chain has a certain amount of money, or a high-level scope, and that's the most malleable of the three. Time is totally arbitrary, really. It's often just picked out of thin air.

CIO.com: Do you think time comes from math? If you have $10 million and 20 contractors at $100 per hour, you can divide the money by the cost per week of the team and figure out when you "have" to be done? (Note: It's 125 weeks.)

Hajratwala: That's exactly how it often goes. It's as good a way as any other to predict that far out from nothing. We really have no idea.

Kaufman: But then at least call it what it is: Burn rate. We may ramp down, we may ramp up, but we have a burn rate, not a schedule.

Hajratwala: Our team interfaces with another team doing waterfall, and we got [it] involved in our standups. They asked, "How do you figure out your three-year plan?" The team was quiet, so I&said, "We recognize that our three-year plan is totally fake, so we don't make it."

Keller: Sometimes that's hard in a world where people at the top level believe in their three-year plan and have confidence in it, even when they've seen that it never matches reality.

Hajratwala: These people&have been sold so much snake oil that they have no faith in anything coming to them. So they say, "You know what, here's what I need and here's when I need it." The only way to break through that is to actually deliver something.

What we're saying-that we can have something in production by the end of the week-makes no sense to them. They want to see the three-year plan. Frankly, until we've delivered, they have no reason to believe it.

Keller: Some people have the thought that they get the commitment to November in order to get it in May. The false-commitment makes sure they get it at all, and they believe it makes the team work really hard.

Drzewiecki: That's schedule pressure as a tool-from a belief that if you don't apply the pressure, the technical team will be lazy. There's a lot of distrust there.

Kaufman: Sometimes the hidden message is to deliver the crappiest piece of software as soon as possible.

Keller: Team members worry about a death march. A few people just can't work longer hours for family reasons. The team often figures out [it] can get it done by sacrificing quality.

Tips: 3 Ways to Be More Agile With Software Shipping Decisions

Drzewiecki: I've even heard of management specifying a "warranty period" after ship. They expect bug fixing the month after shipping, we'll get nothing else done and that is OK. I did not take that forward, I did not tell the technical teams; it would destroy them to tell them they did not have to take pride in their work.

Quality, Time Squeeze Software Testing, Deployment Schedules

Barcomb: How much planning are you doing to predict how long the fixing will take?

Hajratwala: When we said we'd ship with zero known defects, it turned a few heads. The QA guys like it; they're amazed they don't have to "accept" a buggy story anymore.

Drzewiecki: It's a lot easier to get the QA guys to buy into that when they realize we're not pointing at them. We want them involved and want to improve the quality before it gets to QA.

Barcomb: If that's the policy, how do you deal with defects that are found in production? How do you get people to not "blame" testers?

CIO.com: How about shipping buggy earlier and fixing later? Is that acceptable? Would [software consultant] Uncle Bob Martin yell at you?

Hajratwala: Of course.

CIO.com: But would you ever take that deal?

Kaufman: You'd lose any credibility with the technical staff [by] asking [it] to do something like that.

Barcomb: It depends on what it is. Gmail was in beta for how long? And people like it.

How-to: Adjust to the Changing Face of Software Testing

CIO.com: A lot of companies want to be like Gmail, but they don't want to make the investment in quick deployment, rollback and monitoring to make that strategy successful.

Hajratwala: It's also different to develop one feature and roll back if you need to than to develop a pile of stuff in a year and push it all out to production at the same time.

Unless You're Facebook, Buggy Features Aren't Acceptable

Kaufman: Most of us don't work [on] Gmail, and most of us don't work on the space shuttle. There's a middle ground. The pressure is to do a bad job coding to get this feature done, which makes the next feature slower. That's the part that is hard to quantify, hard to measure, which makes it appealing psychologically. It's invisible-and easy to cut.

Barcomb: As long as you can align the strategy so your bugs are someone else's problem, you're OK?

Keller: When can you pursue that kind of a strategy-where buggy features are acceptable?

Hajratwala: Facebook is a great example.

Kaufman: Right. How many automated tests did Mark Zuckerberg write before he got to market? We try to define quality as binary, but it's usually somewhere in the middle. There are 500 shades of grey with regards to software quality.

Keller: Facebook is one thing, but lots of companies have compliance issues where the consequences of missing a deadline are millions of dollars in fines.

Hajratwala: Right. And if Zuckerberg's company went under, so what? He could get a job.

Kaufman: People don't have the courage to step up.

Keller: I've been in situations where the entire team is asked to do things. They hear the request, walk away, and say&"I can't believe what I just heard."

Kaufman: It goes back to trust. If you have a high-trust environment, people will speak up.

Barcomb: I used to have a number on a piece of paper-the amount of buffer we needed in the bank for when I lost my job. One day, my wife called and said we had hit the number. Suddenly, I started to speak up.

Keller: Once you feel that you have options, you suddenly feel empowered.

Barcomb: If you want people to be more forthright, talk to them. Have the one-on-one conversation: "I'd like you to speak up more. What's going on?" Another conversation to have is about predictability. We can move closer to predictability, but it's not a shop floor-and it isn't going to be one, certainly not if we are defining objectives at the bullet-point level.

Kaufman: One thing we can focus on is change the conversation from executives asking the technical team, "When this will be done?" to instead having the team ask the executives, "What amount of money are you willing to game on this amount of scope?"

Ask Your Software Development Questions

Lunch ends, and we scoot off to a session or to practice. We do manage to get together in the evening, after the event, to share notes over beverages.

During the conversation, I have to wonder: How many people live in towns without a Council of Elders, a group to turn to when times get tough?

If you have questions, ask them in the comments below. We'll encourage the council to monitor them.

Plus, you know, we do need a topic for next year's Agile and Beyond.

Matthew Heusser is a consultant and writer based in West Michigan. You can follow Matt on Twitter @mheusser, contact him by email or visit the website of his company, Excelon Development. Follow everything from CIO.com on Twitter @CIOonline, Facebook, Google + and LinkedIn.

Read more about agile in CIO's Agile Drilldown.