1. Lessons Learned Best Practices
Iterative Development
Lisa A. Grant, MBA, PMP, AC-Bronze, CL
May 19, 2007
Lessons Learned Best Practices
Jim Young, MS/IT, PMP
Lisa A. Grant, MBA, PMP
Daniel Vitek, MBA, PMP

2. Agenda Introduction to Agile Methodology
Application of Agile Methodology
Integration with the Enterprise Performance Life Cycle
Questions & Answers 2 2

3. Introduction to Agile Methodology
Jim Young, MS/IT, PMP

4. Agile Development Characteristics of Agile Development:
Minimize risk by developing software in multiple shorter iterations.
Each iteration passes through a full software development cycle.
At the end of each iteration, stakeholders re-evaluate project priorities to optimize return on investment.
Agile methods emphasize face-to-face communication over written documents.
Collocation is encouraged to facilitate communication.
Wikipedia - 4 4

5. Scrum is not an Acronym
Scrum is borrowed from rugby. It is a way of restarting the game. Opposing teams interlock and compete to gain control of the ball that is tossed into the middle of group.

6. What is Scrum?
Scrum is an iterative, incremental process for developing any product or managing any work. It produces a potentially shippable set of functionality at the end of every iteration. It's attributes are:
Scrum is an agile process to manage and control development work.
Scrum is a wrapper for existing engineering practices.
Scrum is a team-based approach to iteratively, incrementally develop systems and products when requirements are rapidly changing
Scrum is a process that controls the chaos of conflicting interests and needs.
Scrum is a way to improve communications and maximize co-operation.
Scrum is a way to detect and cause the removal of anything that gets in the way of developing and delivering products.
Scrum is a way to maximize productivity.
Scrum is scalable from single projects to entire organizations. Scrum has controlled and organized development and implementation for multiple interrelated products and projects with over a thousand developers and implementers.
Scrum is a way for everyone to feel good about their job, their contributions, and that they have done the very best they possibly could.
                                                                                                                                                                                                                                                                                                                                            6 6

7. Scrum Process
Scrum focuses an entire organization on building successful products. Scrum can be implemented at the beginning of a project, in the middle, or to rescue a troubled development. Without major changes, often within thirty days, teams are building useful, demonstrable product functionality. 7 7

8. Work Burn-Down Management is Concerned About:
Sprint progress – how is the team progressing towards meeting their Sprint goal?
Release progress – will the release be on time with the quality and functionality desired?
Product Progress – how is the product filling out compared to what is needed? 8 8

9. Observation Scrum provides direct visibility into the project
Management can attend and observe the daily Scrum meetings. During these meetings they can observe team spirit, each member's participation, team member interaction, work that is being completed, and impediments to progress 9 9

10. Active Management
Management is actively involved with Scrum on a daily basis. During daily Scrum status meeting, management listens closely to team member reports and compares this to their expectations. For example, if someone has been working on a trivial task for three days, it is likely that that team member needs help. Management assesses team velocity: Is the team stuck, are they floundering, are they making progress? Management can step in and resolve issues if help is needed. 10 10

11. Scrum Resources The Scrum Primer http://www.scrumprimer.com/
Agile Software Development with Scrum
Agile Project Management with Scrum
Enterprise Scrum 11 11

12. Application of Agile Methodology
Lisa A. Grant, MBA, PMP

13. Scrum on Research Activities
Problem:
New project utilizing Natural Language Processing (NLP) and a development team with no NLP experience
Solution:
Allocate resources to new project 100%
Collocate resources
Utilize Scrum
By definition projects are unique, however, they have similarities, i.e. S/W development follows SDLC, construction projects
Example: C & A process that takes 80 days, Learned the hard way on first project apply it to next projects.
Inexperienced testers on a claims project for cost cutting reasons 13 13

14. DKMS Collaboration Availability of a collaboration room
Decided Agile best suits our projects
Decided to try Scrum
By definition projects are unique, however, they have similarities, i.e. S/W development follows SDLC, construction projects
Example: C & A process that takes 80 days, Learned the hard way on first project apply it to next projects.
Inexperienced testers on a claims project for cost cutting reasons 14 14

15. DKMS Scrum Team of 5-7 Team is collocated in collaboration room
Sprints are 2 weeks
Low tech project tracking and reporting
By definition projects are unique, however, they have similarities, i.e. S/W development follows SDLC, construction projects
Example: C & A process that takes 80 days, Learned the hard way on first project apply it to next projects.
Inexperienced testers on a claims project for cost cutting reasons 15 15

16. Why did it Work? Sprints time-boxed activities i.e. research
Planning with outcomes in mind
Each activity had a deliverable
Presentation of deliverable at sprint end
Quick input from Stakeholders
Team could easily talk and solve problems
By definition projects are unique, however, they have similarities, i.e. S/W development follows SDLC, construction projects
Example: C & A process that takes 80 days, Learned the hard way on first project apply it to next projects.
Inexperienced testers on a claims project for cost cutting reasons 16 16

17. Sprint
By definition projects are unique, however, they have similarities, i.e. S/W development follows SDLC, construction projects
Example: C & A process that takes 80 days, Learned the hard way on first project apply it to next projects.
Inexperienced testers on a claims project for cost cutting reasons 17 17

18. Integration with the Enterprise Performance Life Cycle
Daniel Vitek, MBA, PMP

19. Iterative Cycles (Sprints)
Agile methodologies are thought of as being about small, collocated teams. Some agile methodologies have special practices that set them apart from others--for example, extreme programming uses pair programming and test-driven development. However, at the highest of levels, approaches are very similar.
Agile methodologies share emphasis on continuous (re)design. Continuous design is the idea that design and building are intertwined and that changes to a design should be made as more is learned about the true requirements for the software. This the thinking behind the mantra, "release early, release often."
Continuous design is an approach that is predicated on recognizing that it is rarely possible to design perfectly upfront.
The reasons for this approach, as stated by the original team, are as follows:
To shorten the software engineering life cycle of design/implement/test to a granularity of 1 day.
To make software that always works.
To find and fix defects in hours not weeks by bringing quality assurance inside the development cycle and by breaking the cycle of letting users find bugs.
To automate everything.
To make all developers responsible for testing (developers are expected to fix their bugs immediately).
Among the values expressed by the original development team are the following:
Test early and often; this is critical to high-quality software.
Retain measurements to assess progress and measure productivity.
Present results in concise informative ways.
Know and show the status of the system at any time. 19 19

20. EPLC Framework EPLC Phases & Deliverables Initiation Phase
Business Needs Statement
Concept Phase
Business Case
Project Charter
Preliminary Project Management Plan
Planning Phase
Final Project Management Plan
Project Process Agreement
EPLC Planning Phase
Through planning work is very similar across methodologies, regardless of development approach.
Even utilizing an iterative development approach, early planning is rarely revisited without material project changes to areas such as budget, schedule, scope, or acquisition. Thresholds for what constitutes “material change” are defined by each Center’s Governance and in some instances may be unique to the specific project.
Planning also includes Identification of appropriate delivery approach(es). 20 20

21. Project Process Agreement
Requirements & Design Phases are the primary difference between iterative and non-iterative approaches.
Through the use of a Project Process Agreement document, the EPLC can be tailored to accommodate a variety of projects and approaches, including those utilizing Agile development.
How requirements, design, and their associated governance reviews are performed identifies the primary difference between an iterative and non- iterative development approach. To a lesser extent planning, testing, and implementation are also impacted.
Through the use of a Project Process Agreement document, the EPLC can be tailored to accommodate a variety of projects and approaches, including those utilizing iterative development. Upon Governance approval of the Project Process Agreement and finalized Project Management Plan the project formally advances into the EPLC Requirements Analysis Phase EPLC Definition = The Project Process Agreement is used to authorize and document the justification for using, not using, or combining specific Stage Gate Reviews and the selection of specific deliverables applicable to the investment/project, including the expected level of detail to be provided. 21 21

22. Requirements Phase Identify initial requirements.
Decompose to feature/function level.
Triage delivery based on priority.
Consider initial testing/implementation strategy.
Perform EPLC Requirements Review.
Responsibility delegated by Center’s Governance to the project business owner.
Identify initial requirements
Decompose requirements to feature/function level
Triage delivery based on priority
As each new iteration nears, features and functions identified for delivery in a particular iteration are decomposed to a level of detail that can be estimated, scheduled, designed, built, and tested within the confines of one iterative cycle. Responsibility for the EPLC Requirements Review is delegated by the Center’s Governance to the identified business owner 22 22

23. Design Phase Define initial design
Operating system platform, development language, system architecture, database schema, etc.
Perform initial EPLC Design Review.
Perform iterative Design Reviews.
The most appropriate approach is defined by each Center’s Governance. 23 23

24. Test/Implementation Phase
Test reviews are delegated by Center’s Governance to the project manager.
During the first development iteration that contains a formal product implementation an Operational Readiness Review must be performed by the Center’s Governance.
At this time, how future reviews will be performed is also defined.
During the first development iteration that contains a formal product implementation an Operational Readiness Review must be performed by the Center’s Governance. At this time, how future Operational Readiness Reviews will be performed is also defined 24 24

25. Iterative Review Options
Iteration reviewed at the beginning of each new iterative cycle.
Outlines all iterations then review iterations at the beginning of each new release cycle.
Project review at specific duration increments.
Project review at specific project completion thresholds (% complete).
Project review at specific variance thresholds (+/-10% from baseline or budget).
Governance’s Preliminary Design Reviews conduct a full iteration reviewed at the beginning of each new iterative cycle with the management oversight of that cycle delegated to the Project Manager.
Governance’s Preliminary Design Reviews conduct a full product release cycle review that outlines the multiple iterations contained within the product release. Iterations are then reviewed at the beginning of each new release cycle with the management and oversight of all iterations contained within that approved release cycle delegated to the Project Manager.
Governance’s Preliminary Design Reviews conduct a full project review at specific increments of defined durations with the management and oversight of all iterations contained within that duration delegated to the Project Manager.
Governance’s Preliminary Design Reviews conduct a full project review at specific thresholds of project completion (% complete) with the management and oversight of all iterations contained within that threshold delegated to the Project Manager.
Governance’s Preliminary Design Reviews conduct a full project review at specific thresholds of project variance (+/-10% from baseline or budget) with the management and oversight of all iterations contained within that threshold delegated to the Project Manager. 25 25

26. Questions & Answers