Agile manager's dilemma: Should you bend on principles?

As an agile coach, David Griffiths has watched the irony unfold many times. A manager spends a week learning the techniques of agile development and then returns to the office fully indoctrinated, gung-ho, and ready to apply every principle without compromise. The manager turns a philosophy designed to encourage flexibility into a straitjacket that every team member chafes against.

"When people get certified, the rules can become a tick sheet," Griffiths says. "They start to define hard and fixed processes instead of being nimble."

Deciding when to be strict and when to be flexible is one of the greatest challenges for agile managers. Enforce too many rules and principles and you'll leave everyone feeling frustrated and trapped. Let too many programmers run free, and the license to be agile becomes an excuse for everyone to do whatever they please. Chaos follows.

While the agile programming philosophy is gaining in popularity, there's still plenty of debate about which principles to push and which to gently suggest. As a manager, you must choose when to be dogmatic and when to be accommodating. Books can explain the rules, principles, and value, but only experience can teach how to bring them to the cubicle farm.

Griffiths is the author of several books on this subject, including Head First Android Development. He also writes code and nurtures agile developers for Black Pepper Software. When he comes into an organization to teach the principles of agile development, he encourages teams to start slowly and be flexible.

"We get into [a] very simple subset so they can work on them," he says. "Slowly, the underlying principles and the underlying values become apparent."

In the beginning, the team must learn the basics, Griffiths says. Here are the five major values that form the foundation of the agile process:

  1. Communication
  2. Simplicity
  3. Feedback
  4. Courage
  5. Humility

On these values rest principles, such as adding change incrementally or maximizing the return for stakeholders. These, in turn, are translated into clearly defined practices like test-driven development or creating multiple models.

When it comes time to bend, Griffiths sees no problem in dropping a practice if it conflicts with a bedrock value. But you should only do this if there's a clearly articulated reason why the practice is slowing the team.

He tells one story of a team with a project that took a long time to build from scratch because of elaborate dependencies. The agile principles encourage continuous rebuilding to ensure that the code compiles successfully and runs tests successfully. But in trying to do this, the team was waiting too often and creating increasingly elaborate build mechanisms to try to save time.

"If it turns out that in order to get the 10-minute build to work, you're compromising a principle, you're making a mistake. You shouldn't make it so complex that you're compromising simplicity," he says.

Testing in the Agile Era: Top Tools and Processes

...and when not to

Chris Sims, founder and agile coach at Agile Learning Labs and the co-author of Scrum: A Breathtakingly Brief and Agile Introduction with Hillary Louise Johnson, isn't as flexible. It's not that he thinks slavish adherence to rules is the only way, but it's his view that developers try to relax the rules when something isn't working. Letting something slide doesn't solve the dysfunction; it only lets it fester.

"Sometimes there are some that think the daily scrum is too expensive," he says. "They say it takes an hour and it gets in the way of doing real work. So they're doing it twice a week."

That's a mistake, Sims says. Communication is an essential part of the philosophy, and it shouldn't be relaxed. While programmers may get more work done with fewer meetings, they risk drifting off in separate directions and losing a common focus. Everyone needs to talk. Relaxing the requirement for a daily meeting doesn't fix a problem—it just hides it.

The solution, he says, is to limit the length of the meetings, perhaps to as little as 10 or 15 minutes. As a manager, you should be strict about cutting off those with a tendency to prattle on. Even if they seem too rushed, the groups can follow up later if more detail is needed.

"Changing scrum itself would be to cover up the symptom of the dysfunction," Sims explains. "It relieves the short-term pain, but what it doesn't do is address the underlying problem."

The key lies in identifying the underlying issue. Sims doesn't believe in following every rule dogmatically, but he thinks that the team should be suspicious of rule-breaking because it often reveals a deeper problem. While the rationale for relaxing a rule may seem reasonable, it can let a problem grow.

Sims says that diagnosing the problem isn't always easy, but the values and principles are guideposts for finding the right solution for the team.

"It's about getting a discipline in place where we are constantly reevaluating that and incorporating the newly discovered knowledge and moving forward," he says.

Rules aren't everything

Andrew Stellman and Jennifer Greene, the developer co-authors of Learning Agile, point out that even the rules aren't always enough. They tell the story of one group that dove headfirst into agile development but found themselves floundering after they'd worked through several iterations. The team made progress, but the users never seemed excited or satisfied.

"They were holding a daily scrum the way you're supposed to," Stellman says. "They had a product backlog. They had a product owner. They were breaking things down to tasks. If you had a checklist of all of the things you're supposed to do, they would check every box."

Every requirement from the list was done, but no one was happy with the software. The product wasn't loved. The new features attracted little attention. The team felt unappreciated.

The weak point turned out to be the product owner, a team member who typically comes from the business side and must represent the needs of users and the company. The person filling the role was too junior in the organization. He didn't know enough, and didn't have enough experience. As Stellman says, the product owner "didn't have enough juice in the company to make decisions on their behalf."

Using the agile model was better than nothing, but it couldn't compensate for underpowered decision makers. Even though they were following the model the best they could, they were violating some of the basic principles. The product owner wasn't providing the communication between the team and the users, and the programmers were left rudderless.

"I'm all about making changes, but you need to make those changes in a way that doesn't compromise the principles," adds Greene. "The reason the rules are written [is] people don't understand the purpose until they've done them a while."

Building muscle memory

Once you begin to understand the underlying reasons for the structure and rules of agile, the steps become like muscle memory, and the team implements them without feeling constrained by protocol, Greene says. Then the code just flows and all the short meetings and interactions make sense.

Attaining this state should be your ultimate goal, says Sims. When communication is smooth and the team is effectively self-organizing, good code emerges that makes both users and the company happy. Whether or not team members are checking every box or making every meeting doesn't matter; the end result is success.

"Once that happens, you can start to relax," Sims says. "That's why the rules are really there."

Topics: Dev & Test

Popular Posts