Agile Development

Presented to PMAGL. Lowe, G. Mays and J. Skinner

April 19,2010

2

Agenda

What Is Agile Development Why Use Agile (WIFM) Agile vs. Waterfall Agile & PPM State Agency Experience Next Steps References

3

What is Agile DevelopmentAgile is a team driven iterative approach to development where the users and product owner are constantly involved with the development team during the entire project life cycle.

Uses simple adaptable processes Continuous communication with stakeholders Empowers people to collaborate and make decisions quickly Relies on continuous planning, testing and integration Uses iterations, incremental delivery and continuous

feedback to refine and deliver the product Methodologies include Extreme Programming (XP), Scrum,

Crystal, Dynamic Systems Development Method (DSDM), Lean Development & Feature-Driven Development (FDD)

4

Agile Manifesto for Software Development

We are uncovering better ways of developing software; we have come to value:

Individuals & interactions

over

Processes & tools

Working software early Comprehensive documentation

Customer collaboration Contract negotiation Responding to change Following a plan

While there is value in the items on the right,

we value the items on the left more. Agile Manifesto www.agilemanifesto.org

5

Agile Principles Customer satisfaction is #1 priority Deliver early, continuous value Embrace change and uncertainty Business and developers work together Provide motivated individuals the work

environment and support they need to succeed Communicate face to face (co-locate if possible) Best architectures, requirements, and designs

emerge Trust the team to get job done

6

Why Use Agile (WIFM)Current Approach:

Budget overruns Missed target dates Too many projects Not enough people Scope creep (addressed with future projects)

Everything is top priority Fire-drills and instability wreck havoc

Agile Promises: Quality – produces reliable products/services Productivity – increases effectiveness, deliver quickly and on-time Value - brings customer value as soon as possible Innovation – fosters creativity

7

Agile: Better ProductivityAgile Adoption & Team Productivity

1%1%5%

62%

31%

Significantly Better

Better

Unchanged

Somewhat Worse

Much Worse

Source: http://www.shinetech.com/attachments/104_ShineTechAgileSurvey2003-01-17.pdf

8

Agile: Better Quality

Source: http://www.ambysoft.com/surveys/agileFebruary2008.html

Impact of Agile on System Quality

29%

48%

14%

6% 3% Much Higher

Somewhat Higher

No Change

Somewhat Lower

Much Lower

9

Agile: Better All Around

52

40

58

17

54

20

50

24

51

20

44

22

0

10

20

30

40

50

60

70

80

90

100

ManageChangingPriorities

IncreasedProductivity

ImprovedTeamMorale

EnhancedSoftwareQuality

AccelerateTime-to-Market

Business/ITAlignment

Value Actually Realized From Agile

Significantly ImprovedImproved

Source: http://www.versionone.net/pdf/AgileDevelopment_ResultsDelivered.pdf

10

Agile Vs. Waterfall

Agile Mindset… Waterfall Mindset…

Goal Deliver smaller product releases faster, improve as you go (incremental and iterative)

Follow a baselined project plan

Change Embraces changing, adaptable, flexible scope

Deliver approved requirements for current increment

Expect and welcome new features; address scope creep in future increments

Predictable, stable, well defined requirements, tight scope control

Avoid out-of-control changes and gold-plaiting

Rebaseline project as needed to handle approved change requests

Repeatability

Unique product, each project is different

Standard templates, software has similarities and the process to create it fits into repeatable steps

11

Agile Vs. Waterfall

Agile Mindset… Waterfall Mindset…

Process Empirical process – experimental with uncertain requirements and deliverables

Emergence model (experience, observe, adapt, fine-tune) use of prototyping (build + test)

Individuals and interactions valued

Definitive process - defined process with known requirements and deliverables

Pre-formulated, repeatable, defined

Processes and tools add value in the hands of competent staff

Formality/Structure

Informal, fluid, unstructured Products defined incrementally

and rapidly

Formal, definite, structured Products designed and defined

before building

Planning Team guided by expertise without formally defined project plans

More important to respond to business driven change than follow a plan

Event–based planning using project management processes

Well defined project plans

12

Agile Vs. Waterfall

Agile Mindset… Waterfall Mindset…

Phases Smaller product releases May include multiple,

simultaneous or sequential "waterfalls”

Allows requirements to change

Work Phases (requirements, design, construction ,implementation) executed in single linear process

Permits change via defined change management process

StatusReporting/Oversight

Direct transparency into progress and status for all stakeholders

Accountable to the customer Customer sees work getting

done daily rather than reviewing written reports

Project status and delivery of services are visible to management at defined points

Formal governance and oversight bodies receive periodic written and verbal status updates

Quality &Communicati

on

Formal processes block open communication

Team collaboration produces a quality product

Formal Communication Plans High quality work results from

structure and Quality Management plans

13

Agile Vs. WaterfallAgile Mindset… Waterfall Mindset…

Issue & RiskManagement

Highly proactive –impediments get resolved daily

Empowered team makes decisions, takes action and resolves issues promptly

Easier to fix a problem than log and track it

Formal issue and risk management disciplines

No issues/risks are lost in the shuffle

May take longer to remove impediments

Documentation

Working software is more critical than full documentation

Only develop documentation that adds value to product

Easier to collect and act on raw data than spend time developing perfect documents

High quality documentation using standard templates prepared, reviewed and formally approved (time consuming & costly)

14

Agile & PPM

Agile is Easy….

Implementing it is Hard…

…Must changeProcesses and

Values…

15

Agile & PPM: Lifecycle

Agile (Scrum) Lifecycle

Vision/Discovery ( imagine)

Release Planning (envision)

Sprint Planning (plan)

Iteration (create)

Review (show)

Retrospective (adapt)

PPM Lifecycle

Phase 1: Project Initiation Phase 2: Planning & Design

A few early iterations (sprints) occur here

Phase 3: Execution & BuildVast majority of iterations (sprints) occur here

Phase 4: ImplementationFinal iteration (sprint) occurs here

Phase 5: Closeout

16

Agile & PPM: Artifacts

Key Agile (Scrum) Artifacts Vision - Elevator Statement (For …, product/system is … that …. Unlike …, product/service can …) Stories – link to Vision and capture customer expectations and requirements (As a …, I want …, so that …) Product Backlog – is a list of prioritized stories broken down to make it easily consumable within a single sprint Sprint Backlog – actual work that the team commits to deliver in the current sprint; contains all tasks and tests to complete a subset of work Burndown Chart – is a visual indicator and constant reminder of remaining work to complete Potentially Shippable Increment – focus on Minimal Marketable Product (MMP)

17

Agile & PPM: ArtifactsKey PPM Artifacts

Agency Artifacts: Acceptance Criteria Change Management Plan Communication Plan Configuration Management Plan Deployment/Rollout Plan Disaster Recovery/Business Continuity Plan Operations and Maintenance Transition Plan Pilot Phase Results Project Plan Quality Assurance Plan Risk Management Plan Statement of Work (SOW) Test and Acceptance Results Test Plan Training Plan Work Breakdown Structure

SCIO Required Artifacts: Alternatives Analysis (projects >$10M) Business Requirements Cost Estimate Lessons Learned Procurement Plan Staffing Plan Technical Architecture System Design (TASD)

NOTE: See handout that shows mapping/XRef that relates PPM artifacts with corresponding Agile artifacts.

18

State Agency Experience

Challenges Encountered

Agile Principle State Government RealityStrive for efficiency, fast decisions, quick delivery to customer

Can take 2-4 times longer in state government

Co-located fully dedicated team members

Staff wear many hats - stretched too thinFacility limitations not conducive to co-locating

Best infrastructures evolve (stick vs. stack)

Environments must exist to do Sprints, yet: Procurement not allowed until after Gate 1 Fully defined TASD required for Gate 2

Project Structure: Team consists of Pigs (Chickens are out)

Agency PMO, statewide EPMO, architects at Agency and Statewide level, plus other supporting external groups influence project outcomes and impact progress/speed

19

Pig – Someone occupying one of the three Scrum Roles (Team, Product Owner, Scrum Master) who has made a commitment and has authority to fulfill it.

The Pig’s Point Of View

20

On the Job Training- Real Experience

Terminology is different; processes are different but the goals are the same.

Meet the requirements, on time, and if possible under budget.

The Product Backlog provides the overall game plan and replaces the requirements document.

The Sprint Backlog sets the pace and determines the work or tasks to be done.

Expect the first Agile project and first few sprints to be “Lessons Learned”.

21

Sprint Backlog

The Sprint Backlog is similar to the Gantt Chart

22

The First Agile Project – First Sprint 2008

Very First Sprint

23

Current Agile ProjectMost recently completed Sprint of our 4th Agile Project

24

State Agency Experience: Lessons Learned

Build time in for training and learning curve Planning and real life don’t always match – getting hands dirty

up front saves time and effort over long run Very little time to “explore” different possibilities in a SPRINT if

one did not work SCRUM does not fit all projects - best system development

methodology depends on nature of the project, organization and other factors

Harder to use pure SCRUM methods in database centric projects

There are tradeoffs to simplifying the workflow too much - more detail gets more information, but takes too long

Useful to forge ahead in spite of unexpected obstacles Prioritizing what was important helped a lot

25

State Agency Experience: Lessons Learned

Very talented, focused people can move along very quickly, given opportunity to do so

Fully dedicated resources are essential for optimal work product Daily meetings were very useful to keep momentum going, and

information flowing SCRUM Master stays very busy removing obstacles and keeping

team focused Useful to keep documentation to a minimum, yet documentation

of process and decisions was important Detail in documentation is critical for future recall and decision

making Team found delivery of implementable product in a short period

of time very satisfying Media capability may enhance virtual team efficiency when co-

location is not viable – e.g. collaborating with websites and video conferencing

26

Next Steps The Enterprise Project Management Office

Improvement Plan for FY09-11 addresses items identified in our recent agency survey. Comments indicated the need to review the project approval processes for system development life cycles other than SDLC.

An agency workgroup will be formed to develop best practices for systems development life cycles (SDLCs) such as waterfall, agile and infrastructure projects.

27

References: WebsitesAgile Alliance www.agilealliance.org

Agile Project Leadership Network

www.apln.org

Agile Manifesto www.agilemanifesto.org

Agile Modeling www.agilemodeling.comwww.rallydev.com

Agile Software Development

www.agilesoftwaredevelopment.comwww.epmo.scio.nc.gov/library/pdf/AGILE_Development.pdf

Scrum www.controlchaos.comwww.mountaingoatsoftware.com/scrumwww.scrumalliance.comwww.implementingscrum.com

28

References: BooksAnderson, David J.

Agile Management for Software Engineering - Applying the Theory of Constraints for Business Results.

Upper Saddle River, NJ: Prentice Hall, 2009.

ISBN 0-13-142460-2

Cockburn, Alistair

Agile Software Development: The Cooperative Game. 2nd Edition

Boston: Addison-Wesley, 2006.

ISBN-13: 9780321482754

Cohn, Mike Agile Estimating and Planning. Prentice Hall, 2005.

ISBN-13: 9780131479418

Highsmith, Jim Agile Project Management: Creating Innovative Products. 2nd Edition.

Pearson Education, 2009.

ISBN 0-321-21977-5

Highsmith, Jim Agile Software Development Ecosystems.

Pearson Education, 2002.

ISBN 0-201-76043-6

Larman, Craig Agile and Iterative Development: A Manager's Guide.

Pearson Education, 2004.

ISBN 0-13-111155-8

Martin, Robert Agile Software Development, Principles, Patterns, and Practices.

Saddle River, NJ: Prentice Hall, 2002.

ISBN-13: 9780135974445

Schwaber, Ken Agile Project Management with Scrum. Redmond, WA: Microsoft Press, 2004.

ISBN 978-0-7356-1993-7

Schwaber, Ken and Beedle, Mike

Agile Software Development with Scrum.

Upper Saddle River, NJ: Prentice Hall, 2004.

ISBN 0-13-067634-9

29

Conclusion Being Agile Is Our Favorite Thing

30

Questions