Agile Development Product Delivery For Successful Organizations

Product Delivery for Successful OrganizationsAgile Development:

© Copyright Pacific Technology Consulting Group, LLC

Marc Crudgington

Interactive Agenda:Pick a Topic

Tools

Scrum

Build Delivery

Framework vs. Process

Agile Success

Adopting Agile

Agile Types

Agile Principles

Impediments

Resources Iterative or Predictive

Estimating/Planning

Evolution

Buzzwords

2

3

• Career– US Air Force, 3Com, ONI/Ciena, Mortgage/Countrywide, KPMG,

Jefferson Wells, Autobytel, ASM

• Entrepreneurship– Adventure Travel, Consulting, Mortgage, Consulting

• Education– MBA, BBA, ACS, AEE

• Certifications– PMP, CSM, TOGAF, ITIL, ISS, CISM, CISA

• Personal– Married to Maricris 01/2004, Two boys: Jake 5 / Luke 2

Bio / Info

4

Framework vs. Process

Framework Process

• Set of principles with no parent-child relationship which within activities are performed.

• Not all components required to be used

• Not always used in the same order

• Less structured• Agile

• Prescriptive and linear series of steps taken to repeatedly generate the same output.

• All components used• It is a sequence / same order• Structured• PMBOK (Project Management

Body of Knowledge), Waterfall

5

• Characteristics– Plan driven, heavy load upfront, structured– Sequential, bureaucratic, change resistant– Design: intensive, 10%; Construction manual, 90%– End result pre-determined

• Steps– Idea, Requirement, Design, Construct, Integrate, Test,

Implement, Maintain

Iterative or PredictivePredictive

6

• Use when– Project familiar– Inexperienced developers– Project team is large and project is complex– Thoroughly documented, demands order– Predictability versus change, requirements stable

• IMO– Civil engineering, Construction– Maybe government, government contractors, pharma?

Iterative or PredictivePredictive

7

• Characteristics– Ambiguity okay, code oriented, adaptable– Welcome change, feedback, people vs. process– Design: creative, 80%; Construction automate, 20%– End result evolving

• Steps– Brainstorm/plan, Development, Deliver, Feedback

Iterative or PredictiveIterative

8

• Use when– Project evolves or a little unknown– Accept change– Team small; strategies for large/split– Rapid change can occur

• IMO– Information Technology

Iterative or PredictiveIterative

9

Iterative or PredictiveComparison

Agile Waterfall

Informal/Incremental Documented/Steps

Teamwork/Collaboration Individual

Continuous Integration End or Milestones

Light process Heavy process

Open door Limited

Cross trained Segmented

Active developers Developers sit and wait

No surprises at end Validate requirements

QA helps produce QA certifies

Empowerment Controlling

Best app for customer Satisfy requirements, contracts

10

Agile PrinciplesManifesto for Agile Software Development

We are uncovering better ways of developingsoftware by doing it and helping others do it.Through this work we have come to value:

Individuals and interactions over processes and toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiationResponding to change over following a plan

That is, while there is value in the items onthe right, we value the items on the left more.

11

Agile PrinciplesPrinciples behind the Agile Manifesto

We follow these principles: 1. Our highest priority is to satisfy the customer through early and

continuous delivery of valuable software. 2. Welcome changing requirements, even late in development.

Agile processes harness change for the customer's competitive advantage.

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

4. Business people and developers must work together daily throughout the project.

5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

12

Agile PrinciplesPrinciples behind the Agile Manifesto (cont.)

7. Working software is the primary measure of progress. 8. Agile processes promote sustainable development. The

sponsors, developers, and users should be able to maintain a constant pace indefinitely.

9. Continuous attention to technical excellence and good design enhances agility.

10. Simplicity--the art of maximizing the amount of work not done--is essential.

11. The best architectures, requirements, and designs emerge from self-organizing teams.

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

13

Agile Principles

Authors of the Agile Manifesto

Kent BeckMike BeedleArie van BennekumAlistair CockburnWard CunninghamMartin Fowler James GrenningJim HighsmithAndrew Hunt

Ron JeffriesJon KernBrian Marick Robert C. MartinSteve MellorKen SchwaberJeff SutherlandDave Thomas

14

Adopting Agile

15

Adopting Agile Success Factors

• Business problem to solve− Goal to achieve; visible

• Freedom to change− No micromanaging; right people in, wrong people moved

• Engergized team− Familiar with; team spirit; about product/goal

• Customer communication− Dedicated; gets ’it’; respected in organization

• Collaboration− must work together; fight the ”PC glare”

• Quality focused− up front; clean; embodied in the product; automate

• Incrementalism− JIT features; small chunks; task-by-task

16

Adopting Agile Adoption Patterns

• Start Small− Pilot team; >$ for mistakes, success optimized, experts− False hope, takes longer, sign of non-commitment, two types

• All In− All teams; management commitment, quicker, one type− Risk, cost, reorg (?), stress

• Technical Practices First− Concentrate on how to develop; quicker transition− More difficult, costly, less user-centric thinking

• Iterative First− Concentrate on the repetitive cycles; less resistence, easier− May not adopt necessary engineering processes

17

Adopting Agile Adoption Patterns (cont.)

• Stealth Mode− Kept to the Agile team; focus on success, less distractions− No org support, skeptics

• Times Square Approach− Communicated; success incentive, support, out skeptics− Announce then fail, skeptic disruption, ’vendor wolves’

Organizational Effects

• Developers; micromanage/freedom/talent | no forethought

• Management; new features, progress, impact, project end

• HR; receive complaints, corrective action,

• Marketing; feature announcement, release date, left out

18

Adopting Agile

Top-Down Bottom-Up

Organization sponsored Department/Project sponsored

Visibility Fewer Monday Morning QB’s

Executive strength Focused pressure

Central change team Freedom to define change

Execution consistency Time to learn, refine process

More measurable Still measurable

Business problem solution Appropriate business problem

• Communication • Best practice / learn from Agile Coach• Tools to assist• Raise the bar• Plan for management and governance

19

Impediments

TeamOrganization

• Agile knowledge

• Work in silos

• Individual resistance

• Proper tools

• Documentation requirements

• Management support

• Management control

• Department resistance

• Trust in team/process

• Investment required

• Unrealistic expectations

• Customer commitments

20

Agile TypesAgile Survey 2006

21

Agile TypesAgile Survey 2009

22

Agile TypesAm I Agile?

Adaptive, empowered, self-organizing

Absence of phases

Use of minimal planning

Scalable

Continuous process refinement

Iterative and incremental

Working software measured in progress

Artifacts are minimized

Customer involvement throughout

Adaptive, empirical customer relationship

Emergent requirements

Frequent inspection

Individuals and Interactions

Working software

Customer Collaboration

Responding to Change

23

Agile TypesFDD (Feature-Driven Development)

• Characteristics− UML modeling focused, iterative, testing absent, small teams

• Processes− Develop an overall model − Build a Features List− Plan by Feature− Design by Feature− Build by Feature

• Best Practices− Domain Object Modeling, Feature Teams, Visible Progress,

Developing By Feature, Inspections, Individual Class Ownership, Regular Builds, Configuration Management

− Requires all 8 to be FDD

Done Sequentially

Done Iteratively

24

Agile TypesFDD (Feature-Driven Development)

• Features− Primary unit of coding− Similar to XP User Stories or Scrum Product Backlog− Completed within two weeks

• Feature Set− Collection of features− Assigned to a Chief Programmer and team

• Major Feature Set− A domain area, one or more feature sets

25

Agile TypesAm I Agile?

Adaptive, empowered, self-organizing Not so much

Absence of phases No

Use of minimal planning No

Scalable Yes

Continuous process refinement Not so much

Iterative and incremental Somewhat

Working software measured in progress No

Artifacts are minimized Somewhat

Customer involvement throughout Yes

Adaptive, empirical customer relationship Yes

Emergent requirements No

Frequent inspection Yes

Individuals and Interactions

Working software

Customer Collaboration

Responding to Change

26

Agile TypesAgile Modeling

• Characteristics− Collection of values, principles, and practices− Meant to be tailored into other methodologies

• Values− Communication, Simplicity, Feedback, Courage, Humility

• Principles− Assuming simplicity (modeling), embracing change (working),

incremental change (agility), rapid feedback (reflects needs), model with a purpose (know)

− multiple models (for intellect), travel light (discard), content (many ways), communication (open/honest), quality (focus)

27

Agile TypesAgile Modeling

Best Practices

28

Agile TypesAm I Agile?

Adaptive, empowered, self-organizing Somewhat

Absence of phases Yes

Use of minimal planning Yes

Scalable Yes

Continuous process refinement Somewhat

Iterative and incremental Somewhat

Working software measured in progress Yes

Artifacts are minimized Yes

Customer involvement throughout Yes

Adaptive, empirical customer relationship Yes

Emergent requirements Yes

Frequent inspection Yes

Individuals and Interactions

Working software

Customer Collaboration

Responding to Change

29

Agile TypesXP (Extreme Programming)

• Characteristics− Collection of values and practices− 1 – 4 week iterations, all dials set to “10”− Stories (functionality), on-site customers− UNIT TESTING, simplest thing − YAGNI (You Aren’t Gonna Need It)

• Values− Simplicity: what is needed and asked for, no more− Communication: face to face, daily; work together on everything− Feedback: every iteration seriously delivering working software;

listen change as needed; adapt process to project − Respect: everyone contributes; developers respect customers vice

versa; management respects authority over work− Courage: truth about project/estimates; no fear no one works

alone; adapt to changes

30

Agile TypesXP (Extreme Programming)

Workflow

31

Agile TypesAm I Agile?

Adaptive, empowered, self-organizing Somewhat

Absence of phases Yes

Use of minimal planning Yes

Scalable Yes

Continuous process refinement Mostly

Iterative and incremental Yes

Working software measured in progress Yes

Artifacts are minimized Yes

Customer involvement throughout Yes

Adaptive, empirical customer relationship Yes

Emergent requirements Yes

Frequent inspection Yes

Individuals and Interactions

Working software

Customer Collaboration

Responding to Change

32

Agile TypesScrum

• Characteristics− Framework or Method NOT a Process or Technique− Self organizing teams− Progress in month-long or less “Sprints” (iterations)− Requirements are “Product Backlog”− Engineering “Free for Team”− Rules to maintain / be Agile on project

• Scrum Team− 7 to 11 members optimal (PO, SM, Team)− Full-time i.e. devoted to Scrum Team; exc. Sys Admin− Change only between Sprints

• Etc.− Sprint/Stabilization Sprint: Design, code, test− NO CHANGES during Sprints…take your scope creep and…− Few artifacts, Burndown charts

33

Agile TypesAm I Agile?

Adaptive, empowered, self-organizing Somewhat

Absence of phases Yes

Use of minimal planning Yes

Scalable Yes

Continuous process refinement Yes

Iterative and incremental Yes

Working software measured in progress Yes

Artifacts are minimized Yes

Customer involvement throughout Yes

Adaptive, empirical customer relationship Yes

Emergent requirements Yes

Frequent inspection Yes

Individuals and Interactions

Working software

Customer Collaboration

Responding to Change

34

Scrum Overview

• Scrum History– Presented 1995, Jeff Sutherland/Ken Schwaber– Not a process or technique, framework (within you can

employ processes/techniques

• Scrum Theory– Empirical process control: continuous cycle of inspection

for correct operation, adapt as needed– Three pillars for implementation

• Transparency: affect the outcome is visible to those managing; what is being seen must be known

• Inspection: to detect unacceptable variances; skill/diligence• Adaption: adjustment of unacceptable variances; quickly; Daily

Scrum, Sprint Review & Planning meetings; Sprint Retrospective

35

Scrum Overview

• Scrum Content– Scrum Team

• ScrumMaster, Product Owner, the Team

– Time-Boxes• Release Planning Meeting, Sprint Planning Meeting, Sprint,

Daily Scrum, Sprint Review, Sprint Retrospective

– Artifacts• Product Backlog, Sprint Backlog, Release Burndown, Sprint

Burndown

– Rules• Connect/unite each: Scrum time-boxes, roles, and artifacts• Rule: Daily Scrums last only 15 minutes• Rule: Only the Team talks during Daily Scrums

36

Scrum Overview

• Scrum Team– Product Owner

• One person only• Manages Product Backlog, ensures value of work

• Tip: product manager or business function manager – ScrumMaster

• Coaches Scrum Team / organization, removes impediments• Upholds Scrum values, practices, rules• Tip: works to identify and instantiate Product Owner

– Team• Developers• Tip: 7 optimal, + or – 2 is okay

37

Scrum Overview

• Scrum Time-Boxes– Release Planning Meeting

• Establishes: plan and goals, high priority Product Backlog, major risks, features/functionality

• Sets probable delivery date and budget

– Sprint• A time-boxed iteration, max is 1 month• Consist of Sprint Planning Meeting, development work, Sprint

Review, Sprint Retrospective• One after other, no time in between Sprints

– Sprint Planning Meeting• Iteration is planned, 8 hours for 1 month Sprint• What/How: top priority Product Backlog/Team decides work• Sprint Goal: objective through Product Backlog implementation

38

Scrum Overview

• Scrum Time-Boxes (cont)– Sprint Review

• 4 hours per 1 month Sprint, Scrum Team/stakeholders• What was done, what remains; what went well, problems,

resolution; demo of work, Q&A• Input for next Sprint Planning Meeting

– Sprint Retrospective• 3 hours per 1 month Sprint, Scrum Team• Inspect Sprint (people, relationships, process, tools)• Actionable improvements to implement in next Sprint

– Daily Scrum• 15 minutes, inspect/adapt, same place and time• What: Accomplished, Going to do, Obstacles• Improve communication/knowledge, remove impediments

39

Scrum Overview

• Scrum Artifacts– Product Backlog & Release Burndown

• Requirements for product, evolves and changes• List of all features, functions, technologies, enhancements, bug

fixes• Product Owner: contents, availability, prioritization• Graph for sum of Product Backlog effort in time

– Sprint Backlog & Sprint Burndown• Product Backlog tasks Team turns into “done” increment• Tasks decomposed/developed during Sprint Planning Meeting• One day or less per task (Sprint Backlog item)• Sprint Backlog only change by the Team• Burndown is a graph of daily estimates of remain sprint work

40

Scrum Overview

Sprint Burndown Chart

41

Scrum Overview

Scrum Sprint

42

The Planning Onion

Planning/EstimatingGeneral George S. Patton - "A good plan, violently executed now, is better than a perfect plan next week.”

43

• Organizations culture

• IT infrastructure investment

• Sponsor / Management commitment

• Project selection

• Agile team selection

• Training needed

• Expert access

• Project only assignment

• Mandatory documentation

Pre-planning points

Planning/Estimating

44

• All stakeholders

• Release goal

• Risks

• Conditions of Satisfaction (Features / Functionality, Delivery,

Budget)

• Priority of Feature Set (confirm project idea first)

• Estimating the Product Backlog or Feature Set

• Change Management strategy

• Define ’Done’

Release Planning

Planning/Estimating

45

• Daily Stand-up (Time/Place)

• Technical process

• Tools discussion (code migration, QA, project management,

Backlog)

• Iteration timebox

• Capacity of team

• Backlog priority (client: ”more of this, less of that”)

• Tasks to complete Product Backlog item

• Size of Product Backlog item

• Velocity (previous iterations/sprints)

Iteration Planning

Planning/Estimating

46

• Inspect and Adapt meeting

• Accomplishments

• Going to accomplish

• Impediments in the way

• Coordinate individual activities

• Wrap-up

Daily Planning

Planning/Estimating

47

• Product Backlog, Iteration Backlog, Tasks

• Size not Time

• Estimation types− Story points: Size and complexity, numerically relevant (10 = 5*2),

relative estimating, focus on size vs. duration, units added together− Planning poker: Iterative approach

1) Estimators get deck of cards with valid estimates2) Product owner reads story, briefly discussed3) Estimators selects card as estimate4) All estimators turn cards over5) Discuss differences (outliers)6) Re-estimate until they come together Good results: do the work estimate the work, justify estimates, group discussion, relative vs. absolute, involves all

− Fibonacci number: 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, ...

Estimating

Planning/Estimating

48

• Pair Programming– Typing, Reading, Both Thinking; discuss often, instant review, helps

inexperienced developers, accountability, collaboration

• No Code Ownership– Anyone can review and fix code; inexperienced limitations

• Code/Test– Automate tests; ‘smoke tests’, integration testing; raise visibility

• Test First Design– Writing code against test for requirements; think through design

• Refactoring– Improve readability and maintainability; reduce complexity

Build DeliveryCoding Practices

49

• Automate the Build– Repeatable, build anytime

• Build is Self-Testing– Build includes automated testing, covers large part of code base

• Daily Commits– Quicker failure, bugs/defects founds sooner

• Commits create Builds– Integration is tested daily

• Keep Builds Fast– Developers have status quickly; queue of builds, email status

Build DeliveryIntegrate Often

50

Tools • Consulting firm

– Agile transformation– All parts of organization

• Agile Coaches– Understanding of Agile processes; ease transition for team– Directory at: Agile Alliance and Scrum Alliance

• Project Management– Built for Agile (hosted/on-premise; high cost/low cost)– Agile templates, dashboards

• Build/Test– Integration, comparison; code evaluation, modeling, bug isolation

• Vendors/Products– Rally Software, CollabNet, IBM, Microsoft, JUnit/XUnit,

ScrumWorks, Electric Cloud, OpenMake Software

51

Tools

52

• Organization− For holistic success devote attention downstream− Manifesto implies organization (customer, business people,

feedback)− Greater role in decision making, product outcome− Better collaboration with other departments

• Organization Tips− Pick one problem to solve− Don’t forget governance and regulatory requirements− Incentives and Rewards− Customer interaction with departments

Agile SuccessImpact

53

• Agile Team− Development ownership in process (estimate, quality, delivery)− New techniques for meeting deliverables− Retrospectives/Feedback to immediate improvement− Defects caught early− PM’s/ScrumMaster becomes the snowplow− PM’s/ScrumMaster provide vs. need, coach vs. enforcer

• Agile Team Tips− Adopt the right mix (maybe more than one)− Initial focus on team principles and build practices− Team consistency/accountable to one another− Empowerment is not a noun, it is a verb− Do not under estimate the challenge of transforming− Utilize tools to fullest extent

Agile SuccessImpact

54

• Needs− Assessment plan− Support plan (training, coaches, management)− Balance business needs with technical − Realize change effects all moving parts− Smaller teams, self managed, reduced silos− New skills, automate the routine

• Results− More transparent organization− Realistic product horizons− Better moral− Reduced time to market− Quality improvement− Less surprises− Higher customer satisfaction

Agile SuccessFull Potential

55

• Done– Shippable increment of product containing all Product Backlog for

the increment– Must be additive to all prior increments– Defined by Team, Product Owner informed

• Continuous Integration– Integrating of code by team members at a frequent pace (daily)– Can produce numerous builds daily (10 team members = 10 builds)

• Kanban– A Lean Manufacturing “Pull” process developed by Toyota– Software development used the same process with a physical task

board (To Do, In Progress, Done, etc.)

Buzzwords

56

Resources

• People− Kent Beck, Jeff Sutherland, Tobias Mayer, Mike Beedle,

Ken Schwaber, Peter Hundermark, Jim Highsmith • Books

− Succeeding with Agile, Agile Estimating Planning, Scrum and XP from the Trenches, Continuous Delivery, Agile Software Development with Scrum, Agile Coaching

• Organizations− Agile Alliance, Scrum Alliance, Scrum.org, PMI

• Websites− (See Organizations), Google, Amazon, Forrester,

AgileJournal, MountainGoatSoftware, AgileManifesto.org, ExtremeProgramming.org, LinkedIn(groups), tech related

57

Sources

• Certified ScrumMaster Training, Conscires Agile Practices

• http://agilemanifesto.org/

• Scrum, Jeff Sutherland/Ken Schwaber, http://www.scrum.org, Feb.

2010

• Do Better Scrum, Peter Hundermark, ScrumSense, Nov. 2009

• The Truth About Agile Process, Carey Schwaber, Forrester, Aug. 2007

• The Forrester Wave: Agile Development Management Tools Q2 2010,

Dave West/Jeffrey Hammond, Forrester, May 2010

• From Agile Development To Agile Engagement, Tom Grant, Forrester,

May 2009

• Agile Development: Mainstream Adoption Has Changed Agility, Dave

West/Tom Grant, Forrester, Jan. 2010

58

Sources

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

• Planning and Tracking Agile Projects, Mike Cohn, Mountain Goat

Software, March 2007

• Agile Project Management: Estimating the Unknown, Rick Freedman,

TechRepublic, June 2009

• Agile Success Factors, Jeff Langr/Tim Ottinger,

agileinaflash.blogspot.com, July 2010

• New Patterns of Agile Adoption, Mike Cohn, Agile Journal, Jan. 2008

• Introduction an Agile Process to an Organization, Mike Cohn/Doris

Ford, IEEE, June 2003

• Scaling Up: An Approach to Organizational Agile Adoption, Ross Pettit,

Agile Journal, Nov. 2006

59

Sources

• Key Success Factors in Top-Down Agile Adoption, Ross Pettit, Agile

Journal, March 2007

• The Agile Heartbeat, John Graham-Cumming, Electric Cloud, 2009

• Best Practices for Implementing Agile Methods: A Guide for

Department of Defense Software Developers, Ann Fruhling/Alvin Tarrell,

University of Nebraska at Omaha, 2008

• Selecting an Agile Process: Choosing Among the Leading Alternatives,

Mike Cohn, Mountain Goat Software, Sept. 2004

• An Introduction to Agile Modeling, Scott Ambler, Ambysoft, 2006

• Feature-Driven Development, Peter Coad/Eric Lefebvre/Jeff De Luca,

Java Modeling in Color with UML, Prentice Hall, June 1999

• http://www.microtool.de/instep/en/prod_scrum_edition.asp

60

THANK YOU!