5 reasons you’ll love to hate agile development

If agile development were easy, everyone would be doing it. Or at least doing it better.

On October 18th AgilityFeat CEO/Founder Arin Sime (that’s me) is presenting at InnovateVirginia on «5 reasons you’ll love to hate agile development.» In this talk I go beyond the hype about faster and more efficient software development teams and present five areas that I have regularly seen teams struggle when shifting to agile development. This is based on my experience as an agile coach to many companies, as well as our own experiences within AgilityFeat doing offshore agile development for our clients.

The slides from my presentation are below, and in this post I’m going to summarize the 5 reasons.

Here are the five areas that I focus on in the talk:

1. pair programming
2. test driven development/automation
3. manual testing patterns
4. complex branching/release streams
5. iterative architecture/design

These are all all areas that teams new to agile development struggle with. In each area, your team may or may not reach the agile ideal, but you should at least give it a shot and not say «that will never work here.»

#1 – Pair Programming

Managers fear that pair programming adds to their salary expenses by having two people work on the same thing at once, and some developers are reluctant to do it because they don’t like being that close to other people. Pair programming though results in higher quality code with fewer defects, and defects are much more expensive to fix than getting it right the first time. Here are my Code Commando tips for how to tackle pair programming:

• Require two people to sign up for every user story
• Or only require pairing on certain user stories
• Allow “me time” daily
• Enforce pair programming most strictly on difficult or risky changes and with new team members
• Use a sign up sheet and rotate pairs daily or on stories

#2 – Test driven development/automation

Test Driven Development is very powerful, but can be hard to get going on. Managers fear that it will slow down development, developers worry about maintenance of fragile test suites, and testers worry that the testing will not cover be comprehensive. But smart automation of happy path scenarios can enable more rapid deployment cycles and less time testing the standard scenarios. Here are my Code Commando tips for getting started:

• Start with “Manual” TDD – write acceptance criteria
• Leave legacy code behind
• “Cover and Modify” as you enhance legacy code
• Focus on unit tests first
• GUI level automation should focus on just a few paths that cover large sets of functionality

#3 – Manual Testing patterns

Manual testing is still necessary and valuable on agile teams – automation won’t cover it all. But traditional testers worry about whether they can effectively test stories if code is being deployed to production every week or two, and they fear releasing bugs to production because they didn’t have time to do comprehensive regression testing with each release.

Here are my Code Commando tips for handling manual testing:

• Enforce small user stories!
• Developers deliver highest value stories first in the sprint
• In-sprint testing focuses only on the stories at hand
• Use the beginning of the next sprint to regression test before deploying the current sprint
• In-sprint bugs are communicated, not tracked

#4 – Complex branching/release streams

Before the advent of better tools like Git, merging code branches was the bane of every developer’s existence. Even with Git, it can still be more trouble than it’s worth if you don’t manage code branching well. Because agile teams release to production frequently, and they still have to manage parallel projects that may take multiple sprints before it is production ready, developers need a smart branching strategy. This section of my talk really benefits from looking at the slides above, or by reading a past blog post I wrote on this topic.

Here’s the reader’s digest version though of how Code Commandos should branch:

• Sprint and Hotfix branches should have a short lifespan
• Epic branches should be merged into regularly to stay up to date with latest sprint work
• Set clear policies for where branches are merged from
• Use demo’s as a checkpoint to agree that a sprint branch is ready to send down the release path, and rotate who will handle merging tasks

#5 – Iterative Design & Architecture

The biggest complaint people have about agile’s emphasis on short iterations of work is that teams get so heads-down focused on small changes they will lose focus on the big picture. In this storyline, visual design and UX will look hacked, and the technical architecture will deteriorate over time. These are legitimate concerns with an inexperienced team who looks at agile as a license to hack, but these concerns are easily fixed with those who are mature enough to balance short term fixes with long term goals and design perspectives.

Here are my Commando Tips for how to balance iterative design & architecture on agile teams:

• Write all documentation “just in time”
• UX/Visual design can work a sprint or two ahead at most
• Design documents should start as whiteboard photographs, and stay there until needs require more.
• Use pair programming to enforce coding standards

Agile development is hard – and worth it

Why go to all this trouble? Software development in general is hard, but if there is anything that the agile movement has taught us it is that receiving customer feedback as soon as possible is crucial, and deploying code in small chunks mitigates risk. The agile development practices we’ve discussed here are not always easy to do, but at least taking baby steps in their direction will make it easier for you to deploy code frequently and reap the benefits of truly agile teams.