Top seven ways to ruin an Agile or Scrum project

#1 Waterfall by any other name…

Performance Test Manager Mark Yarbro described what he thinks most software dev teams are doing when they claim to be doing Agile. “In Scrum, you have a bunch of people sitting around in a meeting, picking things off the backlog, starting to give estimates, and the developer’s just making stuff up, and the QA guys are just copying what the developers are saying. After a day or so of that, it’s all story pointed out, so then they all start hammering out code. QA’s sitting there, writing some test cases, but really waiting for the code to be delivered. So a week or two into the sprint, code starts being given to the QA folks, they’re starting to test things, Development is sitting around waiting. They’re planning the next sprint, pulling more things off the back log and figuring out what they’re going to be working on next. You know what that is? That’s Waterfall. You’re doing four week waterfalls. That’s RAD (Rapid Application Development). That’s what most people are doing when they call it Agile.”

#2 Feedback doesn’t happen when it should

In the perfect world, the end user or true customer would be sitting in from the very first meeting. Sadly, that’s rarely the case. That means there are always assumptions being made. Satyapal Chhabra, Founder and Managing Principal at Ideliver, highlighted this problem. “If you have continuous sprints, when does the real end customer start participating? Probably sprint eighteen or nineteen. That participation is the fundamental premise of Agile. But it doesn’t happen.” Mark agreed, “They should be there from the start.” In his experience, teams end up using proxies to stand in for the customer, with predictable failures in their ability to correctly predict what the customer really wants.

Enterprise Agile Coach Jay Packlick pointed out that, if there is a known lack of information, Agile must adapt to take the missing knowledge into account. Obviously, the later the customer becomes involved, the longer it will take to identify and satisfy their requirements. This is a common cause of cost and budget overruns in Agile. “Here’s where things go wrong. They have a situation where the customer isn’t going to be available until sprint nineteen, but they don’t solve the problem of ‘What am I going to do to get feedback?’ That’s a failure in one of the core principles of Agile which is to change your approach so that you solve your problem. You inspect and adapt. You have to change the system, or they will go on for months and fail. I don’t care what process you’re doing. If it’s not working and you don’t change it, it’s going to fail.”

#3 Agile documentation is almost always atrocious

According to Mark, who worked in Agile shops for many years, it’s easy to get carried away with the rush and bustle of Scrum and not pay attention to sustainability. “In daily standups there aren’t supposed to be any status updates. No ‘I’ve been working on…’ only what you’ve accomplished, what you hope to accomplish, and any impediments to getting that done. Accomplishing things constantly is the fuel that keeps Agile working. Otherwise, it’s a grind. But it’s also used as an excuse not to do any documentation. Enterprise needs to think bigger. The actual development is the tip of the iceberg. The maintenance is what’s under the water.” He described organizational amnesia that results when developers move on and there is no one left who remembers the details of the code. Greater accountability is a must. “Pure Play Agile doesn’t take into account that what gets done isn’t what’s expected, it’s what’s inspected.”

#4 Agile testing often stinks as well

Not only is there a serious shortfall in documentation, but testing throughout the project often suffers from lack of attention. Mark commented again, “Agile needs to have better testing. To make things work, you need QA people who are developers and developers who aren’t afraid of testing.” Quality Management specialist Brian Bernknopf agreed. “You can’t have an Agile SDLC with only Agile development where you’ve got devs working on stories and QA working on releases. Other traditional QA responsibilities may change, but you still need governance. In daily builds, what type of testing is going to happen at check-in? How do you know if those are the rights tests?”

Unfortunately, many teams haven’t figured out how to make things work when they go Agile and QA often gets sidelined. That means they need to regain a seat at the table, even if it’s in a different chair. “It’s a changing role. They need to be able to sit inside a Scrum and jump in and solve a problem. In a similar way, Developers need to be able to help write a test script. In an agile project, QA is a role and not necessarily a person. You could have a developer with a QA mindset in that position.”

#5 Key stakeholders become less involved over time

Agile is not a free for all. It requires discipline. Shreyas Batt, Cofounder and CEO of FusePLM, found that out the hard way. His team’s recent project thankfully did not fail, but it certainly took longer than planned because they weren’t consistent about following the rules. In this particular case, working with an offshore development team added logistical and time zone issues to the mix. “We had weekly meetings. But over time, the project manager or Scrum manager was sometimes not available. Then it was just a bunch of devs but no one to guide them and keep them on track on their side. On our side, we weren’t privy to the internal planning. You need the right people on the call.”

#6 Demos become optional instead of mandatory

Failing to prioritize the Agile structure and ensure constant feedback and communication proved to be an error for Batt’s team as well. “We took their word for what was going on. It didn’t give us a good picture. We didn’t want to micromanage, but to have insight into progress. At the start, we would have a demo each week. Later, we didn’t enforce that well enough. They told us what they were doing but didn’t actually deliver the code for testing until eight weeks later. That’s when we realized they didn’t understand the requirements. Agile enforced correctly would have really helped.”

#7 The desire to go Agile is fuzzy

Jay revealed that the first issue he seeks to help resolve with organizations is figuring out what they actually need to change. Most of the time, the people he speaks with aren’t actually certain. “That’s the first problem. They want to do something but aren’t clear about what outcome they really want.” Then comes the challenge of figuring out if changing to an Agile methodology can actually happen. “You have to determine who is the locus of control or the champion. Sometimes, nobody within the organization is a champion, it’s unclear, or the person isn’t acting to lead that change.” The right conditions for change must be met and the right people must have an appropriate level of involvement. Otherwise, trying to do an Agile project in a traditionally Waterfall culture simply won’t work—and the project is ruined before it even begins.