Is an agile SDLC an oxymoron?
Upcoming SlideShare
Loading in...5
×
 

Is an agile SDLC an oxymoron?

on

  • 1,952 views

Adaptive software development processes epitomized by Agile methodologies are based on continual improvement – incremental changes that emerge as teams iterate and learn about the product they are ...

Adaptive software development processes epitomized by Agile methodologies are based on continual improvement – incremental changes that emerge as teams iterate and learn about the product they are developing. This appears to conflict with the world of the program office, responsible for defining the software development lifecycle (SDLC), in which a stable and repeatable development process with well-defined ownership and controls is a common objective. Using recent examples in which agile methods have been successfully introduced into large organizations with existing SDLCs, we consider the difficulties of creating a verifiable process when the process itself is continually being modified, and look at how software development can be managed and controlled without stifling the benefits of adaptive software development processes.

Statistics

Views

Total Views
1,952
Views on SlideShare
1,945
Embed Views
7

Actions

Likes
4
Downloads
61
Comments
0

3 Embeds 7

http://paper.li 5
http://www.linkedin.com 1
https://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Is an agile SDLC an oxymoron? Is an agile SDLC an oxymoron? Presentation Transcript

  • Is an agile SDLC an oxymoron?or how to do the right thing, not do thing rightagile42 | 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 technologyTechnical Due Diligence newly-minted CanadianPre-IPO IT Audits executive leanstartup outsourcingSDLC Definition fatherRegulatory Compliance & Agility enterprise transitions • PCI Compliance B2C data analysis kanban • Data Security seismology scrum • Telecommunications organizational excellence agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
  • 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 ISagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
  • Minimizing Audit: Doing the thing right• Audit goals• Introducing the SDLC• Agile SDLCs• Auditing agilityagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
  • With IT’s importance to the business growingsteadily, the governance aspects of IT clearlyhighlight the following as major components: • Alignment • Value realization • Service delivery • Risk managementAuditing Realization of Benefits from IT, S. Anantha Sayana, InformationSystems Control Journal, Vol. 3, 2005 agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
  • 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 efficiently 5. Established program/operating goals will be metagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
  • 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 PMOagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
  • 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)agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
  • 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 Outcomeshttp://en.wikipedia.org/wiki/Software_development_process and http://en.wikipedia.org/wiki/ISO/IEC_12207 agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
  • Capability Maturity Model IntegrationAccording to the SoftwareEngineering Institute, CMMI Characteristics of the Maturity Levelshelps"integrate traditionally separateorganizational functions,set process improvement goalsand priorities,provide guidance for qualityprocesses, andprovide a point of reference forappraising current processes." CMMI Overview. Software Engineering Institute. Sally Godfrey (2008) What is CMMI ?. NASA presentationagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
  • CMM (the precursor to CMMI) is based on the process maturity framework first described in the 1989 book Managing the Software Process by Watts Humphreyhttp://en.wikipedia.org/wiki/Waterfall_model agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
  • 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 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 1956http://en.wikipedia.org/wiki/Waterfall_model agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
  • SDLC to Maturity Models Maturity Model - Level 5 Maturity Model - Level 4 Maturity Model - Level 3 Maturity Model - Level 2 Maturity Model - Level 1 Requirements Design Implementation Verification Maintenance SDLC workflowagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
  • 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 progresshttp://agilemanifesto.org/ agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
  • Team-level SDLC http://www.ambysoft.com/essays/agileLifecycle.htmlagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
  • 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 http://www.ambysoft.com/essays/agileLifecycle.htmlagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
  • 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 http://www.ambysoft.com/essays/agileLifecycle.htmlagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
  • 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 deliveryagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
  • Auditing agilemethodsFor small teamsAnd for the enterpriseagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
  • Software deliverydoesn’t have to be along, uphill climb withno end in sight..Phases or gated models breakdownDefinition and control conflict withthe adaptive self-organizedapproach of agile methodsagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
  • 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 itagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
  • Focus on outcomesover control gatesControl small changes to thewhole, not steps in the processProcess is defined by itsoutcomes, not how work is doneagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
  • Agile methods forsmall teamsLittle divergence from commonapproachShared artifacts emerge naturallyagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
  • Focus on outcomes not process definition Compliance contributes directly to team Capture the right artifacts Institutionalize knowledge sharingagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
  • Focus on outcomes not process definition Compliance contributes directly to team Capture the right artifacts Institutionalize knowledge sharingagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
  • Focus on outcomes not process definition Compliance contributes directly to team Capture the right artifacts Institutionalize knowledge sharingagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
  • Focus on outcomes not process definition Compliance contributes directly to team Capture the right artifacts Institutionalize knowledge sharingagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
  • Agile methods atscaleTeams diverge from commonapproachArtifacts harder to shareagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
  • •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)agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
  • Focus on framework and boundary objects Guide self-awareness not maintain status quo Share success not best practicesagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
  • 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 Share success not best 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 guidingcopyright 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 Share success not best practicesagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
  • 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 practicesagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
  • Maximizing Value: Doing the right thingagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
  • 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 agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
  • ‘If you are not embarrassed by the first version of your product, you’ve launched too late.’ Reid Hoffman, founder of LinkedInagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
  • http://www.ambysoft.com/essays/agileLifecycle.htmlagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
  • Lean Startup to DevOpsagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
  • Ineffective and unimaginative IT can mean the loss of opportunities, markets and customers Auditing Realization of Benefits from IT, S. Anantha Sayana, Information Systems Control Journal, Vol. 3, 2005agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
  • How well does IT serve the business? What is the state of effectiveness of IT for the business to date? Auditing Realization of Benefits from IT, S. Anantha Sayana, Information Systems Control Journal, Vol. 3, 2005agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
  • What is the benefit derived fromimplementation of specific largeprojects or enterprise-wideimplementation of applications? Auditing Realization of Benefits from IT, S. Anantha Sayana, Information Systems Control Journal, Vol. 3, 2005agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
  • Takeaway: Business Assurance through....?At the first level, IT in every organization seeks to perform the most widely usedand common functions.At the next level, IT should seek to support the business strategy through closeralignment and enterprise information systems that provide substantial support forcarrying 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 bysuggesting to the business new possibilities in various aspects, such asproduct development, reaching new markets and rolling out newerbusiness models that are completely enabled by IT, thereby giving the businessopportunities that would have not been otherwise possible. Auditing Realization of Benefits from IT, S. Anantha Sayana, Information Systems Control Journal, Vol. 3, 2005agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
  • 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 Europeagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
  • 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=X1jWe5rOu3gagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
  • “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/davesharrockagile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.