Project Practitioners > Agile Adoption Pitfalls: Don't Forget the Tests!

Agile Adoption Pitfalls: Don't Forget the Tests!

By Brandon Carlson

Agile software development offers organizations an approach to software development that promises to deliver higher quality software faster than traditional project management approaches. As Agile gains popularity, more people than ever are attempting to use Agile to improve software project results. Unfortunately Agile transitions are full of gotchas and pitfalls, and I’ll be discussing one of them today: Ignoring Developer Practices.

Scrum is undeniably a leading process in the Agile space. It is an approachable framework that is easy to implement. The Scrum framework is pretty clear about it’s project management practices and intentionally silent about software development practices. Naturally many teams attempting to adopt Scrum for the first time focus entirely on the PM process and ignore changing their organization’s development practices. There is a problem with this approach. The technical practices are an enabling factor in sustained Agile development.

A simple example

Assume we are beginning a new project, it’s estimated to be about 24 months, and we’re optimistic that using Scrum will help us make the target date. We have elaborated and estimated the requirements into the product backlog and are ready begin our first iteration. We’ll start with 30 day sprints as that is the standard for out of the box scrum. Now, because we are doing Agile, we know that we don’t have a “design phase” so we pick up the first 10 stories and “start coding”. Thirty days pass and things are great. We made all of our iteration commitments and the business likes the progress they’ve seen. Looking at the burn-down charts things are looking good for our project. We spend the next couple of days performing our retrospective and planning for the next 30 days and promptly pick up the next 10 stories. Scrum rules! As several more iterations roll by, however, our velocity starts to decrease. Instead of doing 10 stories per iteration, we got 9. “It’s a fluke”, we say, “we ran into a couple of gotchas this iteration, but nothing to worry about. Shortly thereafter we only got 8 done. Management reviews the burn-down chart and sees that our 24 month Agile project is now up to 27 months. “What’s the problem?”, they ask, “I thought this Agile thing was supposed to decrease my project timelines not increase it!” Bob the Scrummaster springs into action and asks the team. “Why does our velocity keep going down?” “We’re having to do a lot of architectural refactoring to put new features in because the appropriate hooks weren’t designed in up front”, says the lead developer and “I’m finding a lot more defects lately”, says the QA analyst. The team decides that in order to correct the situation they’ll be “more careful about testing”. The next several iterations pass by with no increase in velocity, only another decline. Agile is now being perceived as a failure because “if we would have talked about the system architecture and design up front, we wouldn’t be having these problems now”. In the organizations mind Agile is a fad that is driven by “cowboy developers” who don’t have any discipline.

What went wrong

It’s simple really. As the codebase grew, the ability to thoroughly test the code each iteration diminished. When new features were added that required changes to core elements of the system, there was not a reliable regression system in place to ensure that the new code didn’t negatively impact the rest of the system. Developers, who are focused only on their sprint deliverables, don’t test the other modules in the system, and QA who by this time has about 75 features to test, in addition to the 8 from the current iteration.

By ignoring developer practices such as Test Driven Development (TDD) and Acceptance Test Driven Development (ATDD), the process was missing a critical feedback loop. Automated testing catches regressions in the codebase earlier, often during development, when they are cheaper and much less time consuming to find and fix. TDD and ATDD are not easy to implement and will cause an initial drop in productivity. Given time, however, these techniques definitely pay for themselves by reducing regressions and increasing the overall quality of the system under development.

Don’t forget the tests

If you decide to take the leap into implementing Scrum at your organization Don’t forget the tests! It will make for a higher quality product and enable a sustainable Agile transition.

Related Links
How many bugs are too many? That depends on how serious they are. Software Quality Release criteria help the team determine how software quality will be judged at different development stages. It may help some teams to have a formal bug fix WBS for training or to model best practices. A Master Test List can insure that important tests aren't forgotten in the heat of the deadline push.

Not all comments are posted. Posted comments are subject to editing for clarity and length.

The comments to this entry are closed.

©Copyright 2000-2017 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail
Terms of Service and Privacy Policy

Stay Connected
Get our latest content delivered to your inbox, every other week. New case studies, articles, templates, online courses, and more. Check out our Newsletter Archive for past issues. Sign Up Now

Follow Us!
Linked In Facebook Twitter RSS Feeds

Got a Question?
Drop us an email or call us toll free:
7am-5pm Pacific
Monday - Friday
We'd love to talk to you.

Learn more about ProjectConnections and who writes our content. Want to learn more? Compare our membership levels.