Start For Free
 

Being Agile is hip, but not all teams and organizations are equally adaptable. While stodgy cultures and individual attitudes are often to blame, the “small stuff” may go unnoticed – and sometimes the small stuff counts, big time. Team leaders are wise to pay attention to details (including those that have nothing to do with Agile methodologies); these obstacles to progress are not usually apparent until after they happen.

One of life’s biggest lessons is, “Never assume.” Yet, a lot of assumptions pose challenges for teams and enterprises transitioning to Agile. While the desire to adopt Agile methodologies may be genuine, there are certain obstacles managers and executives overlook that can impede or even halt Agile initiatives.

Agile stepsAgile Wasn’t Supposed to Mean This

Agile development concepts are simple. Transforming a team or an enterprise into an Agile entity is far more complicated. While there is no shortage of information about Agile development processes or Agile methodologies, a lot more is involved in becoming agile than is immediately apparent.

“One of the most common mistakes almost everyone makes is thinking that Agile is a series of steps and if you learn the steps, you’re there,” said Damon Poole, chief agilist at Elaissen Group, an IT staffing and services company. “People don’t realize exactly what they’re getting into.”

While managers and executives may acknowledge that Agile development requires a different working style than traditional methods, their teams still may be structured in traditional ways. And, team leaders may not have adapted their managerial styles to an Agile way of working.

“Managers are used to telling people what to do. They’re not used to giving them work and saying, ‘You figure it out.’ That’s a cultural change,” said Poole.

It is not uncommon for teams to succeed on their initial Agile project. However, it is also not uncommon for subsequent projects to fail or to be less successful when people fail to realize that the success was tied to a project, not to a broad, organizational change. As a result, the organization may be overconfident about its ability to repeat the success. Since not all factors are constant, the same approach used in a different context can yield different results.

Over time it may even become apparent that the organization’s culture, structure, and processes are not in line with Agile practices. “If you remove all the support from Agile it will go away,” said Poole.

Even when an organization thinks it has committed to becoming Agile, contradictory work habits may frustrate progress. If an email announcement is sent out stating that the team or the organization is going to transition to Agile, but every subsequent email sends a traditional message such as asking for the status of sign-offs or the status of requirements documents, the inconsistency may adversely affect the desired cultural shift.

“Project managers typically becomes Scrum Masters but they continue to look at Agile as a means of doing the things they used to do, like telling people what to work on or getting status updates,” said Poole. “Most of the people on top have never really worked as part of a team, only as individual contributors.”

Yeah, Yeah, Whatever

There are usually disconnects between what people think Agile should be and what it actually is. While this is a valid basis for hybrid implementations, it can also indicate radical differences in the perception of what “Agile” means. The lack of a collective understanding of how Agile will be implemented can stand in the way of its positive application.

One way to drive consensus is through training which often takes the form of a two-day class. While training is helpful it is not a panacea. No one can learn everything they need to know about Agile (or most other things!) in two days. Training has to be practically applied to be understood in context.

Agile distracted in meetingIn addition, some of what is taught may not sink in because the person is experiencing information overload or because what is being presented contradicts the student’s work experience. “When somebody tells you that you’re going to have something you can actually ship and put into production every two weeks, people may not think it will work in their organization so they’re kind of half paying attention,” said Poole.

Transitioning from traditional product releases to sprints can be difficult when people are questioning their skill sets, staring at a giant requirements document, having to think about a business case for the first time, or considering the software’s value from a user’s point of view for the first time.

“It’s tough to get the benefits of Agile in a two-day class. It’s like saying, ‘Let’s go climb Mount Everest. I hear they have a class on hiking this weekend,’” said Poole. “The goal is to hit the top. It requires a lot of skills that have to be built up over time.”

Bumps in the Road

Assuming team members have accepted that their former heavyweight projects can now be implemented in a lighter-weight fashion, the question becomes how to manage sprints. Because a comparatively limited number of things can be accomplished in one to four weeks, prioritizing backlog items and tasks is essential.

But beware of scope creep. “In Agile processes like Scrum, the team plans a sprint based on business priorities. By committing to a set of goals, the developers know they can focus on specific tasks without interruption and the business owners know that if things change they need to wait another week or two,” said Mark Herschbert, CTO of lead generation firm Madison Logic. “Unfortunately, business owners forget this and try to shoehorn more things into the sprint.”

Raja Bavani, Agile evangelist and chief architect of Product Engineering Services and IT Services at outsourcing firm Mindtree, said scope creep can also result from poorly-defined user stories. “When you get high quality requirements you can deliver high quality deliverables or meaningful solutions,” said Bavani. “If the user stories are insufficiently groomed, changes can creep in.”

Whether or not scope creep is an issue, the demands from business are consistent: more features, higher quality products, faster times to market. And oh, do it all at the same time with increasingly favorable results. While software teams work hard to keep pace with such demands, the outcomes are not always perfect.

“The point of the sprint is to focus on producing software, not meetings and documentation,” said Madison Logic’s Herschbert. “We hope not to be off by much, but the product owners don’t always get the specs right and they don’t always communicate them perfectly to developers (who aren’t perfect at estimating anyway).”

In some cases quality assurance suffers.

“When teams keep up with the pressure from the business to deliver as many features as possible as they move from iteration to iteration, the rigor of engineering practices such as automated unit tests or code quality decreases,” said Mindtree’s Bavani. “Teams accumulate technical debt and they do not take any steps to pay off the technical debt. This results in several issues contributing to poor product quality.”

Learn from Others’ Mistakes

While Agile adoption levels differ from company to company, there are some things managers and executives can do to increase their odds of success, according to Elaissen Group’s Poole:

  1. Realize that going Agile requires reorganizing. While just about everyone hates the word “reorg,” a structural shift is necessary.
  2. Adopt an Agile funding model. If $10 million is allocated to a project, the investors want to know what the outcome will be in a year. It’s hard to be Agile if your project does not allow for change.
  3. Revisit salary structures. Agile organizations are team-oriented; yet people are typically paid as individuals.
  4. Change your metrics. “Working software” is the greatest measure of success in Agile terms, yet software teams still measure success in terms of software bugs and lines of code.
  5. Embrace problems. Agile makes problems visible so people may blame Agile for creating problems. The problems were always there; Agile just made them apparent. When Agile points to a problem, use it to your advantage.
  6. Consider the limitations of your tooling. If you’re using tools that are 10 – 20 years old, they were not designed for Agile development and likely are getting in the way of your Agile efforts.
  7. Rethink your objectives. Since IT is considered a cost center, it focuses on reducing costs. Agile development is about increasing opportunity, not reducing costs. To increase opportunity, get the business on board. If you try to handle Agile development entirely from the IT side, your Agile efforts will show some improvement but you won’t get the full benefits.

Getting an entire team or an entire organization to embrace Agile is a challenge. There are people issues, cultural issues, structural issues, and managerial issues to consider, the effects of which may only seem obvious in retrospect. While the idea of being Agile is attractive, the actual process of becoming Agile can be hard work because there are many unseen obstacles to overcome.

The Mendix App Platform supports Agile development teams from the first sprint through continuous maintenance of their applications. Sign up to learn how Mendix can help your team adopt Agile.

The App Platform for the Enterprise - Build New Enterprise & Mobile Apps
in a Fraction of the Time - Get started for free!

  • http://www.pmhut.com/ PM Hut

    HI Lisa,

    Your first point: “Agile isn’t supposed to do this” stems from the fact that there is not standard definition to Agile. This is a big problem and it’s one of the reason that many companies are still hesitant to adopt this methodology.

  • hgeldenhuys

    I find that its difficult to compare waterfall methodologies against the the agile ones without defining context, as in the long run agile is more a value system than a framework for a rapid changing world (we move from a modern to progressively post modern world) in my opinion. No 1 recipe applies to all organisations, but the fundamental universals are still valid, like a “you dont know what you don’t know”, “self organising teams”, “embrace problems” etc; they guide more than dictate. One has to be both pragmatic and disciplined to asses where you are and where you want to go and apply the correct path to achieve the desired outcome. If no ideal approach is available immediately, we still aim for the ideal the best we can. There is however a fine line between the dogmatic and the pragmatic, its more often the dogmatic things that let the little things hold back teams, its the pragmatic idealism that gives room to the seemingly smaller things and contribute to success in the long haul, but this means change and change is uncomfortable. There are no silver bullets and common sense must prevail in the end at the expense of a comfort zone. I find that the “learn from others’ mistakes” above mentioned are very valuable pragmatic guidelines, without the expense of paying for that experience yourself, and helps the organisational change occur with less resistance. We need others’ slipstream.

  • http://agilepainrelief.com/notesfromatooluser/ Mark Levison

    @hgeldenhuys:disqus one of the things that people tend to overlook when looking at agile – its not intended to preserve the status quo. Its not intended to allow the current system to continue to exist. It is a tool to relentlessly examine your current system and force it to improve. Sometimes the issues it exposes are uncomfortable at that stage a good Agile coach/trainer/consultant will be accused of being dogmatic or theoretical.

    If your current state exists largely without change a year after you started Agile then something has been misunderstood.

Connect With Us