iterative methodologies - osehra · •a single iteration results in one or more bite-sized ......
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
• 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 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 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
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 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