The Agile Architect

How To Win With Agile By Cheating (a.k.a., Rules Are For Other People)

Agile rules can sometimes become a barrier to progress and even be perceived as impenetrable. Our Agile Architect spins a story about recognizing these artificial barriers and how to break through them.

• By Mark J. Balbes, Ph.D.
• July 18, 2016

You have just joined an agile team. It's your first time practicing agile although you've read a lot about it and enjoyed the company's agile orientation class during your first week on the job.

Now, it's been two weeks, and you've just completed your first week with your new development team. And you are wondering what you've gotten yourself into.

The team you've joined is stalled on development. They haven't been able to push a story card through their Kanban board in over three weeks. The team is having yet another meeting to discuss how to resolve the issue. And, lucky you, you are a part of it.

"Look," says Jill, the team's technical lead, "We've been through this a bunch of times. It's pretty clear that we just have to power through this no matter how long it takes."

"So then how are we going to meet our deadline?" mutters Alex. "We need to tell someone that we aren't going to make it."

"We did that a week ago and I've been updating them," Jill says, a bit irritated. "Besides, this is our problem to solve."

"We've been trying to solve it. We've been beating our heads against the wall," Bob says coldly and a little too loud.

You chime in, "I'm sorry. What exactly is the problem we're trying to solve?"

Four faces turn toward you. Your face goes crimson but you stand your ground, "If I'm going to be a member of this team, I kinda have to know. Right?"

"Look," says Bob, "We don't expect you to understand everything at once, but here's the gist of it. We're building a brand new system. It's going to set the standard for everything our company builds from now on. We are building on top of Ballast technology fronted by an Anchor service which no one on the team has used. In fact no one in the company has used it."

Alice breaks in, "All of our user stories depend on it. They are all blocked on the Kanban board until we can figure this frickin' thing out. So we are making no progress and we are going to miss our deadline!"

"Can't we," you say timidly, "just work around it? Take that requirement out of the stories and say they are done without Ballast and Anchor?"

"That's not agile!" Bob retorts rapidly. "User stories have to be vertical slices through the system. Without that, we end up building software that doesn't work because the pieces don't fit together."

"Slicing the system horizontally is a big agile smell," Alice agrees.

Jill continues, more measuredly. "We've been experimenting with different techniques to solve the problem. We've tried having multiple parallel spikes to see if one pair can get it to work before the other. We tried mob programming after the spikes to see what would happen if we pooled our knowledge. We've taken online training classes, read countless articles, tried different versions of the libraries, and even switched operating systems. We just can't get it to behave the way we need it to.

"I was able to get the Hello World example to work pretty easily," you offer optimistically.

"Yes," Bob says. "That's swell. We all did that on day 1."

"The point is," Jill interrupts before Bob can say anything else, "we haven't had a demo in three weeks. We've got users that want to see our progress and give us feedback but we don't have anything to show them. Like I said, we just have to power through this somehow. Once we get it figured out, we'll be able to catch up and get back to normal."

"You've been saying that for two weeks," says Alex. "Nothing's changed."

"It will. It will," says Jill. "It has to."

Later at lunch you discuss the situation with Denny, your duly assigned new-employee mentor. Denny's been with the company for a number of years and you've really enjoyed your talks.

"Denny," you say after a lengthy explanation, "I just feel lost. It seems pretty obvious to me that we need to get some effort put on our user interface and our middleware layer but I guess that's just not agile, so we're not allowed."

"Who said that?" responds Denny quickly.

"The whole team. They say our stories must be complete vertical slices through the system to be agile."

"Seems reasonable," says Denny. "But maybe, in this particular case, it isn’t"

"It sounds like," Denny continues, "besides the immediate technology problem, there are a few other things going on that the team isn't addressing. First, because you aren't making progress, your metrics have become useless to you in predicting whether you will make your deadline."

You jump in, "And that's important! We are racing a competitor for shelf space so if we miss the window, we may not ever get to market. That's why it's so important that we solve this problem now. We can't ignore it and hope we magically get smarter later."

"Or can you?" Denny smiles. "You've already pointed out that you aren't having demos. And that's my second thought. Your team has chosen to defer learning on other fronts in order to hit this one technical problem with the full capacity of the team. Is there some way you could continue learning about your other technologies and about how your users will interact with the system?"

"I guess we can have only one pair working the problem and the rest continue on stories," you say excitedly. But then you pause and say deflated, "But not really. Like I said, in order to do any of the user interaction or middleware work, we have to do full stack stories, and we can't because of..."

"No, you don't." Denny interrupts. "If I told you it was O.K. to stop working completely on the technology problem, what would you do?"

"I guess I would mock out the Ballast and Anchor layers of the system and build everything else on top of the mocks."

"And what does that buy you?"

"We can let our product owner and users interact with the system so we make sure we are building the right thing. That's what I suggested to the team but they shot it down. Besides, we can't release with mocks."

"No, but it starts the learning and feedback cycle again and unsticks your team. Once you start getting some momentum, you'll see the team morale improve and you'll work better together. Also, I'm not done asking questions," Denny smiles.

"Why do you have to use Ballast and Anchor at all?" Denny continues.

"From what the team has said and what I've read, it's really the only option for this kind of functionality. Any team that wants to frugate their blancheu does it this way."

"What if you wrote it yourself?"

"That's crazy. There's like a whole development team that's been working on it for years. We could never duplicate what they did in time."

"But you don't have to. And that's my third point. You only need what's necessary for your first release."

"I suppose it's possible but we'll definitely need it for the next release."

"So you are choosing to jeopardize this release in order to hopefully minimize risks to future releases?"

"Yes! Yes. Um, yeah I, I mean that's what we talked about," realization dawning on you.

"And what happens to future releases if this first release doesn't meet the deadline?"

"They might not happen," you pause. "So you're saying that we should forget about Ballast and Anchor, have one pair build a minimal replacement and put the other pair on user stories with mock implementations on the back end. When we get our minimal replacement, we'll go through the user stories again, replacing the mocks."

You are excited but then it occurs to you "But what happens if we can't build a minimal replacement? We'll have lost all that time."

"You could have one pair continue to work with Ballast and Anchor."

"We only have two developer pairs. Alex is our QA. So that won't work. Looks like we are going in circles."

"Why can't you get a third pair to help? Perhaps some fresh eyes on Ballast and Anchor will shake things up a bit."

"We don't have the budget for more people. The team talked about that."

"Have you talked with your executive sponsor about it?" Denny asks.

"Of course not. This is a technical problem. She couldn't help."

"Well, now maybe she can," Denny smiles knowingly.

"O.K.," you recap. "So we are going to cheat and take a non-agile approach."

"Who said that?" Denny snaps. "Agile says to deliver working software. You aren't doing that now so you need to find a different way to be agile."

"Right. Got it. Sorry."

"Is that enough to get you past these problems for the first release?"

"I think so."

"Can you bring this back to your team?"

"I'm not sure I'll be able to explain it too well."

"Then how about we go together?" says Denny.

"That sounds wonderful," you smile.

Final Thoughts
That's my story, based on multiple, real experiences. This story uses a specific issue to illustrate a case where an excellent agile practice, vertically slicing stories, can lead down a bad path. But this can happen any time you apply practices without understanding why you are applying them to your particular problem. And finally, if you ever have to frugate your blancheu, remember to not pre-optimize the pole-gates.