In a previous post we examined an “Agile pain points” survey that highlighted some of the top obstacles organizations are facing when trying to adopt Agile practices.  Now that these obstacles have been identified, you might be asking – as we did – where do we go from here?

The Importance of Agile Tools

We think these findings reinforce the need for ALM tools to support Agile implementation, accelerate adoption and build a foundation to scale Agile.  Developers need integrated, yet flexible and customizable toolsets encompassing Software Configuration Management, Build and Release Management and Agile Lifecycle Management.

Agile Roadmap

In addition to Agile tools, development organizations also need to adopt new approaches to support Agile. Here is a roadmap for organizations as they head down the Agile path:

- Take a fresh approach to capturing requirements. The first thing you should consider is that the focus of requirements in an Agile world shifts from developing a detailed specification, to collecting user stories.  Having a development process and the necessary tools to support gathering, tracking and managing of user stories is crucial when going Agile.

- Invest in test. Even when not practicing explicit test-driven development, the importance of testing – unit test, regression, and system-wide testing – is considerable throughout the Agile development process no matter what method is being used.

- Release early and often. Organizations should look for planning tools that track when user stories are done and ready for customer feedback, source code tools that show where user stories are in the development process, and build and release tools that create releases continuously.

- Build In-house expertise from the outside in. Organizations should work with vendors that have a full suite of training and coaching offerings, in particular seeking those vendors that go beyond generic Agile training and instead examine the organization’s existing processes and goals and customize training for their specific needs.

- Incorporate release aspects in early Agile plans. Building in real-world items like testing and deployment will allow issues to surface early, before they become entrenched in the code base and difficult to address.

- Recognize that scaling Agile reveals dependencies between projects and teams. Having the ability to track both Agile and traditional projects in the same tool interface can prove critical to ensure a smooth scaling out process.

- Don’t forget about requirements when going “all in” with Agile. Lastly, organizations should be sure tools and processes clearly show team members all key aspects of requirements and are flexible and powerful enough to keep pace with the dynamic nature of a fully realized Agile environment.

We’d like to hear what you think – what steps have you and your organization taken to support Agile adoption?  What have are some other steps organizations should consider?

For details on AccuRev’s findings and more on these recommendations, check out the full Agile Adoption Pain Points Survey report, available free for download at http://www.accurev.com/whitepaper/agile-pain-points-survey.

When talking about Agile development, people often ask me, “but why would I want to change to a new methodology when traditional development has made so much money and created so much value for so many people for such a long time? Why mess with success?” That’s a great question!

After hearing that question for the umpteenth time I finally realized something.  It isn’t traditional software development that has provided so much value! It is the software itself. Imagine calling a travel service prior to the advent of software. You call them up and say “I’d like 100 or so options for travelling from Boston to San Jose. I’ll also need a bunch of 3 or 4 star hotels in San Jose and mid-sized rental cars to choose from.  Could I get that in 5 seconds please?”

In today’s world, of course you just go to a site like Orbitz.  It isn’t traditional software that provides that value, it is the software itself.  It almost doesn’t matter what process you use to produce that software, the value is so high. When you are only competing against somebody that doesn’t have software, that’s one thing. When you are competing against other organizations that are also using software, then the exact process you use can make a big difference from a competitive standpoint.

What do we mean by “traditional development?” After having been involved in the process of literally thousands of software development organizations, I can safely say that there isn’t really any such thing as “traditional development” or even “waterfall.”  That is, if you look at any two organizations developing software, there is no standard for what comprises traditional development.

In the end, organizations adopt individual practices that make sense for their circumstances. This same approach can be used when adopting “Agile.” There really isn’t any such thing as “Agile.” It is a combination of values and practices which can be adopted by any organization and does not require wholesale adoption in order to provide value. Yes, there are packaged solutions out there such as Scrum, XP, Kanban and others, and they do provide value.  But so do the individual practices.  So, instead of thinking about “how do I switch to this new thing,” consider Agile as a new set of tools that you can add to your existing process on a case by case basis. Worry about “being Agile” after you’ve gotten some experience under your belt with some of the practices.

We recently produced a webinar here at AccuRev, co-sponsored by Rally Software, about the Top 10 Factors for a Successful Agile Implementation.  Number 7 addresses the question of a tools stack. Once Agile coaching and training is complete, now we can think about tools.

Agile manifest declares:  ”Individuals and interactions over processes and tools.”

But we believe that this statement doesn’t mean you should forget your tools stack entirely. It’s really about making sure that your toolstack helps facilitate those interactions between individuals.

So it’s no surprise to us that when we hear about people rolling out Agile, they don’t even consider upgrading any of their tools. Studies have shown that new teams that do not invest in Agile tool sets, automated testing and continuous integration, start to struggle around the 10th iteration (4-5 months). The backlog of bugs and to-dos become so great that teams have to stop what they are doing and do a “maintenance” iteration, where they do massive amounts of QA or stop and do code reviews for an entire iterations. If we think about it, this kind of seems like traditional development model doesn’t it? Are you really Agile if you can’t deliver something which is “done” after every iteration?

The problem? Your current toolstack was designed by people who had traditional development models in mind.

Your tools don’t actually facilitate shorter development cycles, they actually hinder you by getting in your way. Your tool stack shouldn’t be the impediment in your Agile rollout.

Lets start with an Agile project management tool. This is the obvious tool to replace in your stack. Converting your traditional issue tracking system to an Agile one will give you the speed and visibility to help your teams practice Agile on a day to day basis.

Traditional source control management systems also hinder the process by following a “waterfall” like model of isolating code changes and leaving them on branches. Most SCM vendors know this is a problem, which is why their solution for an Agile branching methodology is to consolidate branches, or have entire teams work on one branch. This doesn’t make sense. All of your scrum teams should be able to function together and in parallel, while integrating work together on a regular basis.

Smaller iterations mean a faster paced development cycle. Some of the tasks that you used to do a handful of times over the course of a waterfall will now be done on a weekly, sometimes daily basis. This is where continuous integration and test orchestration come into play.

While you’re moving through a 2 week iteration, using continuous integration and automated tests suddenly becomes extremely important. Having these processes in place can help you avoid the 10th iteration problem we talked about earlier. You’re not going to have 4 months to regression test the application by hand in Agile.

The idea here is that your Agile tools must help you build a testable, deploy-able app every 2 weeks like clockwork. You will repeat this process over and over. Isn’t it time your toolstack provided you with clockwork development cycles?

AccuRev is co-presenting a one-day seminar on Agile Development Transformation:

“Mitigating Risk with Agile Development: Great Software, Great Business Results.”

Where:10 Maguire Rd, Bldg. 1, Lexington, MA
When: Thursday, February 26, 9:30 – 3:30

Details and registration

Speakers: Rich Mironov (Enthiosys); Johnny Scarborough (GlobalLogic); Damon Poole (AccuRev)
Cost: $50 for qualified registrants ( List price $595 ). Seating limited to 50 attendees.

This one-day session will include detailed presentations, interactive exercises and open discussion on:

• Agile development approaches including distributed agile methods, the history of agile, and agile manifesto
• A detailed walk-through of Scrum, one agile approach
• The organizational changes required for successful agile adoption: executive commitment, cross-functional teams, and coaching
• Hear first-hand from one of your peers about how to bring about agile adoption and improved results.
• Roadmaps, releases, iterations and the iron triangle
• Business drivers, business value and customer collaboration approaches
• How to evaluate technologies when adopting agile

This seminar is intended for CTOs, Vice Presidents & Directors of:

• Software Development or Engineering
• Product Management
• Business Units

All attendees will receive free copies of two new books:

Scaling Software Agility: Best Practices for Large Enterprises by Dean Leffingwell
The Art of Product Management by Rich Mironov