What is Agility? Summarizing from last month's article  Agility is “the ability to both create and respond to change in order to profit in a turbulent business environment…. What is new about agile methods is not the practices they use, but their recognition of people as the primary drivers of project success, coupled with an intense focus on effectiveness and maneuverability.” Achieving agility while avoiding unproductive thrashing of the project requires high quality communication and tight feedback loops between competent team members and with project stakeholders. This allows the project team to iteratively grow the product architecture and functionality despite ever-changing customer requirements and priorities. Projects employing agile methods share the following key characteristics:
- Adaptive – plans, designs, and processes are regularly tuned and adjusted to adapt to changing needs and requirements (as opposed to predictive methods that attempt to develop comprehensive and detailed plans/designs/requirements “up front”).
- Goal-driven – focus on producing end-results (working functionality) in order of highest business value/priority . “Agile approaches plan features, not tasks, as their first priority because features are what customers understand” . (as opposed to being document-driven or risk-driven)
- Iterative – short development cycles, frequent releases, regular feedback
- Lean – simple design, streamlined processes, elimination of redundant information, and barely sufficient documentation and methodology
- Emergent behavior – quality systems (requirements, architecture, and design) emerge from highly collaborative, self-organizing teams in close interaction with stakeholders.
What is Agile SCM? One recurring theme from last month's issue () is that the key to understanding how to make SCM "agile" is recognizing SCM processes and practices must embody the agile values and principles in order to support and enable the characteristics of agile development. SCM processes and tools must eliminate bottlenecks in feedback cycles by:
- Easing up on rigid front-end controls to focus more on tracking and accommodating change rather than striving to prevent it.
- Eliminating redundant information and artifacts to focus upon the effective flow of communication
- Coordinating and streamlining development changes and communication, and …
- Automating back-end integration/build/test activities, increasing their frequency, and incorporating them into daily development tasks
Who are these people and why are they writing about Agile SCM? We are Brad Appleton, Steve Berczuk (Steve B.), and Steve Koniecza (Steve K.). As Steve Berczuk and Brad Appleton were initiating discussion and researching new ways to enhance the documented patterns of SCM, they ran into Steve Konieczka who was researching and initiating discussion on the characteristics of SCM for the Agile Community. Both Steve B. and Brad had a natural interest in Agile in other areas of their careers and happen to believe that SCM is a key component to effective agile development. Once we crossed paths, we saw a common ground and decided to collaborate together on the topic of SCM and how it can provide agility to development teams.
This column is the result of our collaboration and we welcome input from the community. Our intent is to further discussion on the topic of SCM and ways that SCM can help development teams become more agile. This particular article is an introduction to who we are and concludes with comments on what to expect from the column in the future.
Steve Berczuk - SCM "Sympathizer" and Agile Practitioner
Early in my career I observed the power of software configuration management (SCM) appropriately applied. I was part of a Boston area development team that was collaborating with a group at the parent company's home base of Rochester, NY. As you can imagine, the issues regarding how we would manage the source code spanning the range from the technical to the social to architectural. Some of the issues that we had to resolve were:
How to set up a distributed source management system; Because of network issues we needed to keep parts of the repository close to the group that was primarily responsible for them. We also had to come up with a build mechanism that worked at the moment and that was easily adaptable as the project components changed.
What sort of check in and testing policy would work for both our team -- where most people were used to rapid changes -- and the other team -- which had a more staid, corporate, approach) and …
How could we divide the work