Agile Overview

Agile Overview
Radha Sharma ISL Quality Team Oct 2011
Copyright IBM Corporation 2009
Agenda Content
Agile Characteristics Agile Vs Waterfall Agile Methodologies Overview Scrum Deep Dive Sharing of experiences by a project team Product Backlog User Stories, Use Cases Prioritising Product Backlog Pair programming Test Driven Development Continuous Integration Agile Reflections
2 Generation Open | IBM Global Business Services Copyright IBM Corporation 2009
Characteristics of Agile Projects
Generation Open | IBM Global Business Services Copyright IBM Corporation 2009
Characteristics of Agile Projects
What Agile is NOT!
Why was/is waterfall so popular
1
Its simple to explain and recall.
Do the requirements, then design, and then implement. IID is more complex to understand and describe. Even Winston Royces original two iteration waterfall immediately devolved into a single sequential step as other adopters used it and writers described it.
2
It gives the illusion of an orderly process.
It gives the illusion of an orderly, accountable, and measurable process, with simple document- driven milestones (such as requirements complete).
3
It was promoted heavily.
It was promoted in many software engineering, requirements engineering, and management texts, courses, and consulting organizations. It was labeled appropriate or ideal, seemingly unaware of this history or of the statistically significant research evidence in favor of IID
Note: IID = Iterative and Incremental Development

Agile Defined (Industry)

Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: 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.
2001 www.agilemanifesto.org
The IBM Agile Manifesto
Agile development must

Address complex architectural requirements. Provide effective governance. Strengthen Be solution disciplined. quality and consumability. Be effective for all types of development: for SOA products, components, solutions and suite releases. Provide integration processes for small and large teams across multiple sites and time zones.
Where these statements are not yet true, we will work together to make them a reality.
Agile Defined (IBM)
Uses continuous stakeholder feedback to deliver high-quality, consumable code through user stories and a series of short, timeboxed iterations.
Principals
End Users
Partners
Insiders
Agile Defined (IBM)

Uses continuous stakeholder feedback to deliver high-quality, consumable code through user stories and a series of short, timeboxed iterations.
Key concept Agile development necessitates greater discipline than traditional methods. Quality must be real. CUPRIMDSO: How consumable are your applications?
Capability Usability Performance Reliability Install-ability Maintain-ability Documentation Service Support Overall Satisfaction Necessary functions work properly Ease of use Response time and speed are good Low frequency and severity of errors Ease of Installation and migration Ease of upgrading or applying fixes Accurate, complete and easy to find Provided within expected SLAs All aspects of the clients experience
10
Waterfall and Agile-Core processes

Waterfall Process
Concept
Understand what is to be built and who to build it for
Plan
Understand and confirm how to build it
Develop
Build it
Qualify
Test it
ROLLOUT
Deploy it!
Agile-Core Process
Concept
Understand what is to be built and who to build it for
Plan
Understand and confirm how to build it
Iteration 1, 2, 3
Build it and test It n Develop & qualify phases
ROLLOUT
Deploy it!
11
Waterfall Project Profile

Description Business Value
Design completed prior to Plan DCP. Single execution of 5 distinct phases (Concept, Plan, Develop, Qualify, Rollout). Scope changes and requirements reprioritization are possible with Change Management. Supportive of many dependencies Proven ability to deliver fixed scope on time and within budget. Less failed projects within the industry.
Project Characteristics
Project whose business case has stringent revenue targets that need to be achieved in a short period of time. Project that has legal, accounting or environmental requirements (e.g. Daylight Savings time) with a specific deployment date. Large, complex, integrated portfolio of projects Well understood Architecture Business needs known up front Fixed Scope, Cost and Delivery Date Well understood business process and requirements Small or Large Teams Collocated or Dispersed
Waterfall Process
Concept
Design & Requirements signed off (100%)
Right Project
Plan
Develop
Right Client Right Team

12
Qualify
Rollout
Agile-Core Project Profile

Description Business Value
Agile-Core will use iterations during Develop/Qualify phases. Like Waterfall, Design completed prior to Plan DCP. Rollout will occur after the final iteration is complete. Scope changes and requirements reprioritization are possible with Change Management. An aspect of this offering is that it supports changes that are less likely to impact the underlying architecture. This offering will provide the client with a way to flush out unknown requirements and allow the end user to view functionality periodically throughout the development cycle. It allows stakeholders to identify changes sooner and minimizes the cost impact of those changes.
Project Characteristics
Requirements / Design must be committed at a Plan DCP May involve user interface or sun set of legacy systems Projects with data mart, complex reporting or user dashboard Project with legal, accounting or environmental requirements (e.g. Daylight Savings time) with a specific deployment date. Highly engaged Client/SMEs Collocated or very strong virtual teaming Small or Medium teams are preferred. Large teams should be broken into focus groups with stringent project management disciplines Collocated or very strong virtual teaming
Iteration
Develop
Right Project
Iteration
Right Client Right Team
Qualify
13
Key Characteristics of Successful Agile Projects at IBM
Stable code in Time-Boxed, Short Iterations
Stakeholder Feedback
Self-Directed Team
Sustainable Pace
14
Agile Framework Agile Framework

Agile is a conceptual framework for undertaking software engineering projects
Extreme Programming (XP)
Based on values of simplicity, communication, feedback, courage, and respect Start with simple solution, add complexity through refactoring
SCRUM
Unified Process Simplified version of Rational Unified Process reduced
Crystal
Adaptive
Dynamic Systems Development Method (DSDM): 3 primary phases: PreProject, Project Life-Cycle , Post-Project
Feature Driven Dev. Develop feature list Plan, Design, Build by Feature
Small teams of 68 people Backlog defined requirements that will be addressed in each Sprint Daily 15 min.Scrum meeting to discuss work for the day
Frequent delivery Reflective improvement
Repeating Speculate, Collaborate, Learn cycles Provides for continuous learning and adaptation to changing project state
Agile Techniques: The above methods involve a range of techniques including:

Test-driven development Planning game Pair Programming Refactoring
15
Continuous integration Design improvement Small releases Simple design
Static Analysis Coding standard Sustainable pace Whole team
Questions?
16
Scrum Deep Dive
Credits
Mountain Goat Software, LLC
18
Scrum
Image owned by Teivovo, Fiji Rugby, 2007
19
Scrum Development Process
4 Key Roles
3 Key Meetings
5 Key Artifacts
1 Development Process
20
Roles
Responsible for the value delivered by the release Develops and maintains the product backlog Prioritizes the Product Backlog Empowered to make decisions for all customers and users Shields team from external influences Presents and explains Product Backlog to the Team Communicates project progress to Stakeholders Drives User Experience and User Design Accepts and Rejects work results Responsible for maximizing team productivity Sets up and facilitates various Iteration meetings Shield team from external influences Removes barriers Responsible for estimating and committing to work Is self organized and cross-functional Has full autonomy and authority during a Sprint Collaborates with Product Owner Demos to Products Owner
Product Owner
Scrum Master
Scrum Team
Stakeholders
Observes and advises Has material interest in the work of the Scrum Team Provides input via the Product Owner
21
Key Artifacts
Product Backlog
List of requirements & issues Owned by Product Owner Anybody can add to it Only Product Owner prioritizes
Iteration Goal
One-sentence summary Declared by Product Owner Accepted by team
Iteration Backlog
List of tasks Owned by team Only team modifies it
Blocks List
List of blocks & unmade decisions Owned by ScrumMaster Updated daily
Increment
Version of the product Shippable functionality (tested, documented, etc.)
22
Key meetings
Iteration Planning Meeting
Hosted by ScrumMaster Attended by all Input: Product backlog, existing product, business and technology conditions 1. Select highest priority items in Backlog; declare the iteration goals 2. Team turns selected items into Iteration Backlog Output: Iteration Goal, Iteration Backlog
Daily Scrum Meeting

Hosted by ScrumMaster Attended by Team Same place/ time every day, 15 minutes max Answer 1. What did you do yesterday? 2. What will you do today? 3. Whats In your way? 4. Did you update your hours remaining in RTC? Team updates Iteration Backlog Scrum Master updates Blocks List
Iteration Review Meeting

Hosted by ScrumMaster Attended by all Informal, 4 hour, informational Team demos increment All Discuss Consider Reuse Harvest Candidates Hold reflection Announce next Planning Meeting
Reflection
Every iteration ask What should we: STOP ? START ? CONTINUE ? Then every 2 months do DEF
NOT status for the ScrumMaster BUT commitments in front of peers

23
Scrum Development Process
Blocks Daily Scrum List Meeting Iteration Review Meeting 24 hours
Iteration Planning meeting
Product Backlog
Iteration Goal
Iteration 2-4 weeks
Potentially shippable Product Increment
Iteration Backlog
New or Changed Story
Done, done, done, done!
25
Our IBM-flavored Definition of Done

At the end of each iteration:
DONE
DONE
No Sev 3s or Sev 4s the team including client has not agreed to
DONE
Code, and configuration are unit tested, function tested, system integration tested, performance tested, tested end-to-end, environment test and appropriate user tested. User documentation complete.
DONE
A meaningful stakeholder and user review has been conducted
No Sev 1s or Sev 2s
Can this really be done? This puts a high premium on:

Valuable, maintained, nested automation Appropriate code coverage (e.g. 80%) Unit Test Avoiding technical debt Continuous integration Really understanding what quality code looks like
26
Scaling Scrum
Scrum of Scrums
Mountain Goat Software, LLC 28 Generation Open | IBM Global Business Services Copyright IBM Corporation 2009
Scrum of Scrums of Scrums
Scaling the product owner
Running the scrum of scrums
Attendees
Each team sends an individual contributor If four or fewer teams, its OK to send a ScrumMaster also Rotate based on whose skills are needed most Some say daily I usually do these MWF or TuTh These are problem-solving meetings Not time-boxed to 15 minutes Everyone answers four questions
Frequency
Agenda
Attendees discuss the product backlog for the scrum of scrums
31
Questions?
32
Product Backlog and User Stories
Product Backlog Product Backlog

The Product Backlog holds all the user stories until they are ready to be implemented in a iteration
User Story
34
User Stories: Components

A User Story describes functionality that will be useful to a stakeholder of the system.
User Stories are comprised of three things
1
A brief description of the story used for planning
2
Conversations about the story
3
Tests that convey and document details
4
Assumptions
5
Estimating Elements IBM Account Adds two additional things
35
User Story the 3 Cs
Card
Stories are traditionally written on note cards May be annotated with notes, estimates, etc.
Conversation
Details behind the story come out during conversations with product owner
Confirmation
Acceptance tests confirm the story was coded correctly
36
Source: XP Magazine 8/30/09, Ron Jeffries Mountain Goat Software, LLC Generation Open | IBM Global Business Services Copyright IBM Corporation 2009
User Stories: Card: A brief description
A User Story takes the form of: As a <Role>, I want to <Goal> so I can <Business value>. Examples
As a DBA at Wal*Mart, I want to be able to reduce storage consumption so that I manage fewer storage devices.
Note: DBA at Wal*Mart is administering DB2
DBA at Wal*Mart
Sales Representative
As a sales representative in Australia I want to know the release date of the sales order (processing is over) so that I can know when the item is available to ship.
37
User Stories: Conversation
Warning
Significant value happens here
Include many people
Include as many people as you can. Make sure that all disciplines are represented.
38
User Stories: Confirmation: Acceptance Tests
The product owners conditions of satisfaction must be added to a story.
Easy, binary Done or not
Testable so that you have an easy, binary way of knowing whether a story is finished
Done or not done; no partially finished or done except
As a sales group person in Australia I want to know the release date of the sales order (processing is over) so that I can know when the item is available to ship
The correct release date is on the product analyst report Must respond within 10 secs Release date is within 30 days of order created Release date can be viewed in the second column
39
User Stories: Assumptions and Estimating Elements
Assumptions and Estimating Elements augment the User Story.
Assumptions Estimating Elements
Document any assumptions for the User Story.
Determine appropriate estimating elements for the User Story to help establish size and complexity.
Estimating Elements from ESDW project
Estimating Elements from eHR WSF project
Numberaof ETLsWal*Mart, I want As DBA at to be created Number of tables to be storage to be able to reduce created Number of Jobs to be created consumption so that I manage fewer Jobs to be modified Number ofstorage devices. Number of Unix scripts to be modified Number of source columns to add
40
Number of tables required Number of service API definitions Number of service resource classes Number of message formats required Number of new security roles Number of supporting web pages
User Stories: Additional Estimation Element ideas

How many configuration elements or items are needed
-
document type item category type (related configuration elements required along with item category type can be classified as additional estimation elements), number range categories
Data migration conversion

-
Approx number of business objects / tables
# of user education packages needing updates # of interfaces # of security roles / profiles # of Workflow objects # of portal screens # of SAP screens # of BASIS / infrastructureIBM Global Business Services Copyright IBM Corporation 2009 Generation Open | elements
User Stories vs Use Cases
Brief Description
Actor
Alternate Path Ideas
As a <role> I want to <goal>, so that I can <business value>
Acceptance Test 1 Acceptance Test 2
Successful Solution
Pre and post conditions
Key:
User Story
User Cases
Problem Statement
42
Use cases example

Use Case Name : Purchase Book Description : The use case addresses the situation where a customer purchases a book. Basic Flow : Customer navigates to the bookstore website Customer searches for the desired book Customer adds the book to shopping cart Customer checks out Alternative Flow : A1. Book is out of stock A2. Book seller doesn't sell the book A3. Credit card is declined.
Summary of User Stories
Product Backlog Consist of the 3 Cs Written using the template Good user stories have the following qualities Broken down into tasks
User stories make up the product backlog Card, Conversation, Confirmation, plus estimation elements and assumptions As a <Role>, I want to <Goal> so I can <Business value>. Independent, Negotiable, Valuable, Estimatable, Sized appropriately, Testable User Stories are broken down into tasks that form the iteration backlog during iteration planning
44
Prioritizing the Product Backlog
Product backlog
Product backlog is...

All user stories for the project that are waiting to be implemented Defects not fixed in previous iteration Hint: Try writing user stories for them Non-functional requirements that span many user stories e.g. performance
46
Learn how to prioritize - MoSCoW
Must have: Highest priority
Should have: Desirable to have
Could have: Nice to have
Wont have: Out of scope for this release
47
Summary
Product owner owns product backlog

Product backlog is the list of all work for the project It is owned and prioritized by the product owner
Numerical prioritization
Prioritization takes the form of MoSCoW followed by numerical prioritization
Competing stakeholders
Competing stakeholders can be worked using the prioritization grid
48
Pair Programming
Pair programming basics
Simple concept: two programmers work together at one computer on the same task Driver
Type code, write design
Navigator
Look for defects Think ahead - strategize Brainstorm at any level e.g. design, debug
Together
Has been applied successfully to Analysis, design, code, debugging, test

Pair Programming Myths

Myth
It will double the workload with two doing the work that one can do
Reality
Productivity is about equal, elapsed time is halved, quality is improved Study - 22% of extreme programmers spend > 75% of a day in pair programming. Email etc. will always result in part of the day being spent alone Studies show it works well with most pairs 83% of surveyed projects simply rotate pairs changing pairs after several hours or several weeks
Ill never get to work alone - I couldnt stand that
This will only work well with the right partner Pair programming is good for training, but once you know what youre doing it is a waste Ill never get credit for anything Ill have to share credit with a partner
Training is only one of many benefits
Tasks should still have one owner, but on Agile projects, team credit is preferred
51
Eight synergistic behaviours
Pair Pressure
So as not to let their partner down programmers work smarter and harder in pairs Less likely to violate standards/processes
Pair Negotiation
Each brings different skills, outlook, approach Software decisions are mostly intellectual and have a demonstrably correct answer. Groups typically recognize and select correct intellectual answers.
52
Eight synergistic behaviors
Pair Courage
Affirmation from your partner avoids time wasted on dithering - if it looks right to me and looks right to you, then its probably right.
Pair Reviews
Immediate feedback - The earlier a defect is found, the easier/cheaper it is to fix (minimal technical debt)
Pair Debugging
Immediate feedback - the earlier a defect is found, the easier/cheaper it is to fix (minimal technical debt) Another person will ask questions, present challenges you hadnt anticipated
53
Eight synergistic behaviors
Pair Learning
One on one opportunity to teach each other concepts/details on programming language, techniques (e.g. Test Driven Development), standards, patterns, tools etc. Pair Learning happens continually
Pair Trust
A natural outcome of working closely together now Leads to improved communications and teaming later
Fun
Pairs have more fun!
54
Whats in this for Management

Higher quality
Projects on time with higher quality and fewer defects
Knowledge Transfer
Multiple people become familiar with each part of the system New people to project can contribute earlier Turnover is costly Seven studies 90% of pair programmers agreed they enjoyed their jobs more when pair programming
Happy employees
Elapsed time
Work is accomplished with higher quality in about 1/2 the elapsed time
Teams work together
Teams work together and communicate more effectively. Trust, rapport, common ground enhanced through pair programming
55
How do pairs arise
Rotation
Pairs learn more when rotated dysfunctional teams are less of a problem Problems/questions may arise where someone else at the meeting has ideas on resolution pairing may be a good approach to solve the problem Set a rule . When a task owner asks for help, the team member has to say yes
Daily meetings (standup/Scrum)
Just say yes
Training
For new team members, or to broaden skills in specific areas
56
Tips
Give the driver a moment Give the driver a second to correct mistakes, find menu choices etc. It can be annoying to be continually corrected
Swap positions
If youre getting bored or tired, swap positions grab the keyboard if youre navigator
Ground rules first
For peace and harmony, talk ground rules first . Start the session talking about likes and dislikes when pairing. Navigator can maintain a side list of issues Separate for a specified period e.g. 10 minutes Let navigator drive for a specified time to demo alternate approach Path for escalating issues Be assertive without being aggressive learn balance
When there are conflicts
Apply standards
Apply standards avoids style issues
57
More tips
Use TDD Write test cases first to provide more focus
Practice active listening
Restate and summarize ideas and discussion points
Talk a lot
Help your partner understand your logic
Not listening?
If your partner is not listening get up and walk away
Remote pairing
Remote pairing netmeeting/conference call
When co-located
When co-located, take a shower & use breath mints!
58
Test Driven Development
TDD: How often?
TDD: Benefits
Increased code quality The tests document the system Confident refactoring Removes paranoia Early defect detection & No Debugging More modularized, flexible, and extensible code
Continuous Integration
Continuous Integration: Workflow
Benefits
Reduced Risks Repetitive Processes Deployable Software Accountability
Iteration Demo and Review - Agile Reflections
The Iteration Review Meeting

The Product Owner
Must attend the meeting Is the customer who provides feedback Accepts the user story as done, done, done, done or rejects the story and puts it back on the backlog
The Scrum Master

Facilitates the meeting Questions the completed stories and makes sure that potential open problems are negotiated
The Scrum Team
Key points of how they work together

If problems arise or requirements turn out to have been unclear, the Scrum Master must ensure that the Product Owner understands the teams difficulties on the one hand and the team understands the Product Owners most important requirements on the other to be able to negotiate tradeoffs.
Proudly presents what has been achieved in the iteration
67
Iteration Review Meeting Agenda

Present Completed User Stories
Demo working software completed in prior Iteration
Record Feedback
Record feedback from stakeholders
Adjust Product Backlog

Remove completed functionality Reprioritize unfinished functionality Adjust priorities based on feedback
Adjust Project Structure

Reformulate or resize the team Refine the release schedule
68
Demo Checklist
Iteration goal Demonstrate working software Keep a high pace Business-oriented demos What did we do Dont demo minor fixes and features
Clearly present the iteration goal Dont spend too much time preparing for the demo focus on demonstrating working software Keep a high pace fast rather than beautiful Keep demo on a business-oriented level leave out technical details Focus on what did we do rather than how did we do it Dont demo minor fixes, trivial features mention them only dont detract from the more important user stories
Scrum and XP from the Trenches, Henrik Kniberg, 2007 C4Media inc
Reflection Basics What Are They?
Agile Manifesto, Principle 12

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly
Answer questions
What did we deliver versus what we expected to deliver? Are we really Agile? What debt did we incur? What went well? What needs improvement? What one or two things could we do better next time?
70
IBM Account Agile checklist
You know youre not iterative when Iterations are longer than 4 weeks They are not time-boxed (Each iteration has its own deadline) Team tries to finish all design specifications before programming Iteration doesnt result in workable code Iterations dont include testing
You know you do not use Scrum when The team doesnt know who the product owner is Your user stories dont contain estimates You cannot generate a release burn-down chart and you dont know your velocity
71
Reflection tools: Deployment evaluation framework
72
Reflect each iteration

Practice Use Cases Unit Test Comments Use Stories instead Not enough, not in build Mean 7.8 6.8 Deviation 0.50 1.89
Big Picture
Bullpen [Custom] Vision Use Cases Automated Unit Tests
Stakeholder Feedback Want more Time-Boxed Iterations Daily Scrum Test Early Reflections Static Analysis Not well specified Not Fridays Not enough TDD Need clear actions Not automated yet. 8.5 8.3 9.3 4.5 8.8 3.3 0.58 0.50
Scrum meeting
0.50
Iterative
2.91 0.50 0.96
Non Solo Reflections 0 2 4 6 8 10
Improve Reflect for each iteration Tackle new practices Optional DEF approach
Used by the team to improve not a scorecard Triggers discussion. Team reflects for one hour each iteration. Choose and *Nail* two improvements in the next 2 months. Tackle new practices when others are mastered Optional: share experience report at end of release on your wiki Use this DEF approach, or choose something at least as good
See https://w3.webahead.ibm.com/w3ki/display/agileatibm/DEF
73
Ownership The Team
Who owns the data?
Who owns the process and use of practices?
We dont mind if they share data, pitfalls, and improvements with the organization. But its optional because they have to feel comfortable doing self reflection.
74
Questions?
75
Thank You!
76

Agile Overview

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Agile Overview

Uploaded by

Copyright:

Available Formats

Agile Overview

Radha Sharma ISL Quality Team Oct 2011

Copyright IBM Corporation 2009

Characteristics of Agile Projects

Characteristics of Agile Projects

What Agile is NOT!

Why was/is waterfall so popular

Note: IID = Iterative and Incremental Development

Agile Defined (Industry)

The IBM Agile Manifesto

Agile development must

Agile Defined (IBM)

Agile Defined (IBM)

Waterfall and Agile-Core processes

Waterfall Project Profile

Right Client Right Team

Agile-Core Project Profile

Right Client Right Team

Key Characteristics of Successful Agile Projects at IBM

Stable code in Time-Boxed, Short Iterations

Agile Framework Agile Framework

Unified Process Simplified version of Rational Unified Process reduced

Frequent delivery Reflective improvement

Agile Techniques: The above methods involve a range of techniques including:

Continuous integration Design improvement Small releases Simple design

Static Analysis Coding standard Sustainable pace Whole team

Scrum Deep Dive

Mountain Goat Software, LLC

Image owned by Teivovo, Fiji Rugby, 2007

Scrum Development Process

Daily Scrum Meeting

Iteration Review Meeting

NOT status for the ScrumMaster BUT commitments in front of peers

Scrum Development Process

Blocks Daily Scrum List Meeting Iteration Review Meeting 24 hours

Iteration Planning meeting

Iteration 2-4 weeks

Potentially shippable Product Increment

New or Changed Story

Done, done, done, done!

Our IBM-flavored Definition of Done

Can this really be done? This puts a high premium on:

Scrum of Scrums of Scrums

Scaling the product owner

Running the scrum of scrums

Attendees discuss the product backlog for the scrum of scrums

Product Backlog and User Stories

Product Backlog Product Backlog

User Stories: Components

User Stories are comprised of three things

User Story the 3 Cs

User Stories: Card: A brief description

User Stories: Conversation

Significant value happens here

Include many people

User Stories: Confirmation: Acceptance Tests

The product owners conditions of satisfaction must be added to a story.

Easy, binary Done or not

Done or not done; no partially finished or done except

User Stories: Assumptions and Estimating Elements

Assumptions and Estimating Elements augment the User Story.

Assumptions Estimating Elements

Document any assumptions for the User Story.

Data migration conversion