CMII & Agile: There's a better way to do it - let's find it

CMII & Agile
There’s a better way to do it – let’s find it
Willmund van Aarde, CMIIC
willmund@configitems.com

There is some evidence that Thomas Edison employed this to encourage his lab researchers
1957: Ascribed to Thomas Edison in advertising campaigns
1961: David Sarnoff states that he saw this message on a sign in Edison’s laboratory.
This evidence is not ideal as Thomas Edison had passed away in 1931.
This quote encourages ways to do things better and falls in with the process of continual
improvement.

Introduction
• CMII is lean and mean.
This statement lead to me investigate how lean and agile CMII is and inspired this
presentation.
• Agile - one of the big concepts in IT, with “big data”
following closely behind.
Agile gives the impression of the ability to change fast; the concept is not always
fully understood. Agile provides a broad framework to work under, with various
methodologies like Scrum, Lean and Kanban to work under.
• Unearth people, processes and product improvements
through rigorous focus on continual improvement and by
questioning everything.
Agile is designed to do the above.
• CM: heavy-handed, wasteful, over-burdened and jam-
packed with process.
This is the view of Agilists and a perception we need to work on enthusiastically

The Agile Manifesto
We are uncovering better ways of developing software by
doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we
value the items on the left more.
http://www.agilemanifesto.org/

The Agile Manifesto, interpreted
With that statement as our guide, we will interpret the
Manifesto to be saying:
• We value processes and tools.
• We value comprehensive documentation.
• We value contract negotiation.
• We value following a plan.
http://blog.projectconnections.com/alan_koch/2015/08/is-
the-agile-manifesto-dangerous.html

The Agile Manifesto, interpreted
But because those things are only the means by which
we achieve more important ends:
• We place higher value on individuals and interactions.
• We place higher value on working software.
• We place higher value on customer collaboration.
• We place higher value on responding to change.

Individuals and interactions over
processes and tools
Agile:
• People, their energy and their ability to solve problems
Focus is on people
• Communication
with the cross-functional team is clear, effective and quick
• Strong teamwork
People work together and the team is mostly self-managed and self-sufficient.
Waterfall:
• Challenging to accommodate new ideas, new
requirements, new ideas and thinking
A dogged conformity to processes cause the above to happen.
• Over-reliance on the actual process
Valuing process over people creates a culture of over-reliance on the process instead
of finding the best way to create good products.

Working software over
comprehensive documentation
Scrum – Definition Of Done
The “definition of done” (developed, tested, integrated and
documented) and a working product is the reason for the
project.
On an Agile project the focus is on the documentation that supports product
development
Agile teams need only:
Requirements document - CLEAR, CONCISE and VALID
Product technical specifications - how the product was
created
How do we know what documentation is required? Stop creating them and see who
shouts loudest! Another method is to ask WHY five times to get to the root reason for
the document
CMII: Change faster, document better!

Customer collaboration over
contract negotiation
Collaboration rather than confrontation produces better, leaner and more
useful products
This ensures that the customer is part of the project on an ongoing basis.
Historic PM approach:
There are 3 points where the clients are involved, namely
The project start
Scope changes during the project
The end of the project
Agile approach:
A partnership between the customer and the development team.
Discovery, questioning, learning and adjusting the course of the project are
considered routine, acceptable and systematic.
Customer review is built in and the customer sees the product at the end of every sprint
and features are prioritized for maximum returns early on

Responding to change over
following a plan
• Agile: Accommodate change systematically and the
approaches to planning, working and prioritization
allow project teams to respond quickly to change.
• Changes become predictable and manageable.
• CMII change management supports this framework!
It is critically important for the PM to have a view of the plan, but the team needs to
operate in such a way that it can respond to change in the drop of a hat.
Planning is not devalued, it is sticking to the plan that is. The plan helps us to
recognize when things have changed; it helps us understand the implications of the
change, how we need to adjust and the likely cost. Planning is an ongoing time-
boxed activity that includes iteration planning, retrospectives and risk assessments.
Software projects are dominated by change: Changing requirements, changing
environments, changing interactions with other systems and changing user
communities.

Kent Beck (author of Extreme
Programming Explained) wrote
Agility in software requires iron discipline – absolutely
fixed time schedules; rigid and high quality goals; and a
devotion to collaboration and communication.

The scrum engagement sequence was recently updated to the following: “crouch, set,
touch” and then “bind”.
An extra note was added for the referee: The sequence should be easy to implement,
however there will be an adjustment period for both referees and players.
The same note would apply in the corporate world when introducing an agile approach.

www.scrumarabia.comWillmund van Aarde, CMIIC willmund@configitems.com
Important roles:
Scrum Master
-- Teaches scrum
-- Manages process
-- Enforces rules
-- Removes blocks
Important artifacts:
Increment
-- Version of the
product potentially
shippable
-- Working
functionality, tested
and documented
according to project
definition of done
Important meetings:
Daily scrum
-- 15 minutes
-- Run by scrum master
-- Attended by all
-- Stakeholders don’t
speak
-- Yesterday /today /
impediments

CM Planning
Impact mapping approach: why, who, what, how
• Impact mapping: communicate assumptions, create
plans and align stakeholders for iterative software
delivery.
• Impact maps facilitate several popular product and
project management practices.
Impact mapping is a useful approach for planning a systematic
implementation or roll-out of CM in your organisation.
“Impact Mapping – Making A Big Impact With Software
Products And Projects” by Gojko Adzic

Incremental vs Iterative
• Traditional CM planning used the big effort up front
method and this contributed to project failing and the
implementation of CM being unsuccessful.
• Agile recommendation: incremental planning; just in
time – this approach focusses on the building out of
CM functions over a period of time based on the value
perceived by the business and resources available.
The plan is presented to the product team “just in
time”
• Recommended configuration management approach:
iterative. This involves iteratively identifying CM needs
over time and establishing them as and when required.

Incremental vs Iterative
“Impact Mapping – Making A Big Impact With Software
Products And Projects” by Gojko Adzic
Incremental:
Iterative:

Agile Delivery
Creating a quality product
that provides high
business value while
reducing the risk of failure.
Large corporations constrained
by regulations are reluctant to
change as a wrong move could
jeopardise their business and
reputation in the marketplace

Implementing Water-scrum-fall
A typical project
Initiate
Plan
Discover
Build
Deploy
Release
Configuration Management
Plan
Do
Study
Act

Water-scrum-fall
www.andrejkoelewijn.com/blog/

Water-scrum-fall: A proposal
securesoftwaredev.com

Ensure Configuration
Management remains relevant
• Negotiate a suitable Continuous integration strategy
with the development teams
• Ensure there is an effective build strategy in place (fast
and well-automated)
• Build management is simple and performs flawlessly
• Negotiate with stakeholders and developers around
their agile requirements and be open, receptive and
flexible to new ideas

10 Things CIOs Need to Know
About Agile Development
1. Agile is not one thing
It is a set of approaches to software development. A sophisticated
organisation could use a few approaches, whereas one starting should only
use one.
2. Agile is not a "pick-'n-mix" methodology
Agile methods are highly systematic and each component is critical to
eventual success.
3. Embracing agile is a joint business-IT activity
The full benefits of Agile cannot be realized without engaging everyone
affected, from business leaders to IT management and the users.
4. With agile, it is important to walk before you try running
This is in order for an organisation to go through a normal learning curve.
5. Embracing agile is embracing continuous learning
As dedicated employees look to constantly improve quality and cost-
effectiveness.
Gartner Research:
http://www.gartner.com/newsroom/id/3085517

10 Things CIOs Need to Know
About Agile Development (cont.)
6. Agile is about teams and teams of teams
These teams involve both developers and QA professionals. From an HR perspective there is a fine
line between keeping a team together and moving individuals around to encourage cross-
fertilization of ideas.
7. Documenting, managing and eliminating technical debt is a core
concept of all agile methods
Technical debt is the difference between the state of a piece of software today and the state that it
needs to be in to meet appropriate requirements. Technical debt is recognized and added to the
backlog and not swept under the carpet.
8. Working with third-party development service providers on agile
development demands special care and attention
Colocation is central to agile methodologies – when teams are distributed a very different
commercial and engagement model is required.
9. The impact of agile goes well beyond the software development
teams
There is a continuous stream of new and modified software into the operational environment and
this results in changes in working practises for both business governance and relationship
management for both infrastructure and operational teams
10. Other software development methodologies will still have a place in
your portfolio
Different classes of development problems require different approaches and some are better
suited to agile while others are better suited to waterfall. Agile is not better in all cases!
Gartner Research:
http://www.gartner.com/newsroom/id/3085517

There’s a way to do it better –
let’s find it
Configuration
Management benefits
Agile and vice versa when
CM and its functions
become part of the agile
team.

Questions
Willmund van
Aarde
https://za.linkedin.com/in/
willmundvanaarde

CMII & Agile: There's a better way to do it - let's find it

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à CMII & Agile: There's a better way to do it - let's find it

Similaire à CMII & Agile: There's a better way to do it - let's find it (20)

Dernier

Dernier (20)

CMII & Agile: There's a better way to do it - let's find it

Notes de l'éditeur