agile an evolutive approach from cmmi iso

Motorola Public

Miguel InsaurraldeMotorola Argentina Software Center

Agile: an evolutive approach

from CMMI-ISO

Motorola Public 2Miguel Insaurralde, Oct-09

This presentation

It is not ….

• a compilation of industry experience nor…

• a model for Agile adoption

It is …

• sharing the experience of a SW center

introducing Agile process…

• within an existing CMMI-ISO culture and set of

practices …

• and proposing a postulate:


Postulate

Agile evolution rather than substitution

• SW dev changes with technology & market

Experience best practices throughout time

• Properly used help to reuse knowledge

CMMI/ISO + Agile can boost mutually

• Complemented and empowered


Motorola Argentina Software Center

Variety of projects since 2001

• Embedded and Platform for mobile

communications & devices management

• Applications for public safety, assets tracking,

multimedia content management

Quality standards

• CMM-3 in „03, CMM-5 in „04, CMMI-5 in „07

• ISO 9001:2000 in „06, ISO 9001:2008 in „09

Agile first project „07 org adoption „08


THE MYTHICALMAN-MONTH

SW development evolution

SOFTWARE AS

UNIQUE MEASURE

UPFRONT MODELS

TO MINIMIZE

CHANGES

CHANGEABLE

WORKING

SOFTWARE

NO SILVERBULLET

TEAMWORK & COLLABORATION

THE INTERNETKNOWLEDGE &

PRACTICES

Business velocity

Technology„s capacity of change


AGILE

ADOPTION

Motorola Argentina Software Center


What “Agile adoption” means for us…

• New Agile process definition

• Integrated within existing Quality Management System

• Integrated with some existing practices

• Different certainty and commitment basis

• Demanding interaction with pairs and stakeholders

• Different involvement in decision-making process


Some myths to overcome…

• Main focus only on intermediate artifacts, not in real product

• Team members just limit to follow a plan of upfront assigned tasks

• Release date is only a best guessing, true deadline is iteration end-date

• Do not make any mid / long-term decision, you are not going to needed


Ideal context

• Balanced timing… not too early / too late

• Stakeholders aligned to decisions timing

• Base decisions on facts and feedback (from product increments) and previous experience

• Continuous Integration & Test Automation

• Decision-making spread among affected groups, ready for breaking changes


Different “real” contexts

• Life-cycle creation / enhancements / maintenance

• Dependencies customized / single version, framework / solutions

• Teams & decision-makers co-located / distributed

• Team volatile, different skills & experience levels

• Obligation exploratory / intermediate / customer delivery

• Defects impact repair, recall, company image


Adaptability to different contexts

Wide range of projects can adopt Agile

Many require significant tailoring

Gap: beware, and

adjust accordingly

Lack of Product Owner

availability

Continuous Integration / Test

Automation not feasible

Separate QA team (product

certification: interoperability,

capacity)

Parallel teams or distributed

product mgmt


CONTRIBUTION

What Agile empowers

AGILE

ADOPTION


Requirements understanding

Upfront assumptions

Progressive agreement over expected results

Contributions

Frequent feedback and testing

Visibility of business value

Better trade-off decisions


Technology usage

Release early, release often test

early, test often

Continuous integration and test

automation require deep

understanding

Support from pairs

Understood Comprehended

Contributions


Teamwork & collaboration

Commitment Ownership

Daily exposure at Standup meetings

Commitment with pairs

Work progress visibility in Reviews

Contributions


Team learning & improving

Per-project wide spectrum

Per-iteration product & team

focused

Monthly and short-duration

Reviews outcome is a key

input

Contributions


INTEGRATED

What empowers Agile

AGILE

ADOPTION


CMMI-ISO & Lean (1)

Eliminate waste – org level

• Feedback (engineers, customers, metrics)

• CMMI Org Innovation & Deployment

(business case definition, pilot & deploy)

• CMMI Organizational Process Definition

• CMMI Causal Analysis

Amplify learning – from teams to org

• Knowledge area teams, Org training plan

Integration


CMMI-ISO & Lean (2)

Build integrity in

• Independent audits & control

• Customer feedback mechanisms

See the whole

• “System thinking” through organizational

groups: OPG / SEPG, Security Council, CM /

Agile forums

Integration

Motorola Public Miguel Insaurralde, Oct-09 20

CMMI-ISO & Lean (2)

… ALL OF THESE CONTRIBUTE TO DETERMINE

WHAT “ADDS VALUE” TO THE BUSINESS

Integration


CONCLUSIONS

After some time doing Agile

AGILE

ADOPTION


Agile requires strong discipline

Focus on goals and deliveries

Clear “Working SW” and

“Done” concepts

Backlogs consistency

throughout project life

Product Owner

involvement

Demanding tools integration


Risks to have in mind

Do not discard valuable pre-

existing practices

Do not assume it will work

smoothly

Keep an eye on

organizational effort


Impact in Culture

Newbie team members

Personal interaction

New certainty basis

Understanding Agile

values & culture takes

time

Time and learning

required to find balance

Planned training & coaching

Organizational follow-up

Be prepared for

diverse reactions


Summary

Makes significant contributions even for very different contexts

Can be powered with existing organizational assets

Requires investment in training, coaching and assessment

Needs wise tailoring to keep product & org vision

Agile within our CMMI-ISO organization...


BACKUP

Some more slides…


CMMI-ISO organization

CONTROLIMPROVEMENT

Input: feedback,

metrics & trends

Output: trainings,

process, support

Who: engineers

Audits

Preventive

and corrective

actions

May stop a

shipment

EXECUTION

Process & tools

Best practices & experience

Quality Management System + Process Areas

Integration


Existing practices

Requirements management

Coding standards & static analysis

Estimations

Change management

Quality Assurance

Risk management

Cost management

Integration


Engineering practices (1)

Requirements management

• Elicitation techniques, classification

• Requirements Specification , Use Cases

when suitable (interfaces, etc.)

Coding standards & static analysis

• Organizational standards and support

(Security Council, CM forum, SEPG)

Integration


Engineering practices (2)

Estimations

• Existing techniques & tools

Change management

• Experience with distributed teams & different

stakeholders structures

Quality Assurance

• Test development techniques & guidelines

• Test management

Integration


Management practices

Risk management

• State & classify, define actions, follow-up

• Historical data and taxonomies

Cost management

• Cost ≠ Progress, but both need tracking.

Every project has somehow an allocated

budget for a given scope

• Buffers, trends, deviations are useful tools

Integration


Do not discard valuable pre-existing practices

• Manage risks of having changes that can be

anticipated

• Use detailed specifications when needed

• Estimation & scheduling techniques for high and low-

level

• Scope management to improve decisions timing

Risks to have in mind (1)


Do not assume it will work smoothly

• Collaboration & Involvement is not easy to reach, use

HR management techniques

• Possible tools integration and setup issues

Keep an eye on organizational effort

• Team members „Organizational time‟ is hard to obtain

Risks to have in mind (2)

agile an evolutive approach from cmmi iso

Documents

public safety

empoweredmotorola public

neededmotorola public

agile adoption

company imagemotorola

postulate agile evolution

product increments

knowledge cmmiiso agile