Is an agile SDLC an oxymoron?

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

Is an agile SDLC an oxymoron?

or how to do the right thing, not do thing right


[email protected]: @davesharrockskype: dave.sharrock

regulatory international B2B

MBA English IPO agile husband start-up

technology

newly-minted Canadian

executive leanstartup outsourcing

father enterprise transitions

B2C data analysis kanban seismology scrum

organizational excellence

Technical Due Diligence

Pre-IPO IT Audits

SDLC Definition

Regulatory Compliance & Agility

• PCI Compliance

• Data Security

• Telecommunications

Dave Sharrock


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 Benefits 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 reliable2.Policies, procedures, plans, laws

and regulations are complied with3.Assets are safeguarded against loss

and theft4.Resources are used economically

and efficiently5.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 efficiently

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 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

Characteristics of the Maturity Levels


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

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


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

Which in turn is based on the waterfall methodology, first 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

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


SDLC to Maturity Models

Requirements Design Implementation Verification Maintenance

SDLC workflow

Maturity Model - Level 1






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 teamsAnd for the enterprise


Software delivery doesn’t have to be a long, uphill climb with no end in sight..

Phases or gated models break downDefinition and control conflict 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. Definition 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 processProcess is defined by its outcomes, not how work is done


Agile methods for small teams

Little divergence from common approachShared artifacts emerge naturally


Focus on outcomes not process definitionCompliance contributes directly to teamCapture the right artifactsInstitutionalize knowledge sharing


Agile methods at scale

Teams diverge from common approachArtifacts harder to share


•Teams adapt to •Development need•Experience curve

•Each team adapts in a different way•Legislating an approach cripples value delivery•Maybe define preferred approaches, especially

where definition 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

copyright 2011 agile42 consulting ltd

team name:

moredirective

moreguiding

each stage acts as a scaffold, offering guidance and support, for different phases of a team’s agile journey

agile teams first focus on smoothing flow and enhancing quality, leading to maximizing of value delivery

enhancing qualitymaximizing value

smoothing flow

� Everyone experiences SM� Team owns environment� Velocity guides release

� Reduces technical debt� Grow engineering practices� Automated PBI testing

� Business value drives work� Visible measure of value� Swarms on committed PBIs� Owns external dependencies

STEP 3. Maximize Valueorganize to deliver maximum value

� Cross-functional Teams� Regular backlog

grooming� PBIs broken into tasks� Transparent team

capacity� Daily stand-ups� Sprint burndown� Focus on 2-3 PBIs

� Working Agreement� PBIs for 1-2 sprints � Impediment backlog � Active Learning Cycle� Definition of Done� Definition of Ready� Potentially shippable� Vision and requirements

STEP 1. Organizepreparing the structures, work and

people

� Team takes 6-10 PBIs� Predictability over 90%� PBIs reviewed as done

� Shared code ownership� Technical debt identified� Bugs actively fixed� 1-3 improvement actions� Release Definition of Done

� Business value understood� PBIs done in priority order

STEP 2. Gain Experience

people, process and work all settling in, focus on learning

� Specialist knowledge shared � Acceptance test-driven dev� Limited manual testing� Automated testing of NFRs� Communities of Practice� Shared Definition of Done� Stable and verifiable builds� Cross-cutting concerns� Entire team works on release

STEP 4. Scalegrow knowledge, share learning,

expand capabilities

the accompanying Growing Agile Teams worksheets provide more details behind the checklist for each step

Focus on framework and boundary objects

Guide self-awareness not maintain status quo



Auditing agile methods at scale



Auditing agile methods

• Focus on outcomes not process definition

• 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

Level 2 - repeatable

Level 3 - defined

Level 4 - managed

Level 5 - optimizing

Level 1 - initial

- process change management- technology change management- defect prevention

- software quality management- quantitative process management

- software product engineering- integrated software management- organization process definition

- software configuration management- software quality assurance- software project planning

~70%

~15%

<10%

<5%

<1%


‘If you are not embarrassed by the first 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




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


What is the benefit derived from implementation of specific large projects or enterprise-wide implementation of applications?



Takeaway: Business Assurance through....?

At the first 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


thank you

[email protected]: dave.sharrock

twitter: @davesharrockslides: slideshare.net/davesharrock

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

Henry Ford

Is an agile SDLC an oxymoron?

Business

Transcript of Is an agile SDLC an oxymoron?