This week I spoke at both ‘Agile Comes to You‘ seminars in Santa Clara, CA and Costa Mesa, CA. Sponsored by the Agile Journal and Software Quality Engineering (SQE), these events bring together AccuRev, Rally Software, Urbancode, and BigVisible to share stories and best practices when starting, managing, or scaling Agile teams.
David P Thomas - Costa Mesa - 115 attendees
Best of all, the 2nd half of each seminar is dedicated to demonstrating the latest software tools on the market to support Agile teams.
As a software engineer by trade, I’m always looking for reusable patterns. With a focus on software development (and given a 20-min timebox ;) I discussed and demonstrated the following three (3) patterns suited for Agile teams.
Task-based Development – When it comes to tracking software changes, traditionally we focused on specific file versions, revision numbers, or commit transactions. In this manner, you have to track the sets of files or the non-sequential, often multiple, commit transaction IDs, respectively. This is horribly manual, fraught with error and even when using BugId in the commit comment, is only a reporting tool at best. With Task-based development, you want to abstract those details and work at a higher level — a level where you don’t care how many files, how many commit transactions, or even how many people worked on a task (but you do care -who- did -what-). Rather, you want to track changes as a logical unit of work, or a Task. AccuRev’s change package facility ties directly to your agile project management (e.g. Rally) or issue tracking system (e.g. Jira, Bugzilla, etc) and associates the tasks/issues/defects to a working set of files. You can promote as many files, as many times, from as many people and AccuRev tracks the working set. Furthermore, beyond just reporting, the change package can be delivered as a whole unit to other baselines (e.g. bugfix releases, customer specific releases, future development lines, etc).
Workflow and Multi-stage Continuous Integration – The most important aspect of workflow (IMO) for Agile teams is ‘just enough’ stabilility. While agile teams innately desire to integrate with other teams, early and often, you still need to provide a buffer – especially if you have follow-the-sun development. For example, without a Team-level buffer, a single commit from one contributor can destabilize multiple teams. With a good workflow in place, teams can co-integrate on the order of hours or days and, most critically, know that the integrated changes are “good.”
David P Thomas - Costa Mesa - Sharing Experiences
The idea is to organize teams such that if someone breaks the build, they only break it for their team — not other teams. If a team deems their changes worthy, they can share with all other teams. Determining worthiness of a change is the job of Continuous Integration (CI). You want to be running CI not only at the shared integration area for all teams, but also at the individual team level. The value of multi-stage CI is that changes are validated at a lower level before they progress to a higher level. Also, the amount or rigor of testing at a lower level may be less than at a higher level, especially if test executions take hours or days to complete (e.g. full regression or performance tests).
The concept of moving changes along a workflow isn’t new. Traditionally….changes on a team branch get merged to a shared integration branch. Those changes get merged to a QA branch, etc. The root problem here is using branches… as each branch incurs manual merging. Instead, AccuRev uses inheritance-based streams that allow changes to implicitly flow from parent stream to child. The parent-child nature of streams lets you build an n-level promotion hierarchy from child to parent where individuals are at the leaves of the tree, organized by team, combined at the team-of-teams level, then queued for end of iteration review. As changes are promoted up the tree, they automatically flow down to corresponding children. This is a beautiful combination of stability and continuous [team] integration.
Private Sandbox - With the spotlight on the team, we can’t entirely forget about supporting the individual contributors. Private sandboxes are an individual’s cornerstone for sanity. By tracking private commit of file and directory changes, savepoints are marked that can be compared over time or even reverted back to if a current task is deemed out of scope. The sandbox is also tracking refactoring and namespace changes. For example, in Java, if you move and/or rename a class, that will likely impact an entire set of files that import the original (unless you are lazy and use import * :) It is important to track these changes privately especially if you ever need to revert back —the entire set— to a previous state… all without impacting anyone else. Private sandboxes should also store those changes on the server thus minimizing the requirement to manage, backup, or lose sleep over a given development machine.
It was hard choosing only three (3) patterns but those are the ones I see frequently in practice. Of the set, I am particularly fond of Task-based development as very few tools support this and it is vital to tracking, delivering, and reporting on logical units of work, rather than just sets of files.
I really enjoy participating in these seminars and especially meeting new folks. I encourage anyone involved in software development to attend one of these seminars. They are a great networking event and you get to see some of the latest software in action!
