Weitere ähnliche Inhalte Ähnlich wie Is an agile SDLC an oxymoron? (20) Mehr von Dave Sharrock (20) Kürzlich hochgeladen (20) Is an agile SDLC an oxymoron? 1. 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.
2. 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 Definition father
Regulatory 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.
3. 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
agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
4. Minimizing Audit: Doing the thing right
• Audit goals
• Introducing the SDLC
• Agile SDLCs
• Auditing agility
agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
5. 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
agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
6. 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 met
agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
7. 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
agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
8. 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.
9. 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
agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
10. 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
agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
11. 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
agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
12. 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 1956
http://en.wikipedia.org/wiki/Waterfall_model
agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
13. 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 workflow
agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
14. 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/
agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
15. Team-level SDLC
http://www.ambysoft.com/essays/agileLifecycle.html
agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
16. 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.html
agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
17. 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.html
agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
18. 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
agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
19. Auditing agile
methods
For small teams
And for the enterprise
agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
20. Software delivery
doesn’t have to be a
long, uphill climb with
no end in sight..
Phases or gated models break
down
Definition and control conflict with
the adaptive self-organized
approach of agile methods
agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
21. 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
agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
22. Focus on outcomes
over control gates
Control small changes to the
whole, not steps in the process
Process is defined by its
outcomes, not how work is done
agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
23. Agile methods for
small teams
Little divergence from common
approach
Shared artifacts emerge naturally
agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
24. Focus on outcomes
not process definition
Compliance contributes
directly to team
Capture the right
artifacts
Institutionalize
knowledge sharing
agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
25. Focus on outcomes
not process definition
Compliance contributes
directly to team
Capture the right
artifacts
Institutionalize
knowledge sharing
agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
26. Focus on outcomes
not process definition
Compliance contributes
directly to team
Capture the right
artifacts
Institutionalize
knowledge sharing
agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
27. Focus on outcomes
not process definition
Compliance contributes
directly to team
Capture the right
artifacts
Institutionalize
knowledge sharing
agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
28. Agile methods at
scale
Teams diverge from common
approach
Artifacts harder to share
agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
29. •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.
30. Focus on framework
and boundary objects
Guide self-awareness
not maintain status quo
Share success not best
practices
agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
31. 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 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
32. Auditing agile methods at scale
Share success not best
practices
agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
33. 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
agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
34. Maximizing Value: Doing the right thing
agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
35. 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.
36. ‘If you are not embarrassed by the first version
of your product, you’ve launched too late.’
Reid Hoffman, founder of LinkedIn
agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
38. Lean Startup to DevOps
agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
39. 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, 2005
agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
40. 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, 2005
agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
41. What is the benefit derived from
implementation of specific large
projects or enterprise-wide
implementation of applications?
Auditing Realization of Benefits from IT, S. Anantha Sayana, Information Systems Control Journal, Vol. 3, 2005
agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
42. 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.
Auditing Realization of Benefits from IT, S. Anantha Sayana, Information Systems Control Journal, Vol. 3, 2005
agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
43. 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
agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
44. 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
agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.
45. “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
agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.