This is the presentation I did at CS

1. Structured Agile Project
Management Processes
Hiren R. Doshi
hirendoshi@practiceagile.com
© 2011 PracticeAgile

2. Introductions
 Over 17 years of corporate Software Development
experience
 Owner, Agile Coach and Consultant @
PracticeAgile.com
 Active blogger on www.practiceagile.com
 Certifications - PMP, CSP, CSM, Lean Six Sigma Green
Belt
 M.S Computer Science, UMASS
hirendoshi@practiceagile.com
Cell: +91 9619322001
LinkedIn: http://in.linkedin.com/in/doshih
© 2011 PracticeAgile

3. Agenda
 Traditional Software Development Methodology
 Agile Manifesto & Principles
 Scrum Framework
 Case Study
 Overlaying CMMI on Agile Practices
© Hiren Doshi - PracticeAgile
© 2011 PracticeAgile

4. Traditional SDLC
© 2011 PracticeAgile

5. © 2011 PracticeAgile

6. Traditional SDLC
 Commonly known as
“Waterfall”
 Detailed requirement
gathering, Designing,
Implementing, Testing and
Deploying.
 Follow a well defined
documented process
 It’s supremely logical –
think before you build,
document everything,
follow the plan.
© 2011 PracticeAgile

7. Pros of traditional SDLC process
 Clear project objectives
 Stable project requirements
 Progress of system is measurable
 Strict sign-off at each stage
 Well Documented process, follows checkpoint model.
PRD, SRS, High level design, Test Plan, Test cases,
Documentation
© 2011 PracticeAgile

8. Challenges with SDLC
 Late changing requirements are not welcome
 All requirement have to be generated upfront
 Difficult to keep up with the competition
 Integration errors which can result in unpredictable
process.
 Growing defect backlog
 Manual and Regression testing
© 2011 PracticeAgile

9. Agile Adoption
VersionOne -2010 State of Agile Development Survey Results
© 2011 PracticeAgile

10. VersionOne -2010 State of Agile Development Survey Results
© 2011 PracticeAgile

11. VersionOne -2010 State of Agile Development Survey Results
© 2011 PracticeAgile

12. Agile Methodology
 Iterative way of development producing incremental delivery
of working software in time-boxed interval of 2 to 4 weeks
Iteration Iteration Iteration Iteration
1 2 3 n
 Is primarily a mechanism for continuous feedback from
customers to successively refine and deliver a software
system.
© Hiren Doshi - PracticeAgile
© 2011 PracticeAgile

13. How is Agile different from Traditional
approaches? The paradigm shift
© Hiren Doshi - PracticeAgile Source: www.dsdm.org
© 2011 PracticeAgile

14. Traditional vs Agile Feedback
© Hiren Doshi - PracticeAgile
© 2011 PracticeAgile

15. The Agile Manifesto (Agile Values)
Individuals and
Interactions Over Processes and Tools
Comprehensive
Working Software Over Documentation
Customer
Over Contract negotiation
Collaboration
Responding to
Over Following a plan
change
© 2011 PracticeAgile

16. 12 Principles of the Agile Manifesto
1. Satisfy the customer through early and
continuous delivery
2. Welcome changing requirements, even late in
development
3. Deliver working software frequently
4. Business people and developers work
together daily
5. Build projects around motivated individuals
6. Convey information via face-to-face
conversation
© 2011 PracticeAgile

17. 12 Principles of the Agile Manifesto
cont..
7. Working software is the primary measure of
progress
8. Maintain constant pace indefinitely
9. Give continuous attention to technical excellence
10. Simplify: maximizing the amount of work not done
11. Teams self-organize
12. Teams retrospect and tune behavior - Inspect &
Adapt
© 2011 PracticeAgile

18. Agile is Mainstream!
VersionOne -2010 State of Agile Development Survey Results
© 2011 PracticeAgile

19. Scrum
© Hiren Doshi - PracticeAgile

20. Scrum
Daily Standup
Product Owner The Team Sprint Demo
Sprint Goal 2 to 4
Weeks
Login Sprint Backlog
Order
Inventory
Product Backlog Scrum Master
Reporting
Sprint Retrospective
© 2011 PracticeAgile

21. Avoid miniature waterfalls
Rather than doing all of one
thing at a time...
...Scrum teams do a little of
everything all the time
Source: “The New New Product Development Game” by Takeuchi
and Nonaka. Harvard Business Review, January 1986.
© 2011 PracticeAgile

22. The sprint should look like …
Sprint 1
Analysis Analysis Analysis Analysis Analysis Analysis Analysis
Design Design Design Design Design Design Design
Dev Dev Dev Dev Dev Dev Dev
Deploy Deploy Deploy Deploy Deploy Deploy Deploy
Testing Testing Testing Testing Testing Testing Testing
Rapid cycle – minimal testing lag
© 2011 PracticeAgile

23. VersionOne -2010 State of Agile Development Survey Results
© 2011 PracticeAgile

24. Barriers to further Agile Adoption
© 2011 PracticeAgile VersionOne -2010 State of Agile Development Survey Results

25. Greatest concern about Adopting Agile
© 2011 PracticeAgile VersionOne -2010 State of Agile Development Survey Results

26. Agile techniques employed
© 2011 PracticeAgile VersionOne -2010 State of Agile Development Survey Results

27. © 2011 PracticeAgile
VersionOne -2010 State of Agile Development Survey Results

28. © 2011 PracticeAgile VersionOne -2010 State of Agile Development Survey Results

29. Case Study: Transitioning 150+ team to
Agile Transformation
• The reason to move to Agile
• Approach
• Cultural Changes
• Recruiting Specialists
• Investment in Hardware, Software, Tools
• Training & Roll-out.
• Scrum of Scrums
© 2011 PracticeAgile

30. Structured Agile Project
Management Processes
Hiren R Doshi
Enterprise Agile / Scrum Coach
hirendoshi@practiceagile.com
Cell - +91 9619322001
© Hiren Doshi - PracticeAgile
© 2011 PracticeAgile