Software Development Process Model: Agile Model with SCRUM Framework

1. Agile Process
(SCRUM)

2. WHO AM I?
 Jakir Hosen Khan, Programmer, National
Board of Revenue
 8 Years of industrial experience
 ASYCUDA, PMIS, FED

3. Outline
 SDLC
 Waterfall Model
 Iterative Model
 Agile Model
 SCRUM

4. SDLC
4

5. Waterfall
5

6. Waterfall ......
6

7. Waterfall ......
7
Issues:
 Working software is produced at the end of the life cycle.
 High amounts of risk and uncertainty.
 Not a appropriate for complex and object-oriented projects
 Cannot accommodate changing requirements.

8. Iterative
8

9. Iterative
9
Advantage:
 Results are obtained early and periodically
 Parallel development can be planned
 Less costly to change the scope/requirements
 Testing and debugging during smaller iteration is easy
 Risk analysis is better

10. Iterative
10
Disadvantage:
 More resources may be required
 Not suitable for changing requirement & smaller projects
More management attention is required

11. Agile
11
 Combination of iterative and incremental process models
 Focus of adaptability and customer satisfaction
 Break into small incremental builds
 iteration typically lasts 1-3 weeks
 Cross functional teams working
 End of the iteration, a working product is displayed to the customer

12. Agile
12

13. Agile
13
Agile Manifesto

14. Agile
14

15. Agile
15
Advantage
 Realistic approach
 Promotes teamwork and cross training.
 Functionality developed rapidly and demonstrated.
 Resource requirements are minimum.
 Suitable for fixed or changing requirements
 Delivers early partial working solutions.
 Good model for environments that change steadily.
 Minimal rules, documentation easily employed.
 Little or no planning required.
 Easy to manage.
 Gives flexibility to developers.

16. Agile
16
Advantage
 Not suitable for handling complex dependencies.
 Strict delivery management dictates the scope, functionality to be
delivered, and adjustments to meet the deadlines.
 Depends heavily on customer interaction, so if customer is not clear,
team can be driven in the wrong direction.
 Transfer of technology to new team members may be quite
challenging due to lack of documentation.

17. Agile
17
Agile Framework
 Rational Unified Process (1994),
 Scrum (1995),
 Extreme Programming (1996),
 Adaptive Software Development,
 Feature Driven Development,
 Dynamic Systems Development Method (DSDM) (1995).

18. Agile …
18
 Rational Unified Process (1994),
 Scrum (1995),
 Extreme Programming (1996),
 Adaptive Software Development,
 Feature Driven Development,
 Dynamic Systems Development Method (DSDM) (1995).

19. Scrum
19
 Lightweight framework for small, co-locate teams to develop complex products.
 Ken Schwaber and Jeff Sutherland developed Scrum
 Not inherently technical, you can adopt the tools and practices to other Industry
 Main goal is “inspect and adapt” means team focus on continuous improvement
of their process as well as product

20. Scrum…
20
Role:
 Product Owner
 Scrum Master
 Team Member

21. Product Owner
21
 Responsible for maximize the return of investment to the team
 Directs team away from less valuable work to most valuable work
 Make sure that team fully understand the requirement
 Responsible for recording requirements, often form the user stories

22. Product Owner…
22
 Hold the vision of the product
 Represents the interest of the business
 Represents the customers
 Owns the product backlog
 Orders the items in the product backlogs
 Create acceptance criteria for the backlog items

23. Scrum Master…
23
 Act as a coach, guides the team to higher levels of cohesiveness, self-organization, and
performance
 While a team’s deliverable is the product, Scrum Master’s deliverable is high performing, self-
organizing team
 Scrum master is not a team boss
 Helps team to learn and apply scrum/agile process
 Constantly available to remove any kinds of impediments

24. Scrum Master
24
 Expert and advisor
 Coach
 Impediment bulldozer
 Facilitator

25. Team Member
25
 Decide which tools and technique to use
 People who do the work are the highest authorities on how best to do it
 Team should passes all of the skills required to create a potential shippable product
 Mind set change from “doing my job” to “doing the job”
 Change in focus form “what we are doing” to “what is getting done”

26. Team size
26
 Should be kept in the range from five to nine people
 Fewer than five team members decrease interaction and results in smaller productivity gains
 Having more than nine members requires too much coordination

27. Scrum Artifacts
27
 Product backlog
 Sprint backlog
 Burn chart
 Task board
 Definition of Done

28. Product backlog
28
 List of desired deliverables
 Includes features, bug fixes, documentation change, anything valuable to produce
 Called ‘backlog items’ often preferred term is ‘User Story’
 Prioritized most important at top

29. Sprint backlog
29
 To do list for the sprint
 Include all stories team committed to deliver current sprint
 Stories are deliverable
 Tasks are thinks must be done in order to deliver the stories
 Story is something a team delivers, tasks is a bit of work a person done

30. Burn-Down Chart
30

31. Scrum Board
31

32. Sprint Cycle
32
 Sprint planning
 Daily Scrum
 Backlog Grooming
 Sprint Review
 Retrospective

33. Sprint Cycle
33

34. Sprint planning meeting
34
Two part
 First part: What we will do?
 Second Part: How we will do?

35. Part I: What will do?
35
 Emerge with a committed stories
 Team believes they can delivery at the end of this sprint
 Product owner leads this part, clarifies team’s questions
and refines the story with the team

36. Part II: How we will do?
36
 Decompose stories into tasks
 Remember, deliverables are things that stockholders,
users and customers want
 Product owner should be available during half of the
meeting to answer the question of team
 Output is sprint backlog list of all committed stories with
their associated tasks

37. Daily Scrum
37
 Daily – start of their work day, can be adopted
 Brief – not more than 15 minutes
 What tasks I have completed since last daily scrum
 What tasks I expect to complete by next daily scrum
 What obstacles are showing me down

38. Backlog Grooming
38
 Improving stories aren’t in the sprint, but in the backlog
 Define and refine acceptance criteria
 Perform story sizing during this session
 Split large stories, top of the product backlog needs to
be populated with smaller stories

39. Sprint Review meeting
39
 Public end of the sprint
 Invite to all stockholders
 Show off accomplishment
 If any undone stories share to the stockholders
 Not a decision making meeting if stories are done or
not, that needs to happen prior to this meeting
 Maximum one hour for every week of development

40. Retrospective
40
 Inspect and adept, ever improve
 After sprint, focus on what was learned and how learning
can be applied to improve
 Two hours max
 Get few implementable action items to improve the team

41. 41
Thanks!
Any questions?
You can find me at jakirkhan71@gmail.com