Agile 2010 is fast approaching, and AccuRev is excited to sponsor and support the Agile community involved with this conference.  However, our excitement is partly due to the fact that Damon Poole, AccuRev’s CTO, was chosen as a featured speaker for not one, not two, but three sessions during the conference week.  I sat down with Damon to chat about his Agile 2010 plans, the ideas behind his session topics, and ultimately, the unrelated topic of my recent exposure to Star Wars.

Star Wars aside, Damon has some great talks about Agile development and components planned for Agile 2010.

Damon’s Discussions on Agile Development and its Various Components

Damon’s first Agile 2010 session will take place on Tuesday, August 10^th at 1:30 PM and is titled “Scrum and Kanban- Like Chocolate and Peanut Butter.”  Here Damon proves Scrum and Kanban are not in fact mutually exclusive, but play well together, much like chocolate and peanut butter.

KE: “So Damon, how did you come up with the chocolate and peanut butter concept?”

DAMON: “I have witnessed infighting within the Agile community, between Scrum advocates and Kanban advocates.  Agile is a way of thinking, and the community wins when there is a synergy between camps.  I want people to recognize that not only can Kanban and Scrum co-exist, they can actually be a very beneficial combination to development teams.”

KE: “Who might this session be best suited for?”

DAMON: “I would say this session is for folks that are already doing Scrum and are curious about Kanban.  I will address Kanban basics, how Kanban can help with real-world process problems, how to apply one-piece-flow to Scrum, and the value of work-in-progress limits applied to Scrum.”

KE: “Since it’s about chocolate and peanut butter, will there be Reese’s?”

DAMON: “You bet.”

__________________________________________________________________________________________________________

The following afternoon, Wednesday, August 11^th at 1:30 PM Damon will present “Getting Managers and Agile Teams Out of Each Other’s Hair.”

KE: “This sounds like an interesting Agile pain point that lots of us can relate to.  How do you approach this topic?”

DAMON: “Well, one of the most talked about, but least understood components of Agile is the ‘self- organizing team.’ There is little research published on this concept and I spent a lot of time looking outside of software development for information and advice on self-managing teams.  I came up with new perspective on this concept by examining external roots of the practice.  What it is, what the benefits are, how it works.  I will share my advice on manager roles and responsibilities, aspects of self-organization enabled by multiple Agile development components, and challenges that teams face.  It should be a good session, I have given it before and it’s always well-received.”

_______________________________________________________________________________________________________________________________________________________________________________________________________

The third day with Damon is on Thursday, August 12^th at 9:00 AM. He will present “Managing Growth Pains on the Way to 40 Scrum Teams”

KE: “Forty Scrum teams is getting up there.  How would you recommend managing such large amounts of teams?”

DAMON: “You’re right, 40 Scrum teams is the sign of a large organization.  I have interacted with lots of large Agile shops that operate with many more than 40 Scrum teams, and noticed issues with Agile weren’t all that different from shops with smaller teams.  By recognizing trends and patterns sooner than later as the organization becomes deeper involved with Agile, teams can start following certain practices to eliminate issues.  When it comes to addressing issues, the sooner the better.

KE: “What best practices have you recommended to larger-sized Scrum teams in the past?”

DAMON: “Multi-stage Continuous Integration, small story size, collocation, cross-functional teams… a few more.  This is a good session even if your organization doesn’t have 40-something Scrum teams today.  It teaches you about growing pains and prepares you for future growth.

Well, Damon sure sounds like he has a busy week lined up at Agile 2010.  Make sure to check out his sessions- they are featured on the Agile 2010 schedule and under the “What’s Hot” tab in the Agile 2010 app for iphone and Droid, so don’t forget to add Damon’s sessions to your schedule via these apps!

Follow AccuRev on Twitter @accurev for Damon’s latest updates from Agile 2010!

More Agile resources

AccuRev is hosting a free Webinar on “Emerging SCM Best Practices for Agile Development” on Thursday, February 5 from 1:00 – 2:00 PM EST. The webinar will introduce the unique demands that agile processes place on legacy SCM tools and ways to build and automate an efficient Agile development process. Damon Poole, AccuRev CTO, and Uttam Narsu will be presenting.

Mr. Narsu, an industry expert on software configuration management (SCM) best practices and former Forrester/Giga analyst, will discuss the most important aspects to consider when applying SCM best practices to an agile world.  Mr. Poole will discuss how Multi-stage Continuous Integration can solve some of the underlying impediments to a successful Agile development environment.

“SCM is critical to Agile success. If your SCM tools don’t provide integrated and seamless support for Agile, you won’t get widespread adoption of Agile development,” said Narsu. “Development teams require brutally efficient SCM tools, but the tools must still be issue-based, must have support for flexible process models, and enable efficient branching, merging, and refactoring. The SCM tool should also provide private workspaces and assist continuous integration.”

Mr. Narsu has worked with hundreds of clients using wildly differing software development environments. While clients who succeed with agile development have strong SCM practices, the best practiced agile SCM: transparently integrated, flexible, and collaborative.

Specific topics discussed will include:

• Typical SCM obstacles to Agile success and how to avoid them;
• Key Agile Process requirements for SCM products and specific use case scenarios;
• Challenges with continuous integration, and how Multi-stage Continuous Integration delivers value and how to adopt it today; and
• Key SCM metrics for delivering on Agile development goals.

Register here for this free webinar taking place on Thursday, February 5th from 1:00-2:00 EST: Emerging SCM Best Practices for Agile Development.

I work for a large software company, and we’ve used AccuRev to facilitate using a large scale distributed Continuous Integration model.

AccuRev makes this possible with the Stream approach to managing different codebases.  Developers run builds using the same build scripts used by the core team for production builds that ultimately are packaged and shipped out of Engineering.

These build scripts not only build and package and kit the product, they also run thousands of xUnit tests written to run fast and fail fast.  Developers that encounter failures immediately know where to fix the code to pass the tests.  We also use test driven development.

Each day, developers promote their changes to a task stream.  We use Scrum, so a task stream correlates in most cases to a Scrum team.  This team runs automated builds / tests at their task stream level and when stories are done and accepted and passing, promote the appropriate changes to the integration stream.

The integration stream is built every afternoon, and any test failures run during the build are quickly addressed by the team.  Our Continuous Integration software provides a failure email with the modifications made that day with AccuRev user names.  Developers can then go into AccuRev using the StreamBrowser and the Version Browser and determine the root cause.

Fixes are then promoted back to the integration stream, and the full nightly build in most cases runs successfully.  We fail all integration builds on test failure as we believe in Continuous Integration.

Each week our qa level stream is built and we repeat the same process. Developers handle the promotes, the central release team does not promote code for teams.  As code promotes up the hierarchy from task to integration to qa the frequency of broken builds, due to test errors or compilation, decreases.

This Multi-stage Continuous Integration approach is easy with AccuRev due to stream inheritence.  If you used a branch / merge solution you would need to staff a central team just to manage the commits to source control, and manage code that is “done”.

Yesterday I was a panelist for a Webinar on agile tools, focusing on software configuration management (SCM), build and software process automation (SPA), the latter term referring to the set of defined, repeatable and measurable automated development workflows that engineers use to transform requirements into shippable software products. Contrary to what I’ve read about the disdain that some agile devotees have for tools, most of the attendees were hungry to know what features their SCM tool should have in order to support agile software development and SPA. Here are some of the highlights, and of course, my take on why I think AccuRev is the best tool for agile software process automation.

There are five key feature areas that an SCM tool needs to support in order to be ready for agile:

* Support for flexible process models

* Continuous integration support

* Support for issue-based development

* Efficient branch and code management

* Private version controlled developer workspaces

Let’s take a look at each of these in turn.

* Support for flexible process models. Agile is often one of several processes being employed within a software development organization. Unless your SCM tool is flexible and process-neutral, you will have a hard time implementing agile (say, for product development) and more traditional processes like waterfall (for example, for product maintenance work) in the same SCM tool. AccuRev streams are a natural way to model any process, and thus are a good fit when agile needs to coexist with other development processes. As for software process automation (SPA), AccuRev streams again are a great fit, since they enable users to model any arbitrary stages of code transformation that a development team sees fit to define as part of their process. By adding triggers and workflow to a stream hierarchy, teams can implement SPA directly in AccuRrev.

* Continuous integration support. Continuous integration is one of the core process elements associated with agile development. By building and testing frequently and acting on the results of tests, teams can uncover defects or test gaps earlier in their development cycle, saving time and money compared to such discoveries late in the cycle. But continuous integration goes beyond just testing the nightly build. With multi-stage continuous integration in AccuRev, code is automatically promoted up the stream hierarchy into more stable configurations as it passes tests. At each stage, continuous integration takes over to build and test, typically with a wider scope of testing as the code nears the release stage. Legacy SCM tools make this type of automated integration factory somewhere between difficult and impossible due to the complexity involved in setting up the hierarchy and in automatically moving and merging code as it flows up the hierarchy.

* Support for issue-based development. Apparently there is a lot of contention about the need for filing issues and defects in agile development. This has puzzled me greatly. While I’m in favor of developers identifying and fixing issues as they are discovered, you lose valuable process information when a defect or enhancement ticket is not filed and later associated with a code change. Without an issue that describes what the problem was, someone looking at the code changes for audit purposes or for group code reviews is at a disadvantage. Why was this code change made? Is it related to other changes? How long did it take? Was it done to fix a bug or to add a feature. In AccuRev, issues either in the integrated AccuWork issue tracking system, or in a 3rd party issue tracking system, can easily be associated with code changes via the AccuRev Change Package mechanism. This establishes basic traceability between issues and the code changes that developers make in order to satsify the requirements of those issues. Issue-based development is well-defined, repeatable and measurable – all hallmarks of good software process automation.

* Efficient branch and code management. Any time you’re working on more than one project, you need to isolate that project’s code from other projects. With agile and multistage continuous integration, even a single project requires multiple code lines in order to separate in-progress code from unit tested code from system tested code that is ready for release. If an SCM tool makes branching, merging and labeling difficult, teams tend to practice branch avoidance, which I sometimes like to call “fear of branching.” This is a classic example of letting a tool dictate what processes you can implement. In AccuRev, streams replace branches as the mechanism for isolating codelines. Since streams are represented inside of AccuRev as data separate from the actual file versions, creating streams is fast – really fast, like, a second or two – and managing a system with hundreds of streams spanning multiple projects and processes is easy.  For continuous integration, AccuRev snapshots and time-based streams are also fast and easy to create and manage, and give users a straight-forward way to “label” an interim or milestone codeline without having to place markers in thousands of source files.

* Private version controlled developer workspaces. Software developers are the heartbeat of any engineering organization. Executives at any development shop will tell you that hiring talented engineers and keeping them well-tooled and productive is the single largest challenge that they face. For agile, this is even more of a challenge, since coding cycles tend to be shorter, and thus anything that gets in the way of individual or team productivity tends to have a greater negative impact on the project. Private version controlled workspaces like the AccuRev workspace model improve productivity, since they enable developers to work in isolation (while they are ‘heads down’ coding). Private workspaces in AccuRev also give developers full SCM capabilites in their workspaces without the need to share in-progress code prematurely. By using the ‘keep’ operation, developers make safe copies of their work in the AccuRev repository, and later can ‘promote’ the code to an integration stream to combine their work with that of their teammates. Individuals are more productive in this way, and if continuous integration builds are frequently testing the integration stream, so are teams.

In a nutshell, agile requires tools, and these tools need to support different modes of operation than with other processes. SCM can help or hurt you in setting up and executing an agile process, so these guidelines are a way to help you get your SCM tool ready for agile - easy of course if your tool is already AccuRev!

If you’re interested, you can view the webinar recording.

Is Your Software Development Environment Agile-Ready?
Free On-Demand Webinar