Agile Configuration Management Environments

Agile Configuration
Management
Environments
Brad Appleton
Chicago SPIN, 4 March 2004

4 March 2004 Agile Configuration Management Environments
© Brad Appleton, Steve Berczuk, Steve Konieczka
2
Agenda
 Part I: Background
• Agility and SCM?
• What is Agility? Achieving Agility
• Agile and Lean Values & Principles
• Agile Development Characteristics
• What is SCM? What SCM does for you
 Part II: Agile CM Environments
• What is Agile SCM?
• Agile SCM Characteristics
• SCM for Agile Methods
• Putting it all together!
• Agile SCM and the Agile Manifesto

3
Part I: Background/Foundation

4
Agility and SCM?
Isn’t “Agile SCM” an oxymoron?
 Many regard SCM as a process-heavy thing that
impedes the "real work" of development
 For many projects, SCM does get in the way
• Some overcompensate by evading and avoiding
tools and practices that can help, out of fear that
SCM process is inherently limiting.
 Others want control and have so much process
around SCM that they hurt themselves.
The “right” amount of SCM is appropriate in
agile projects!

5
What is Agility?
 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.
-- James Highsmith, Agile Software Development Ecosystems

6
Achieving Agility
Responding quickly & effectively to change requires
minimizing the following:
 The cost of knowledge-transfer between individuals
 The amount of knowledge that must be captured in intermediate
artifacts
 The time between making a project decision, and exploring its
results to learn the consequences of implementing it
In essence, reduce the time and cost of human learning
activities for effective knowledge exploration,
acquisition, transfer, and capture/codification
 Close collaboration and frequent iteration are critical for success!

7
Four Fundamental Values of Agility
1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan
There is value in the items on the right
 but value the items on the left more!
 (“over” != “instead of”)
Source: The Agile Manifesto, http://www.agilemanifesto.org

8
Four Principles of Lean Thinking
1. Add nothing but value
– (Eliminate Waste)
2. Center on the people who add value
3. Let Customers “Pull” Value
– (Delay Commitment, Deliver Fast)
4. Optimize the Value Stream
– (Optimize Across Organizations)
Source: Mary & Tom Poppendieck, http://www.poppendieck.com

9
Seven “Wastes” of Software Development
1. Extra/Unused features (Overproduction)
2. Partially developed work not released to production
(Inventory)
3. Intermediate/unused artifacts (Extra Processing)
4. Seeking Information (Motion)
5. Escaped defects not caught by tests/reviews
(Defects)
6. Waiting (including Customer Waiting)
7. Handoffs (Transportation)

10
Ten Simple Rules of Lean Programmning
1. Eliminate waste - Add nothing but Value
2. Minimize artifacts
3. Satisfy all stakeholders
4. Deliver as fast as possible
5. Decide as late as possible
6. Decide as low as possible
7. Deploy comprehensive testing
8. Learn by experimentation
9. Measure business impact
10.Optimize across organizations

11
Agile Development Characteristics
Adaptive – plans, designs, and processes are regularly tuned and
adjusted to adapt to changing needs and requirements
Goal-driven – focus on producing executable-results (working
functionality) in order of highest business value.
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/design & process) emerge from highly collaborative,
self-organizing teams in close interaction with stakeholders

12
What is SCM? (Traditional View)
 Configuration
Identification
 Configuration Control
 Status Accounting
 Audit & Review
 Build & Release
Management
 Process
Management, etc

13
What is SCM? (Alternate View)
SCM is a set of structures & practices that:
 Facilitate frequent feedback on build
quality & product suitability
 Enable you to change & build systems in
repeatable, agile fashion with:
• Increased productivity
• Enhanced responsiveness to customers
• Increased quality
 Help your customers feel more confident

14
What is SCM? (Lean View)
SCM is the part of the business value
stream responsible for managing:
 Efficient, effective flow and storage of changes,
and related information
• From origination-point to consumption-point
• In order to meet customer needs and demands
Requests R2R1
R2
V2 V3V1
R1
Changes Business
Value
Results

15
What SCM Does for You
SCM done “right” can give you:
 Reproducibility
 Integrity
 Consistency
 Coordination
SCM done badly can:
 Slow down development
 Frustrate developers
 Limit customer options

16
Part II: Agile CM Environments

17
What is Agile SCM?
The pragmatic application of
 sound CM principles & practices
 in accordance with Agile Values
 using Lean Thinking
to serve the needs of the Business!

18
Agile SCM requirements
An Agile SCM solution must:
 Serve its practitioners and not vice-versa!
 Break down walls between SCM & developers to bring
a “whole” team working together to deliver quality
software in an agile fashion
 Respond to change rather than prevent changes
 Track and coordinate development rather than trying to
control developers
 Strive to be transparent and “frictionless”, automating
as much as possible

19
Agile SCM Characteristics
 SCM is a “whole team” responsibility
 Respond to change instead of trying to prevent it
 Lean Documentation & Traceability
 Aggressive Dependency Management
 Continuous and Visible Feedback
–on Quality, Stability, and Integrity
 Frequent + fast coordination and automation

20
SCM is a “whole team” responsibility
 SCM and development must closely collaborate toward
the shared goal of successfully meeting a project’s
business and technical objectives
 SCM is part of every team member’s day-to-day tasks
and activities:
• Everyone is responsible for regularly integrating, building, and
testing in their sandbox before committing their changes
• If the build breaks, the whole team takes ownership of getting
it working again
 Everyone understands and appreciates the needs of
both development and SCM because they experience
the needs and benefits of both every day

21
SCM & Development: Great Walls of “Ire”
Many shops segregate development from SCM:
 Development “throws it over the wall” to SCM
 Forges a barrier to effective communication and
collaboration between developers and SCM people
• Developers perceive SCM as overly formal, rigid, and
bureaucratic
• SCMers perceive developers as undisciplined or ignorant of
SCM concerns, constantly compromising product quality or
integrity in the name of schedule or development speed
SCM & development should work together on the
same side (not on two different sides)!

22
Responding to change vs. controlling it
 Manage stakeholder expectations with close
communication and simple boundaries (short,
frequent iterations)
• Decision makers must be closely available &
accessible to give rapid response to issues &
questions
• At the start of each iteration, expectations and
priorities are (re)set and (re)calibrated
• CCB’s might be called “change planning meetings”
to avoid the stigma of trying to control change
• Work only on the features for the current iteration

23
Responding to change vs. controlling it
Authorization for developers to make changes
needs to be instantaneous upon approval:
• Once a developer has signed up for a task, they
should not have to wait to begin checking items out
of the repository
• If a bug breaks the build or a fails a required test,
development must be able to effect the repair
without having to wait any noticeable period of time
to receive “authorization”
• No additional permission required for refactoring

24
“Lean” Documentation and Traceability
 Minimize Traceability and Eliminate Redundancy by
using Fewer Artifacts and Separation of Concerns
 Track features/use-cases and classes/modules
(instead of their individual requirements/routines)
• Increases encapsulation + modularity of code and reqt’s
• Reduces number of items to track (by an order of magnitude!)
 Fewer items, means fewer items to track/trace
• Detailed requirements/use-cases may serve double-duty as
acceptance test-cases
• Hi-level requirements/features may be simple feature/change
requests and/or release notes (automatically generated)
• Some end-user documents may even be used as use-cases or
functional requirements documentation

25
Aggressive Dependency Management
 Minimizing Dependencies minimizes impact+rework
• Aggressive refactoring maximizes encapsulation & localization
• Modularity makes it easier to trace at the level of features, use-
cases, and domain abstractions
 Maximize Simplicity!
“… is finally achieved, not when there is nothing left to add, but when there is
nothing left to take away.” -- Antoine de Saint-Exupery
“There are two ways of constructing a software design. One way is to make it
so simple that there are obviously no deficiencies. And the other way is to
make it so complicated that there are no obvious deficiencies.” -- C.A.R.
Hoare
“Manifest plainness, Embrace simplicity, Reduce selfishness, Have few
desires.” -- Lao-Tzu
 New motto: “Simple-size it!”
• Applies to requirements, design, releases, iterations,
documentation, tools, and process

26
Coordination and Automation
SCM tools & practices/processes cannot hinder
development or they won’t get used!
• Add nothing but value
• Minimize Artifacts
• Eliminate Waste
• Center on the people who add value
 Tools and processes need to be simple, pragmatic, and
enhance communication and coordination or reduce
rework.
 Tracking systems and version control tools should not
interrupt “flow” by causing a “wait” for tools to collect
data or complete lengthy operations.

27
Coordination and Automation
SCM patterns help keep codelines clean and
safely integrated, and the team coordinated
 Frequent & regular integration/test is critical for agility!
• Deliver as fast as possible (small releases, short iterations,
continuous integration)
• Deploy comprehensive testing
 So is effective use of branching and merging!
• Deliver as fast as possible (commit/update development
change-tasks as early as possible)
• Decide as late as possible (branch as late as possible)
• Decide as low as possible (developers reconcile merges and
commit their own changes)
• Optimize across the “Whole” (when/if branches are created, use
a Mainline to maintain a manageable branching structure)

28
Coordination and Automation (continued)
Integration+build+test activities are automated to
the greatest extent feasible
• One of the single biggest “drags” on development
feedback cycle-time is the “friction” that comes from
prohibitive build-times, or long testing-cycles
• These force development to either freeze or branch the
code-base for significant periods of time while waiting for
integration/build/test activities to complete
• Integration+Build tools/scripts, code structure, and
network resources must be leveraged appropriately to
minimize build times

29
Agile Methods and SCM
 Context
 Refactoring
 Minimum Administration
 Appropriate Automation
 Continuous Integration
 Code Availability
 The Three Builds

30
Context Setting
Two types of SCM “enhancements” to consider:
Immediate value vs. Insurance value
 Immediate value - Engine analogy
• Basic Version Management
• Automated build system
• Common development ecosystem
 Insurance - High altitude mountain climbing
(likelihood, consequences, cost)
• Periodic builds
• Restore of prior releases
• Change Management
• Dependency Management
• Code security
• Eliminate heroism

31
Refactoring
The act of constantly cleaning and improving
existing code
• CM VC needs to support changing file names
• History of changing file names is important
• History following file seems to be less important to
developers than ease of change
 Why?: Maximize Simplicity, Manage Dependency
• To prevent code from becoming fragile, slow and
difficult to maintain, while minimizing opportunity for
analysis paralysis.

32
Minimum Administration
Remove unnecessary dependencies on
administration activities
• Events requiring administrative privileges should
be exceptions, not part of routine process
• Automated builds should be periodic and on-
demand
 Why?: Eliminate Waste from Handoffs/Waiting
• To remove hand-offs and manual steps that can slow
the process and provide breakdowns in
communication

33
Appropriate Automation
Automate development events that occur often,
change rarely and require consistency.
• Build events, deployment events, formal release,
automated testing, integration builds
 Why?: Minimize Artifacts & Waiting
• To document these procedures via scripts, improve
development productivity, increase development
predictability and decrease administration.

34
Continuous Integration
 Keep the codeline healthy, working code
• Automated integration build
• Automated tests
• Always update workspace & test prior to check in
• Check in often
 Why?:
• To minimize the time integration problems exist in
the codebase. The earlier it’s discovered, the easier
it is to identify and fix.

35
Code Availability
 Eliminate SCM barriers to development
as much as possible
• Optimistic locking or developer branches -
avoid file lock conflicts
• Development should be able to continue for
short windows of time disconnected from
repository
 Why?:
• To improve developer productivity while
coordinating team changes

36
The Three Builds
 Private Developer Build
• Provides a consistent way for the developer to build
the software in the confines of their private workspace
 Team Integration Build
• Synchronize team, feedback on code quality/integrity
 Formal Release Build
• Creates the deployable package
 Why?:
• Productivity, predictability, documented, ability to
delegate build activity without compromising CM
or quality.

37
Private
Build
Task
Developer
Multi-Task
Coordination
Development
Team
Integration
Build
Customer/
Test(V&V)
Iteration/
Release
Release
Build
The Three Builds

38
Putting it all Together …
Agile 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

39
Agile SCM and the Agile Manifesto Value #1
Individuals and Interactions over Processes
and Tools
 SCM processes and tools should support
the way that you work, not the other way
around.
“Processes don’t write software. People do!”

40
Working Software over Comprehensive Documentation
 Minimize intermediate artifacts
“Simple-size it!”
 SCM can automate development policies and
processes with executable knowledge over
documented knowledge
“Appropriate Automation”

41
Customer Collaboration over Contract Negotiation
 SCM should facilitate communication among
stakeholders and help manage expectations
“It’s the relationship stupid!”

42
Responding to Change over Following a Plan
 CM is about facilitating change, not preventing it
• “Requirements changes late in the lifecycle are competitive
advantage, IF you can act on them!”
– Mary Poppendieck
• “Agile projects are not controlled by conformance to plan but by
conformance to business value.”
• If we accept the notion of constant change & turbulence, then
plans are still useful as guides, but not as control mechanisms
… because they tend to punish correct actions.”
– James Highsmith
“Change is not the enemy – stagnation is! Don’t
try to prevent change! Plan for it!”

43
Wrap Up

44
Our Book
 Pub Nov 2002 By
Addison-Wesley
Professional
www.scmpatterns.com

45
Other Agile/SCM References
 Configuration Management Principles and Practice,
Anne Mette Jonassen Hass
 Software Configuration Management Strategies and
Rational ClearCase, Brian White
 Requirements by Collaboration, Ellen Gottesdiener
 Lean Software Development, Mary & Tom Poppendieck
 The Laws of Software Process, Phillip G. Armour
 Agile Software Development Ecosystems, James
Highsmith
 Agile Software Development, Alistair Cockburn
 Domain Driven Design, Eric Evans
 Refactoring: Improving the Design of Existing Code,
Martin Fowler
 Addison-Wesley’s XP Series of Books

46

47
Other Agile SCM Resources
 www.scmpatterns.com
 acme.bradapp.net
 www.berczuk.com
 www.scmlabs.com
 www.cmcrossroads.com

Agile Configuration Management Environments

More Related Content

What's hot

Viewers also liked

Similar to Agile Configuration Management Environments

Recently uploaded

Agile Configuration Management Environments

Editor's Notes