Is an agile SDLC an oxymoron?

Is an agile SDLC an oxymoron?
or how to do the right thing, not do thing right

agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.

regulatory international B2B
Dave Sharrock MBA English IPO agile
dave.sharrock@agile42.com
twitter: @davesharrock husband start-up
skype: dave.sharrock
technology
Technical Due Diligence newly-minted Canadian

Pre-IPO IT Audits executive leanstartup outsourcing
SDLC Deﬁnition father
Regulatory Compliance & Agility enterprise transitions
• PCI Compliance B2C data analysis kanban
• Data Security seismology scrum
• Telecommunications organizational excellence


Agenda
• Minimizing Audit: Doing the thing right

• The IS Audit

• SDLCs

• And agility...

• Maximizing Value: Doing the right thing

• The edge of agile thinking

• How this might impact IS


Minimizing Audit: Doing the thing right
• Audit goals

• Introducing the SDLC

• Agile SDLCs

• Auditing agility


With IT’s importance to the business growing
steadily, the governance aspects of IT clearly
highlight the following as major components:

• Alignment
• Value realization
• Service delivery
• Risk management

Auditing Realization of Beneﬁts from IT, S. Anantha Sayana, Information
Systems Control Journal, Vol. 3, 2005

To provide reasonable assurance to managers that:
1. Financial and operating information
is accurate and reliable
2. Policies, procedures, plans, laws
and regulations are complied with
3. Assets are safeguarded against loss
and theft
4. Resources are used economically
and efﬁciently
5. Established program/operating
goals will be met


Defining, controlling, monitoring

•Documentation of software
development process
•Definition of project/program
controls
•Definition of required artifacts,
documents and authorizations
•Risk management processes
•Often defined and controlled
through an enterprise PMO

Introducing the SDLC

Any SDLC should result in a high
quality system that:
• Meets or exceeds customer
expectations
• Reaches completion within time
and cost estimates
• Works effectively and efﬁciently
in the current and planned IT
infrastructure
• Is inexpensive to maintain and
cost-effective to enhance

"Systems Development Life Cycle". In: Foldoc(2000-12-24)


The Software Development Lifecycle

• In the search for repeatable,
predictable processes that improve
productivity and quality, the
Software Development Lifecycle
(SDLC) is a structure imposed on
the development of a software
product
• The ISO/IEC 12207 standard
establishes a process of lifecycle for
software
• There are 23 Processes, 95
Activities, 325 Tasks and 224
Outcomes
http://en.wikipedia.org/wiki/Software_development_process and http://en.wikipedia.org/wiki/ISO/IEC_12207

Capability Maturity Model Integration
According to the Software
Engineering Institute, CMMI Characteristics of the Maturity Levels
helps

"integrate traditionally separate
organizational functions,

set process improvement goals
and priorities,

provide guidance for quality
processes, and

provide a point of reference for
appraising current processes."

CMMI Overview. Software Engineering Institute. Sally Godfrey (2008) What is CMMI ?. NASA presentation


CMM (the precursor to CMMI) is based on the process maturity framework ﬁrst
described in the 1989 book Managing the Software Process by Watts Humphrey

http://en.wikipedia.org/wiki/Waterfall_model


CMM (the precursor to CMMI) is based on the process maturity framework ﬁrst
described in the 1989 book Managing the Software Process by Watts Humphrey

Which in turn is based on
the waterfall methodology,
ﬁrst described by Winston
Royce in 1970, describing
the work of Herbert D.
Benington from the
Symposium on Advanced
Programming Methods for
Digital Computers on 29
June 1956
http://en.wikipedia.org/wiki/Waterfall_model


SDLC to Maturity Models

Maturity Model - Level 5





Requirements Design Implementation Veriﬁcation Maintenance

SDLC workﬂow

Agile SDLCs
1. Our highest priority is to satisfy
the customer through early and
continuous delivery of valuable
software

3. Deliver working software
frequently, from a couple of
weeks to a couple of months,
with a preference to the shorter
timescale

7. Working software is the primary
measure of progress

http://agilemanifesto.org/


Team-level SDLC

http://www.ambysoft.com/essays/agileLifecycle.html


System-level agile SDLC
• Stretch agile SDLC upstream/downstream to support scaled agile teams

• Likely very different but interfaces/dependencies allow control

• Describe the framework, monitor artifacts, and automate boundaries



Enterprise agile SDLC
• Extends beyond software development

• Agility not considered upstream/downstream in current models - this will chnage

• Still based on momentum/inertia based decisions



Agile SDLCs extend traditional SDLCs
• But they lack true agility

• Reform existing models with an
iterative development piece

• Hybrid of true agility and planning-
based processes

• Map to traditional phased
approach

• Don’t recognize paradigm shift to
working software as success

• Still waiting to complete paradigm
shift to adaptive product delivery


Auditing agile
methods
For small teams
And for the enterprise


Software delivery
doesn’t have to be a
long, uphill climb with
no end in sight..
Phases or gated models break
down
Deﬁnition and control conﬂict with
the adaptive self-organized
approach of agile methods


Delivering working
software can take
just a few steps
But companies still need oversight
and transparency. Deﬁnition and
control needs to be more relevant:
• Audit of outcomes over outputs
• Vetting the whole cycle, not bits
of it


Focus on outcomes
over control gates
Control small changes to the
whole, not steps in the process
Process is deﬁned by its
outcomes, not how work is done


Agile methods for
small teams
Little divergence from common
approach
Shared artifacts emerge naturally


Focus on outcomes
not process deﬁnition
Compliance contributes
directly to team
Capture the right
artifacts
Institutionalize
knowledge sharing


Agile methods at
scale
Teams diverge from common
approach
Artifacts harder to share


•Teams adapt to
•Development need
•Experience curve
•Each team adapts in a different way
•Legislating an approach cripples value delivery
•Maybe deﬁne preferred approaches, especially
where deﬁnition has value in and of itself (HR, PMO)


Focus on framework
and boundary objects

Guide self-awareness
not maintain status quo

Share success not best
practices


Growing Agile Teams team name:

Specialist knowledge shared
Acceptance test-driven dev
Limited manual testing
STEP 4. Scale Automated testing of NFRs
grow knowledge, share learning, Communities of Practice

Focus on framework
expand capabilities Shared Definition of Done
Stable and verifiable builds
Cross-cutting concerns
Entire team works on release

and boundary objects
Everyone experiences SM
Team owns environment
Velocity guides release
Business value drives work
Visible measure of value
Swarms on committed PBIs
Owns external dependencies
STEP 3. Maximize Value
organize to deliver maximum value Reduces technical debt
Grow engineering practices
Automated PBI testing

Team takes 6-10 PBIs Guide self-awareness
Predictability over 90%
Business value understood
PBIs done in priority order

not maintainteams first focus quo
status on
PBIs reviewed as done
STEP 2. Gain
Experience Shared code ownership
people, process and work all settling
in, focus on learning
Technical debt identified
Bugs actively fixed
agile
1-3 improvement actions
Release Definition of Done
smoothing flow and
enhancing quality, leading to
Cross-functional Teams
Working Agreement maximizing of value delivery
Regular backlog
PBIs for 1-2 sprints
grooming
Impediment backlog
STEP 1. Organize PBIs broken into tasks
Active Learning Cycle maximizing value
preparing the structures, work and Transparent team
Definition of Done

practices
people capacity
Definition of Ready enhancing quality
Daily stand-ups
Potentially shippable
Sprint burndown
Vision and requirements
smoothing flow
Focus on 2-3 PBIs

more each stage acts as a scaffold, offering guidance and more
directive support, for different phases of a team’s agile journey guiding
copyright 2011We advise, trainltd
agile42 | agile42 consulting and coach companies building software
the accompanying Growing Agile Teams worksheets provide more details behind the checklist 2007 - 2009.
www.agile42.com | All rights reserved. Copyright © for each step

Auditing agile methods at scale

practices


Auditing agile methods
• Focus on outcomes not process
deﬁnition
• Compliance contributes directly
to team
• Capture the right artifacts
• Institutionalize knowledge
sharing
• Focus on framework and
boundary objects
• Guide self-awareness, not
maintain status quo
• Share success not best
practices


Maximizing Value: Doing the right thing


CMMI vs. agile adoption
- process change management
- technology change management
- defect prevention
<1% Level 5 - optimizing

- software quality management
- quantitative process management <5% Level 4 - managed

- software product engineering
- integrated software management
- organization process definition
<10% Level 3 - defined

- software configuration management
- software quality assurance
- software project planning
~15% Level 2 - repeatable

~70% Level 1 - initial


‘If you are not embarrassed by the ﬁrst version
of your product, you’ve launched too late.’
Reid Hoffman, founder of LinkedIn


Lean Startup to DevOps


Ineffective and unimaginative IT
can mean the loss of opportunities,
markets and customers

Auditing Realization of Beneﬁts from IT, S. Anantha Sayana, Information Systems Control Journal, Vol. 3, 2005


How well does IT serve the
business? What is the state of
effectiveness of IT for the business
to date?



What is the beneﬁt derived from
implementation of speciﬁc large
projects or enterprise-wide
implementation of applications?



Takeaway: Business Assurance through....?
At the ﬁrst level, IT in every organization seeks to perform the most widely used
and common functions.

At the next level, IT should seek to support the business strategy through closer
alignment and enterprise information systems that provide substantial support for
carrying out every business process that is critical to success of the business.

At a still higher level of maturity, IT should jointly mold the business strategy by
suggesting to the business new possibilities in various aspects, such as
product development, reaching new markets and rolling out newer
business models that are completely enabled by IT, thereby giving the business
opportunities that would have not been otherwise possible.



agile42 - the agile coaching company

• Agile change for the whole organization

• Agile transformation across an entire
organization involves changes in
understanding and practices at the
individual, departmental and
management levels

• Based in Vancouver, B.C. (Canada) &
Kirkland, WA (USA)

• Operates across North America and
Europe


Further viewing/reading
• Slideshare: http://www.slideshare.net/davesharrock

• Lean Startup: http://www.theleanstartup.com

• DevOps: http://www.devops.com

• Nordstrom Innovation Lab: Sunglass iPad App Case Study
http://www.youtube.com/watch?v=szr0ezLyQHY

• GTAC 2011: Opening Keynote Address - Test is Dead
http://www.youtube.com/watch?v=X1jWe5rOu3g


“Coming together is a beginning.
Keeping together is progress.
Working together is success.”
Henry Ford

thank you

dave.sharrock@agile42.com
skype: dave.sharrock
twitter: @davesharrock
slides: slideshare.net/davesharrock

Is an agile SDLC an oxymoron?

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (18)

En vedette

En vedette (17)

Similaire à Is an agile SDLC an oxymoron?

Similaire à Is an agile SDLC an oxymoron? (20)

Plus de Dave Sharrock

Plus de Dave Sharrock (20)

Dernier

Dernier (20)

Is an agile SDLC an oxymoron?