Avoiding Sand in the Agile Gas Tank
Most software organizations are some version of Agile. Yet, lingering habits still gum up the works. There are some surprising and obvious-in-retrospect reasons why organizations are not as Agile as they might be. If you want to avoid or minimize Agile challenges, read on.
Being Agile is a competitive necessity for many organizations, yet the degree to which they become Agile varies greatly. While communication and collaboration tools have come a long way, corporate cultures and management practices have not necessarily kept up. In fact, quite often it’s the people issues that keep companies from meeting their goals.
Agile development is sometimes viewed too narrowly to succeed on a broad scale. When business representatives are absent, developers build products that don’t meet customer requirements. If downstream roles are omitted, release schedules slip. Following are some best practices that can save time and frustration:
If you’re scaling out Agile, cloning doesn’t work.
What works for a group of enthusiasts doesn’t always work for tens, hundreds, or thousands of other people who are used to doing their jobs a certain way. Agile is a process, after all, and people often resent changes in their work processes. Even when Agile has been scaled out to multiple teams or across the business, it becomes obvious that what works well for one team or project may not work so well for another.
While people need to adapt to Agile ways of working, conversely, Agile practices need to be adapted to suit the unique set of circumstances to which they are being applied.
Don’t underestimate who should be on the team.
Developers, testers, and product owners are pretty obvious. But it’s easy for businesses to overlook people in other roles, such as DevOps, security, documentation, and governance, and their absence can backfire.
“A cross-functional team should include anyone involved in getting the product out the door because those people can cause delays,” said Carrie Driscoll, Agile Delivery Leader at Eliassen Group, a technical staffing firm. “And if they have something assigned to them, they have to be part of the sprint.”
While the list of who should be included may seem long when all of the potential delays are considered, their involvement (particularly upfront) can save time in the long run.
Don’t send a proxy when a decision-maker is required.
Because business executives and product managers are busy, they may send a proxy who has no decision-making authority related to the sprint. (This happens more on the business side rather than among the technical staff.) When the proxy can’t make decisions, it causes delays. It also frustrates other team members who are prepared to move forward.
Be wary of over-committing resources.
Some team members, such as developers, may be 100% committed to a particular project. But other roles, such as database administrators (DBAs), security experts, product owners, and operations personnel, have other responsibilities. Some of these people may dedicate a percentage of their time to one project, with the rest of their time spent on other projects or day-to-day responsibilities. If their time is not monitored, the commitments may exceed 100%, causing unforeseen delays, especially when the person’s time has been split between two or more competing “high-priority” assignments. Not to mention creating stress for the overloaded individual.
“The organization has to be onboard to help manage resources,” said Driscoll. “If a developer has enough work to stay busy for six months, don’t add to that. And the organization is really better off if people are not working on five projects at once.” If they are pulled in several directions, they’re not doing their best work.
Practically speaking, not everyone can be dedicated to a single team. Just make sure the math adds up, whether you’re committing your own time or if you’re demanding a commitment from someone else. Thirty percent here, 50% there, and 40% somewhere else equals over-commitment.
Lead by example.
While it’s fashionable to be “Agile” and many executives label their organizations such, they may not understand what’s actually required of an Agile organization or Agile leaders. Sometimes, executives and project leads send underlings to Agile training but they don’t attend themselves. This has a negative effect on people’s attitude and it does little to establish a common foundation. All stakeholders should attend some kind of cross-functional Agile 101 training so everyone understands the basic terminology and how Agile practices affect everyday processes.
“Some companies have experienced failure because they didn’t have a foundation,” said Driscoll. “It’s important for people to understand each other’s roles and to have process agreements for the whole team.”
Different consulting firms take different approaches to cross-functional training. While most advocate Agile 101 training for all stakeholders, their training approach may differ. In some cases, executives and business people get separate training with attention at a conceptual level; others provide basic training for all roles, supplemented by with in-depth technical training.
Training is often viewed as a one-off panacea but it needs to be reinforced to be effective. Few people retain all they learn in a one-day, two-day, or one-week class. If training is not reinforced, people tend to revert back to their old habits.
There are a couple of ways organizations handle this: They either supplement training with ongoing coaching; or they break training down into smaller, more palatable pieces that are applied immediately.
Bring new people up to speed. It is easy to forget that that new hires and people just joining the team weren’t around when the rest of the team attended Agile 101 training. If formal training isn’t a viable option, consider pairing the new person with a seasoned team member.
Don’t ignore or otherwise disenfranchise remote team members.
“Agile” and “distributed teams” were once considered mutually exclusive but today’s software development organizations usually include remote teams or team members. Whether the team members are in-house, consultants, or offshoring resources, the end result is better if they attend key meetings, with access to the same tools and information as their on-site team member counterparts.
“No one ever said distributed Agile development was easy, but that’s doesn’t mean you can’t find creative ways to make it happen,” said Driscoll. “The more time you can overlap for a key meeting, the better. You should also have an online location [to which] people can go to find stories, decisions that were made in meetings, and other artifacts. You should also have a team collaboration tool so you can ensure transparency.”
It is also a good idea to physically co-locate distributed team members from time-to-time so they can get to know each other and overcome their differences.
“We brought team members out from Kiev for a client company,” said Driscoll. “When you get to know someone personally, it builds trust and breaks down cultural barriers.”
Set Realistic Goals.
Late delivery may be the result of unrealistic expectations. If you’re used to releasing software in six-month increments, getting to two-week sprints should be a gradual undertaking. Don’t try to step off a cliff. It is better to have a series of smaller wins than a major failure.
Also, beware of cross-departmental expectations. Assigning tasks and delivery dates to individuals is good, but don’t make blanket assumptions about other functional areas. Just because your developers work at a certain cadence doesn’t mean IT can work at the same cadence, for example. If you understand what you need and when you need it (such as access to certain infrastructure or the set-up and pre-population of a pre-production environment) you can create stories to facilitate communication and to ensure more accurate project timelines.
Don’t view Agile as a one-size-fits-all solution.
An organization’s unique circumstances drive adoption. Even within an organization, practices can vary. For example, one large U.S. conglomerate has an energy division and a healthcare division that are taking different approaches to Agile. One has been focusing on automation to speed testing and deployments with the goal of getting feedback as soon as possible.
The other is taking a cross-functional, team-centric approach to break down functional silos and departmental barriers. Both are trying to get to market faster with better products, albeit differently.
Be a leader, not a commander.
When they’re working, Agile teams are highly collaborative and often self-organizing. That can be a challenge for managers who still have a command-and-control view of the world. For one thing, Agile teams tend to include smart people who expect to contribute ideas and solutions. An effective manager facilitates cooperation among team members rather than micromanaging. And if the manager proves not to be an effective leader, the team may adopt its own set of rules.
“Part of a manager’s role is to make sure that people are working well together,” said Driscoll. “You can have the best team in the world, but if there are personality conflicts it affects everyone. I’ve seen people voted off the island because the leader was not dealing with it. In the planning session, the team didn’t let the person take any of the stories so the person decided to switch to another team.”
There are countless ways to become Agile and no one way is “the right way.” There is what works and what doesn’t work, which varies from team to team and organization to organization. While the many tool advances help distributed and co-located teams function more effectively, it is often the people issues that continue hold teams and companies back.