agile methodology n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Agile Methodology PowerPoint Presentation
Download Presentation
Agile Methodology

Loading in 2 Seconds...

play fullscreen
1 / 50

Agile Methodology - PowerPoint PPT Presentation


  • 319 Views
  • Uploaded on

Agile Methodology. AGILE TRAINING. Objectives. Introduction to the Agile Manifesto The Unitrin Agile “philosophies” and phases Inception Process Envisioning Process Collaborative Requirements Process QA Process Development and Deployment Processes Agile Change Management Next Steps.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Agile Methodology' - dick


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
agile methodology

Agile Methodology

AGILE TRAINING

objectives
Objectives
  • Introduction to the Agile Manifesto
  • The Unitrin Agile “philosophies” and phases
  • Inception Process
  • Envisioning Process
  • Collaborative Requirements Process
  • QA Process
  • Development and Deployment Processes
  • Agile Change Management
  • Next Steps
agile manifesto
Agile Manifesto
  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

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

unitrin agile our project phases
Unitrin Agile: Our Project Phases

6 project phases

  • Inception
  • Envisioning
  • Collaborative Requirements
  • Development
  • Quality Assurance
  • Deployment

1/3 of the phases involve planning

inception key concepts
Inception Key Concepts
  • Clarifying the project scope and objectives
  • Getting enough information to confirm that the project should proceed - or to convince you that it should not.
  • Understanding the feasibility of the intended solution, and
  • Defining the inception plan (release level)

Led by the customer

inception activities
Inception Activities
  • Verify business benefit
  • Conduct business process review
  • Understand what to deliver
  • Identify key system functionality
  • Define acceptance criteria
inception activities1
Inception Activities
  • Identify the stakeholders and resources
  • Determine the high level estimate (no buffer)
  • Identify risks associated with the project
  • Identify pre-requisites
  • Determine at least one possible solution
inception exit criteria
Inception Exit Criteria
  • Approved, prioritized work in-take item
  • All impacted teams identified
  • Project team understands the project need/purpose
  • Scope document with high level requirements
  • High level estimate (shirt size)
inception faqs
Inception FAQs

“Do I have to have an inception phase?”

“Can I have more than one inception phase?”

slide11

Envisioning Key Concepts

  • Highly speculative
    • You will only have high level information in order to plan
    • Plan should be realistic and include buffer for unknowns
  • Feature based
    • Plan is organized around what will be delivered
  • Iterative
    • Team should plan to regularly revisit, revise the plan as more is known
  • Collaborative
    • Representatives from all teams must be present and participate in the plan
  • Focused on planning
    • Does not involve digging into solutions, requirements
    • Participants must keep conversation at high/mid level
envisioning concepts
Envisioning Concepts

The most important part of the envisioning is planning

envisioning activities
Envisioning Activities
  • Assemble the teams
  • Map features to threads
  • Determine milestones for each thread
  • Refine work estimates (high level plus buffer)
  • Iterating through plan
  • Test strategy development
  • Retrospect
resources
Resources
  • Define the roles and responsibilities for team members needed
    • Agreed to during Inception; reviewed as part of envisioning
    • Don’t forget the business resources needed
    • Contributing team members (other technical team members needed)
  • Include SMEs, managers, project managers and others that will be required to support the staff
  • Determine what constitutes a team (decided at program inception)
    • Core “agile” team
      • 1 person from each discipline
      • Fully (100%) allocated to the work that the team is doing
    • Support staff
      • May not be allocated at 100%
  • Number of teams is determined by the number of available resources that make up the team
    • Requisitions for additional staff are identified
what do mean by thread
What do mean by “thread?”

Work breakdown structure

    • Program x
    • Project x.x
    • Release x.x.x
    • Thread x.x.x.x
    • Milestone x.x.x.x.x
    • Task Unit x.x.x.x.x.x
  • A thread is a system enhancement delivered by a single team
wbs example
WBS Example

Exceed (program)

      Personal Auto (project)

              IL Auto (release)

                    Out of Sequence (thread)

                           Skeletal PERS Record (milestone)

                                  Unit testing (task)

definition of thread
Definition of Thread

A thread includes:

a. Envisioning plus any preparation the teams may require in order to get up to speed on the project (including administrative work and development of the test strategy)

b. Milestones that will implement the thread (this may be synonymous with features)

c. Thread testing (testing for all milestones in the thread)

Essentially a thread includes all activities from planning through integration testing

envisioning case study examples of reasons to buffer
Envisioning Case Study: Examples of Reasons to Buffer
  • All differences in process haven’t been driven out and addressed during the scoping process
  • Waiting for decisions
  • Over-engineering of configurable areas of Claim Center – activities, assignments, notes
    • Complicates upgrades increasing expense, decreasing our ability to quickly move to new releases
    • Changes don’t prove of value and must be backed out at some point
  • Cross-thread/team impacts discovered during development
  • Lack of consistency in user interface requiring re-work
  • IT projects > 12 Mos. are at significant risk for delivery delay
  • The unexpected: loss of staff, CATs, other disasters
  • Assumptions
milestone planning
Milestone Planning
  • For each scope, group works together to come up with the milestones that will implement the thread
  • Each high level feature in each scope discussed in detail:
    • Facilitator is knowledgeable on each feature discussed
    • Does not include discussion of how it will be implemented, the solution, or detailed requirements
  • Each milestone gets its own estimate
    • Duration (weeks)
    • Role(s) required to fulfill the milestone
    • MoSCoW discussion
what is a milestone
What is a “milestone?”
  • May be a feature if individually “implementable”
  • Should be no larger than 4 wks in duration
    • Can be up to 6 wks in duration but need to determine why
  • Defined by the person/team who will work the milestone
what does a milestone include
What does a milestone include?
  • Collaborative analysis for only that milestone
  • Requirement(s) sign off
  • Development
  • Test case development
  • QA sign off
  • Test execution (this may only at the system test level in Dev)
  • Defect management
right sizing a milestone
Right-Sizing a Milestone
  • This is where the paradigm shifts
  • Each milestone should result in an implementable feature that is done done
    • From planning through system testing
  • Milestones are not:
    • Tasks
    • Waterfall phases (e.g. Requirements, Coding, Testing)
    • Divided into horizontal layers (idea is to address a “vertical” slice of functionality
right sizing a milestone1
Right Sizing a Milestone

Iterative ways to split out a milestone:

  • “Planned rework”
    • Start simple and build in complexity with subsequent milestones
  • Separate the functional and non-functional
    • E.g. Build controls before making them reusable
  • Remove cross-cutting concerns
    • E.g. Build user interface and then roll in performance optimization
  • Split based on mixed priority
    • Address higher priority needs first
      • Business value
      • Infrastructure
right sizing a milestone2
Right Sizing a Milestone

Incremental ways to split out a milestone:

  • Split across data boundaries
    • Like data implemented together
    • Policy data then billing data, etc
  • Operational boundaries
    • C.R.U.D
task tracking
Task Tracking
  • Tasks, lowest level of WBS, are tracked by the team
  • Defined by the person/team performing the task
  • Based on experience
  • Visible
  • Updated regularly (we know a little more about the project each day)
envisioning exit criteria
Envisioning Exit Criteria
  • Milestone plan for the upcoming project
    • Features to be delivered per cycle
    • Target release date
  • Task list per team
  • Project team list (with R&R)
  • Refined estimate
  • Test strategy
    • Including acceptance criteria
    • Linked into QC Test Plan folder
envisioning faqs
Envisioning FAQs

“Do I include planning in my plan?”

“Is a project plan required?”

“What if a team can’t participate in the planning?”

“The approved project impacts non-USG teams. Can I start working on it anyway?”

“Do teams have to participate (in planning) if they are only testing?”

“How frequently do I need to update my plan?”

“Who uses my plan?

“Do I have to envision if my team is doing all the work?”

collaborative requirement key concepts
Collaborative Requirement Key Concepts
  • The right people involved
  • Everyone is prepared
  • Project doesn’t move forward till all issues are closed
  • Deep dive
  • Follow good meeting practices
  • Just-in-time analysis
  • Just enough documentation
collaborative requirement activities
Collaborative Requirement Activities
  • Perform requirements analysis/modeling for the milestone(s)
  • Verify/validate requirements
  • Add requirements to QC/Caliber
  • Create the test plan
collaborative requirements exit criteria
Collaborative Requirements Exit Criteria
  • All issues closed before start of construction on a milestone/feature
  • Requirement artifact(s) loaded into QC/Caliber
  • Draft test plan for the milestone/feature
  • Detailed estimate
  • Validated acceptance criteria
collaborative requirements faqs
Collaborative Requirements FAQs

“Do you have a requirements template?”

“Who should I invite to my collaborative requirements session(s)?”

“Do I need to hold requirement meetings if only one team is involved in my project?”

“How many attendees is too many in a collaborative meeting?”

requirements change control
Requirements Change Control
  • Encourage coordinated change
  • Added a simple change control process to CR
  • Change Control Log
    • Evaluate impact of change
    • Approvals
    • Add to requirements
development exit criteria
Development Exit Criteria

(Exit criteria for analysts)

  • Test cases documented in QC
  • Test cases linked to requirements in QC
  • Test case steps reviewed by customer
  • Performance guidelines (if applicable)
  • Performance test scripts written and ready to execute (if applicable)
  • Code has been unit tested and reviewed by analyst on local machine
  • Code is ready to be tested (per developer)
quality assurance key concepts
Quality Assurance Key Concepts
  • Defect prevention (rather just detection)
  • Test early (including the developer’s local machine)
  • Test often
  • No test performed for the first time in upper environments
  • Test artifacts created and stored in QC
  • Test cases linked to requirements, defects
  • Use test automation
  • Daily testing stand ups
quality assurance activities
Quality Assurance Activities
  • Test case development (occurs during Development)
  • Test execution in Dev, SysTest, INT and UAT environments
  • Defect management in all environments
  • Daily testing stand ups
qa exit criteria to systest
QA Exit Criteria: to SysTest
  • Defects retested and passed in Dev
  • Code approvals to move to System Test environment
qa exit criteria into integration
QA Exit Criteria: into Integration
  • Meet performance metrics in Dev or System Test (if applicable)
  • Testing in the development environments is complete
  • All Sev 1, 2, 3 defects resolved
  • Attend daily quality stand up to give project status
    • Pre-release – into INT
  • QA sign off on code
    • Info in Harvest/Endevor notes (QA Name, Heat/WR#/Change Log, Change Request Form (CRF) #)
qa exit criteria into uat
QA Exit Criteria: into UAT
  • Meet performance metrics in INT (if applicable)
  • Testing in INT is complete
  • All Sev 1, 2, 3 defects resolved (if found)
    • Demoted if not resolved within 24 hrs
  • Attend daily quality stand up to give project status
    • Pre-release – into UAT
  • Customer sign off on code promotion
  • Meet the environment date
qa exit criteria into prod
QA Exit Criteria: into Prod
  • Meet performance metrics in UAT (if applicable)
  • Minimum 24 hr stay in UAT
  • Spot check testing UAT only
  • All Sev 1, 2, 3 defects resolved immediately (if found)
    • Demoted if not resolved within 24 hrs
  • Attend daily quality stand up to give project status
    • Production-release – into UAT
  • Customer sign off on code promotion
  • Appropriate CRF/Change Mgmt documentation
agile discussion board
Agile Discussion Board
  • Implemented the Agile Discussion Board as a mechanism for people to provide feedback, make suggestions, ask process questions, etc.
next steps
Next Steps
  • Agile requires a paradigm shift
    • Replacing “waterfall” thinking with “agile” thinking
  • Deep dives into analytical processes: Envisioning and Collaborative Requirements?
  • What analyst tools are needed for the agile teams?
  • Invite me/Rick/Sharon to observe your sessions
  • Virtual coaching