iterative methodologies - osehra · •a single iteration results in one or more bite-sized ......

23
ITERATIVE METHODOLOGIES WHAT WORKS AND WHAT DOES NOT WORK Rosemary Nelson, Principle Investigator Janet Fuller, Project Manager September 6, 2013

Upload: vuphuc

Post on 16-Jun-2018

221 views

Category:

Documents


0 download

TRANSCRIPT

ITERATIVE METHODOLOGIES WHAT WORKS AND WHAT DOES

NOT WORK Rosemary Nelson, Principle Investigator

Janet Fuller, Project Manager September 6, 2013

Presentation Objectives

• Can you be iterative and incremental and not be agile?

• Popular Agile Methodologies

– What works

– What doesn’t work

• Projects not suited for Agile

• Agile Ice Cream Shop

2

• Iterative 1

• Incremental 2

• Agile 3

Can you be Agile if you are iterative and incremental?

3

• Iterative 1

• Definition: a procedure in which repetition of a sequence of operations yields results successively closer to a desired result.

• A single iteration results in one or more bite-sized but complete packages of project work that can perform some tangible business function.

4

• Definition of Incremental:

• The process of increasing in number, size, quantity, or extent;

• Something added or gained;

• A slight, often barely perceptible augmentation;

• One of a series of regular additions or contributions.

5

• Definition of Agile: able to move quickly and easily

• Agile Methodologies:

• Methods for designing software that have proven to be more effective in dealing with business realities such as changing requirements during development. It promotes industry best practices that emphasize teamwork, customer involvement and the frequent creation of small, working pieces of the total system.

6

Can you be iterative and incremental and not be Agile? • Yes

– Agile includes several human collaboration aspects.

– Note: Many waterfall approaches include iterations (prototyping) and breaking project work into small increments.

Can you be using an Agile method and not be agile?

• Yes

– Example: Principle #7 “Working software is the primary measure of progress." A scrum team who is primarily measured on estimated hours completed or even story points vs. actual working software is

not being truly agile.

7

Agile

8

Agile Methodologies • Scrum • eXtreme Programing (XP) • Scrum/XP Hybrid • Feature Driven Development • Kanban • Scrumban • Lean • DSDM (Dynamic System Development Method) • Crystal • Agile Modeling • Open Unified Process (OpenUP) • Agile Unified Process (AgileUP)

9

Popular Agile Methodologies • Scrum

• eXtreme Programing (XP)

• Kanban

Methodology Iterative Incremental Agile

Scrum Sprints produce working software at completion. Sprints are defined time boxes

Working software produced at the end of each sprint is built/added to the next sprint.

Encourages team work (cross-functional skills), co-location of team to encourage communication

eXtreme Programing

Iterations are defined and small pieces of work are completed for each iteration

Small releases are built on top of one another using simple version updates

Encourages team work (pair programming) and constant communication with on-site customers

Kanban Iterations are defined using existing workflow.

Each task or deliverable is built upon the previous iterations’ completed work

Allows team members to identify and solve road blocks collaboratively and streamline work flow processes and timeframes

10

Scrum

11

Scrum Practices Practice Works Well Doesn’t work well Why it is not critical

Daily Standups: Daily 15 min. mtg to discuss: what completed yesterday, what will be completed today, and any impediments

New team and everyone needs to get to know each other; under critical deadline; communication lines are not well established

Team has been working together well for awhile; status is updated daily in a tool or sprint board; mature enough to ask for help when needed

Three questions are good starting point. Daily may not be the best use of everyone’s time and if team is communicating regularly, updating tasks daily and asking for help consistently, not necessary to make team attend meeting

Writing all Requirements as User Stories: “As a (type of user), I want (some goal) so that (reason).”

Requirements needed are at a high level or the end users aren’t sure what they want. Non-technical people tend to understand user stories better than other formats

When writing technical requirements; or need to create detailed user interface designs

A requirement does not have to be written in user story format. This is just another tool to use to better identify/clarify what the end user wants

12

eXtreme Programing

13

XP Practices Practice Works Well Doesn’t work well Why it is not critical

Test Driven Development: Writing a test case first before any coding begins

Reduces defects, improves quality of the test, and reduces code complexity

Design quality doesn’t always improve, project/package level coupling and cohesion is more complex

Write good test cases but not necessarily critical to write them first. Keep up-to-date and run frequently

Pair Programming: Two developers (or a developer/tester) sitting at the same desk creating code

Information sharing, team building, informal code reviews that improves quality, trouble-shooting a high-pressure problem

Introverted team members struggle and are not as creative, pairs with different typing skills- better typist ends up doing most of the work with other member being mostly passive

Code reviews can improve quality just as much as pairing

14

Kanban

15

Kanban Practices Practice Works Well Doesn’t work well Why it is not critical

No predefined iterations: Iterations (sprints) do not have to be a pre-defined length

The work follows the value stream (workflow) so it is easy to implement into existing cultures

The business owner spends more time managing the Kanban board to determine priorities or sign off on completed work (note: instead of approving work every two weeks, the business owner may approve work every day or once a week, etc, whenever the work is complete)

Team will define own cadence* which may be better suited than a predefined iteration *Cadence: ability of a team to reliably deliver working software at dependable velocity

Limit Work in Progress (WIP): Establishing a total number of items that can be worked on in a certain column (workflow step)

Establishing limits forces prioritization of work

May inhibit the potential amount of work a team can complete

If Cadence has been established for a team that has been working together for some time, limits may not be as crucial

16

WHEN TO USE AGILE Project Characteristics Agile a Good Fit Use another method

Requirements Frequently changing/not well defined

Stable – not many changes

Infrastructure Requirements Minimal-Infrastructure built Infrastructure not built, multiple requirements

Total Project Hours 1,000-5,000 hrs Less than 1,000

Budget Limited/not well defined Budget is sufficient and funded

Interfacing IT Systems 3 or fewer More than 3

Architecture Design Established enterprise architecture defined

Enterprise architecture needs to be defined

Sponsor/Product Owner-available and able to make quick decisions on priorities

Yes No

Number of other Projects impacted/affected by project

None More than one

Developer skills All team members are skilled in multiple technical areas

Team members have a singular functional role/skill set

17

Agile Ice Cream Shop • Don’t force a project team

to use a single method. • Agile Methods as an Ice

Cream shop – Fruit Sundae: Traditional is

vanilla ice cream, bananas, and chocolate fudge • While good, may not be

what everyone wants. • Nothing wrong with

different type of ice cream, fruit, or topping. Still sweet and satisfying

18

Agile Menu Board Ice Cream

(Management Methods) Vanilla

(Overall Methods)

Scrum

Feature Driven Development

Kanban

Lean

Chocolate (Technical Methods)

XP

Agile Modeling

Strawberry (Communication Methods)

Crystal

Bananas (Mgmt Practices)

One Business Owner

Kanban Board

Regular Retrospective Mtg

Product Backlog

Strawberries (Technical Practices)

Test Driven Development (TDD)

Refactoring

Pair Programming

Unit Testing

Peaches (Communication Practices)

Daily Stand up

Co-location of Team

User stories accessible to stakeholders

Fruit (Practices)

Whip Cream (Mgmt Success Factors)

Limit Work in Progress (WIP)

Create action plans for improvements identified during retrospective

Update Product backlog daily

Chocolate Syrup (Technical Success Factors)

Testers are part of the Team

Pair programming is conducted for a few hours a day (not all day)

Update test cases daily

Nuts (Communication Success Factors)

Daily Stand up less than 10 min.

Co-located Business owner

User Stories are managed via electronic tool

Toppings (Success Factors)

19

Summary • Be aware that to be iterative and incremental

does not always mean you are agile.

• Using agile methodologies does not guarantee you are being agile.

• Use multiple agile methods/processes. An ice cream shop does not stay in business unless there are multiple options for customers. – No single method is a silver bullet.

– It takes skill to determine which method/processes will work for the team and continuously fine tune those processes. This is what being “Agile” is fundamentally about.

20

Summary • “ANY process or methodology (that is not

actively destructive), applied to a skilled, disciplined, high-functioning, motivated team will succeed, regardless of the process. Likewise, any process applied to a low-functioning team will likely fail.”

(source: www.slideshare.net/alimenkou/kanban-vs-scrum-2725271)

21

Resources • Internet links • http://www.netobjectives.com/myths-of-kanban#Kanban-Suggests-Linear-Work

• http://blogs.versionone.com/agile_management/2012/01/06/1-kanban-vs-scrum-myths-hype/

• http://agile.dzone.com/articles/7-agile-best-practices-you

• http://www.techrepublic.com/article/eight-reasons-why-extreme-programming-wont-work-in-your-shop/

• http://www.theserverside.com/tip/Choosing-the-best-Agile-methodology-for-your-development-needs

• http://www.devx.com/architect/Article/32761

• http://learningagileandlean.wordpress.com/2013/07/25/scrum-kanban-and-unplanned-work/

• http://www.upstarthq.com/2011/05/why-kanban-doesnt-work-for-smes/

• http://www.thefreedictionary.com/

• Additional reading material • http://www.targetprocess.com/blog/2010/10/10-most-common-mistakes-in-agile-adoption-part-i.html

• http://www.developer.com/design/infographic-agile-vs-fragile.html

• http://www.forbes.com/sites/stevedenning/2012/04/17/the-case-against-agile-ten-perennial-management-objections/

• http://swreflections.blogspot.ca/2013/07/agile-development-leads-to-alzheimers.html

• http://dreamsongs.com/ihe/IHE-28.html

ACKNOWLEDGEMENT CITATION: This research and development project was conducted by MDM Strategies, Inc. and is made possible by a contract that was awarded and administered by the U.S. Army Medical Research & Material Command (USAMRMC) and the Telemedicine & Advanced Technology Research Center (TATRC), at Fort Detrick, MD under Contract Number W81XWH12R0045 – EHR Data/Privacy Standards and Agile Development Research and Support.

Non-Endorsement Citation: The views, opinions and/or findings contained in this presentation are those of the author(s)/company and do not necessarily reflect the views of the Department of Defense and should not be construed as an official DoD/Army position, policy or decision unless so designated by other documentation. No official endorsement should be made.

22

QUESTIONS?

23