Upload
mike-cottmeyer
View
5.894
Download
2
Embed Size (px)
Citation preview
Where to go for the presentation
Mike’s blog: http://www.leadingagile.comBrian’s blog: http://blog.softwarearchitecture.com
Who is Mike Cottmeyer?
• Have been on the VersionOne service team for about 8 months
• Prior to joining VersionOne I was a Senior Project Manager for CheckFree Corporation in Atlanta, GA
• Certified Scrum Master, PMP, DSDM Agile Project Leader
Who is Brian Sondergaard?
• Director of Architecture at CheckFree (now a part of Fiserv)
• Instrumental in bringing agile to Fiserv
Overview of the next 90 minutes
• Not a questioning agile talk• This is a scaling agile talk• It is a talk about applying
agile from “concept to cash”• It is a talk about making
agile work in real organizations
• Lot’s of stuff to cover • Links to resources at the end
Our Agenda• 15 minutes setting up
the problem• 15 minutes talking
about core UP and Agile principles
• 45 minutes explaining how it all works
• 15 minutes for questions
Methodology pragmatist
• We are passionate about the values and principles of Agile
• We love stories about wholesale agile transformation
• But… we’re going to do what it takes to get the job done
Most teams are not there…
• Many are doing agile under less than agile circumstances
• As an agile community we need to help people where they are
• …but get them where they need to be
Our story…• Started with a small
colocated team• Product took off • Team grew, 70 plus
including offshore• Our product was
beginning to leveraged as a shared service across the organization
…a little more story
• We were beginning to depend on other enterprise services for our product
• Our product became a product of products
What is a product of products?
Payments Services
Risk Services
Business Intelligence
Corporate Financials
Online Banking
X X X X
Phone Banking
X X X
Payment Processing
X X
Remittance Processing
X X
Complex product architecture
Partner Communication
Payments Risk
Bus Intel/ Reporting
Business Intelligence
Corporate Financials
Small team agile doesn’t resonate
• Shared code ownership
• Teams responsible for entire architecture
• Legacy systems with little automation
• Tightly coupled architectures
Big company overhead
• Document based tollgates
• Corporate governance and decision making
• Traditional Project Management Offices
Scrum is really simple
• Scrum is a simple framework
• Deliver in short cycles, inspect outcomes, and adapt process or requirements
• Some role definition, daily stand up meetings, planning process, etc.
Devise and execute the best processes possible based on their skills, experience, and the situation in which they find themselves
Scrum is not enough
• Business case• Vision• Backlog (where
does it come from?)• Architecture• Documentation• Release plans and
roadmaps
Other Challenges
• Interfaces with external organizations
• When there are lots of team members
• Geographically distributed• Offshore team members• Closed workspaces• Large systems
architectures• External dependencies
Is this even agile?
• Maybe not• Lots of smells• Agile thinking
and agile practice can still be valuable
What do we build around
• Iterative and incremental delivery of working software
• Short cycle planning with an integrated customer
• Small, independent stories• Empowered teams • Autonomy and self
organization• Ownership and Accountability
Scrum-but introduces risk
• Deviating from agile practice introduces risk
• We need to be intentional about how we mitigate that risk
Mitigating process Risk
• As we scale, we often need to have more things written down
• We need to be more intentional about architecture
• We need to be more intentional about requirements
Why bother talking about UP
• Provides an iterative and incremental delivery structure
• Guidance for writing and breaking down requirements
• Patterns for dealing with software architecture
Why bother talking about UP
• Structure for necessary documentation
• Provides process guidance for all aspects of the SDLC, not just development
Most teams are making tradeoffs, lets be intentional about managing those tradeoffs and understanding the risks
Common myths about UP
• Adopting UP means adopting Rational Tools
• UP is too big• UP is too document
focused• UP is not configurable
People in the agile community really HATE the Unified Process, especially the
RUP
Process gone bad
• UP is designed to be configurable
• In practice people do UP poorly
• UP with a waterfall, predictive focus
• Agile with an undisciplined ad-hoc focus
How do we make all this work?
• Take what is good about agile, what scales, and leverage it
• Replace what doesn’t work with certain components of the UP
• Keep things as simple as possible
How do we do this right?
• We want to be as agile as possible
• We want to implement as little structure as possible to scale
• Give people across all the teams a common language, minimal standardization, and some degree of coordination
• Stay risk focused!
What agile should I keep?
• Small teams, teams of teams if necessary
• Short planning cycles
• Visibility, inspection, adaptation
• Retrospectives• Integrated onsite
customer
What agile should I keep?
• Progressive elaboration of plans
• Small independent stories
• Autonomy and self organization
• Ownership and accountability
What UP stuff should I keep?
• Sprit of RUP• Phases• Iterations• Use Cases• Deliberate
Architecture• Some artifacts
What agile stuff might go away?
• No documentation• No planning• Emerging
architecture• Universal shared
code ownership
What UP stuff might go away?
• Role definitions• Process guidance
unless something has value in our context
• Most artifacts
Spirit of UP
• Attack major risks early and continuously, or they will attack you
• Ensure that you deliver value to your customer
• Stay focused on executable software and the “product”
• Accommodate change early in the project
Spirit of UP
• Baseline an executable architecture early
• Build your system with components
• Work together as one team
• Make quality a way of life, not an afterthought
UP phases explained
ConstructionConstructionElaborationElaborationInceptionInception TransitionTransition
LifecycleObjectiveMilestone
LifecycleArchitectureMilestone
Initial OperationalCapabilityMilestone
ProductRelease
Milestone
Are the technical Are the technical risks mitigated?risks mitigated?
Are the Are the logistical risks logistical risks mitigated?mitigated?
Are the business Are the business risks mitigated?risks mitigated?
Are we really Are we really ready to ship a ready to ship a complete complete robust product robust product to market?to market?
Effort and duration by phase
Inception Elaboration Construction Transition
Effort 5% 20% 65% 10%
Schedule 10% 30% 50% 10%
Inception Elaboration Construction Transition
A more Agile representation?
Iteration Zero Iteration H
Iteration 1 Iteration 2 Iteration 3
Internal Release*
Inception Outcomes
• Clarify the Vision• Initial Backlog• Preliminary estimates• One possible solution• Validation of the
business case• Business risk
mitigated• Stakeholder
agreement
Inception Activities
• Meetings between product owner, architect, and analyst to evolve the product backlog and the candidate solution
• Balance the needs of the business with the capability of the team and feasibility of the solution
• Review the outcome with the business, manage expectations, go/no-go decision
Inception Artifacts
• Business case• Vision• Use Case Inventory• Risk Assessment• Candidate
architecture
Elaboration Outcomes
• Architectural spikes completed• Architecturally significant backlog
done• Validated systems architecture• Walking skeleton• Product backlog “fully” defined• Technical risk mitigated• Backlog re-estimated• Business decision to move forward
Elaboration Activities
• Validate systems architecture by building out backlog items that will “prove” the architecture
• Performance testing• Security testing• Backlog creation• Arch/Tech Spikes
• Consensus on major “forces”
• Clarity of boundaries• Agreement on where
we’re going• “Stay between the
lines”
Establish architecture “guardrails”
Scrum of Scrums
Epic/System Perspective
Feature/SubsystemPerspective
Story/Component/ DesignPerspective
Scrum of Scrums• Higher level scrums
integrate the scenarios of the component teams
• Breakdown application and zip it back up
• Automation at each level of the breakdown/rollup
Elaboration Artifacts
• Updated Product backlog• Use case scenarios defined• Go forward architectural
representation• Done backlog items• Test plan/test results• Fully integrated and working
subset of the system
Construction Outcomes
• Product built• Product fully tested• Product
documentation completed
• Logistical risks mitigated
• Business decision to release to market
Construction Activities
• Most ‘agile’ of all phases
• Teams building features from the backlog
• Testing• Documentation• Measure velocity• Project management
Construction Artifacts
• Evolving backlog• Design
documentation• Code• User
documentation• Test results
Transition Outcomes
• Product finalized and ready to be released
• Any remaining issues resolved
• Preparation for handoff
• Transition to support or operations
• Production deployment
Closing remarks
• Might not need to bother if you are a small collocated agile team
• Be pragmatic about process and adopt things that make sense for the size and complexity of your organization
• Be intentional about the tradeoffs you are making and mitigate process risks
• Done right, there are some concepts from RUP you can use to help mitigate these risks
Valuable RUP concepts
• Sprit of RUP• Phases• Iterations• Use Cases• Deliberate Architecture• Some artifacts
Where to go for more info…
• Scaling Software Agility – Dean Leffingwall• Agile Project Management With Scrum – Ken
Schwaber• Managing Iterative Software Development
Projects – Kurt Bittner, Ian Spence• Scott Ambler
http://www.ambysoft.com/unifiedprocess/agileUP.html
• DSDM http://www.dsdm.org/products/atern.asp
Where to go for the presentation
Mike’s blog: http://www.leadingagile.comBrian’s blog: http://blog.softwarearchitecture.com