Although we don’t play favorites when it comes to dev methodologies, you can’t deny the benefits of Agile development.
The ever-popular approach has helped countless companies increase flexibility within their organization, and thus develop better, more intuitive software.
However, there are ways to do an Agile project all wrong. David Taber, of CIO, recently published a list of the top ways to blow up an Agile project, which he says can make even the best Agile team melt down.
So what are the ‘worst practices’ for Agile development? Here’s a look:
1) Use The Element of Surprise
“The agile effect comes from trust (through a team that’s deputized and empowered to make key decisions on its own), as well as close communication and relentless focus on the highest-priority goals. Surprise the team with new mandates, unstated top priorities, an uncertain budget, political cross-fire or just a simple lack of trust and it’s hard to imagine anything more damaging to both morale and productivity. Surprise your team and watch it melt.”
2) Don’t Put Your Best Players on the Team
“One thing’s for sure: The folks who conspired to write The Agile Manifesto are smarter than the average bear. Way smarter. Agile tends to work best when you have users who are articulate and know their business processes cold. Effective agile developers are usually wicked smart.
t’s not just soloist brain-power, though. The team members must respect each other. If they don’t, communication will not be quick and smooth. In my experience, location matters, too. It’s best if team members are within shouting distance, if not in the same room, while it’s almost impossible to have great productivity if the team is spread across multiple time zones.”
3) Use Politics for Leverage
“You know the drill. Find and emphasize Catch-22 situations, exploit optics and rhetoric, use budgetary threats, shuffle the team, promote and demote people randomly, install a Czar—preferably someone who knows nothing about software but is an I’m-in-charge-here, get-it-done, take-no-prisoners kind of guy—then lather, rinse and repeat. These steps work wonders to show your power, and to break down internal trust and external communication.”
4) Don’t Give Team Access to Test Resources Until Beta
“What could be duller than testing? Seriously, the continuous building and changing of agile software makes testing an endless chore for the users and a bore for the compliance guys. Besides, the test labs can’t afford to be available all the time.
You’ll hear these kinds of arguments. You have to overrule them. You don’t have to be a card-carrying member of the test-first crowd to know the economics of software defects: Catch them early and fix them cheaply. Here’s the agile answer: If you test throughout the project, you won’t need a beta at all. The software will just migrate into production when it’s ready.
5) Accel erator-Brake, Accelerator-Brake
“Agile lets developers and users innovate fast and become high-functioning teams. This depends upon continuity of effort and objectives. Sure, detailed priorities shift continuously—but if the global purpose of a project jumps around, the good effects of agile will never take hold.
The same is true if there are interruptions of more than a couple of weeks, as the flywheel never really gets going. Remember: Continuity matters. Due to a number of human factors, restarting an Agile project that’s been stalled for a month is almost worse than starting from scratch.”
Read the rest here>>
As Taber highlights in worst practice #4, beta testing isn’t the right time for testing… and overlooking QA is a sure way to demolish your Agile project. In fact, if testing is done correctly (beginning early on, and done continuously) a beta test won’t be needed at all.
In an Agile setting testing needs to be incorporated into each step of the process, not just at the end of each major release. Real world QA done throughout each step of development, paired with the lab testing that Taber mentions, can help dev teams avoid costly bugs and mistakes. It also keeps the bugs out of the hands of the application’s users, unlike a beta test. After all, you don’t want to expose your user base to a buggy product. But as you can see from Taber’s mistakes to avoid, the challenges don’t end with testing. Planning for Agile, documenting and organizing Scrum meetings quickly while maintaining an Agile environment requires a unique approach where all the key players are involved and on-board.
Agile development has great potential to help teams quickly and efficiently produce higher quality software – but it has to be done right.
For more best practices on adopting Agile, download this free whitepaper: Ten Tips for Understanding Agile Development and Making it Work for You.
What do you think is the biggest challenges in adopting an Agile development approach? Let us know in the comments section.