SE18_Lec 05_Agile Software Development

1
‫ر‬َ‫ـد‬ْ‫ق‬‫ِـ‬‫ن‬،،،‫لما‬‫اننا‬ ‫نصدق‬ْْ‫ق‬ِ‫ن‬‫ر‬َ‫د‬
Faculty of Engineering - Helwan University

2
 A software development methodology or system
development methodology is used to structure, plan,
and control the process of developing an information
system.
 Classical methods of software development have many
disadvantages:
 Huge effort during the planning phase.
 Poor requirements conversion in a rapid changing
environment.
 Treatment of staff as a factor of production.
 New philosophy : Agile Software Development

4
 An iterative process is one that makes progress through
successive refinement
 An incremental process is one in which software is built
and delivered in pieces. Each piece, or increment,
represents a complete subset of functionality

8
 Able to move quickly and easily

9
 A group of software development methods based on
iterative and incremental development
 Requirements and solutions evolve through collaboration
between self-organizing, cross-functional teams
 Promotes adaptive planning, evolutionary development
and delivery, a time-boxed iterative approach, and
encourages rapid and flexible response to change

10
 On February 11-13 2001, 17 people met to find common
grounds in software development methodologies
 What emerged is the Agile Software Development
Manifesto

11
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.

13
Manifesto for waterfall Software Development
Software development can be equated to any other engineering task. We
believe software development projects can be effectively managed by:
………………………………………………………………………………………………………………..
 Understanding and writing specifications that define how the software will look
and what it will do
 Performing in-depth analysis and design work before estimating development
costs
 Ensuring software developers follow the specifications
 Testing the software after implementation to make sure it works as specified,
 and Delivering the finished result to the user
………………………………………………………………………………………………………………..
That is, if the specification is of sufficient detail, then the software will
be written such that it will satisfy the customer, will be within budget,
and will be delivered on time.

14
 Qualities:
 Minimize risk  short iterations
 Real-time communication (prefer face-to-face)  very
little written documentation
 Indicated for unpredictable / rapidly changing
requirements

15
 The following principles are those that differentiate
agile processes from others.
 Our Highest Priority is to Satisfy the Customer through Early
and Continuous Delivery of Valuable Software.
 Welcome Changing Requirements, even late in Development.
 Deliver working software frequently, from a 2-4 weeks. with
a preference to the shorter timescale.
 Business People and Developers must Work Together Daily
through out the Project.
 Build projects around motivated individuals. Give them the
environment and support they need, and trust them to get
the job done.

16
 The most efficient and effective method of conveying
information to and within a development team is Face-To-
Face Conversation.
 Working software is the primary measure of progress.
 Agile processes promote sustainable development. The
sponsors, developers, and users should be able to maintain
a constant pace indefinitely.
 Continuous attention to technical excellence and good
design enhances agility. [i.e. High quality is the key to
high speed]

17
 Simplicity--the art of maximizing the amount of work not
done--is essential.
• Agile teams take the simplest path that is consistent with
their goals.
• They don’t anticipate tomorrow’s problems and try to
defend against them today.
 The best architectures, requirements, and designs emerge
from Self-Organizing Teams.
 At regular intervals, the team reflects on how to become
more effective, then tunes and adjusts its behavior
accordingly

18
 Effective (rapid and adaptive) response to change (team
members, new technology, requirements)
 Effective communication in structure and attitudes
among all team members, technological and business
people, software engineers and managers。
 Drawing the customer into the team. Eliminate “us and
them” attitude. Planning in an uncertain world has its
limits and plan must be flexible.
 Organizing a team so that it is in control of the work
performed.

19
 Emphasize an incremental delivery strategy as opposed
to intermediate products that gets working software to
the customer as rapidly as feasible.
 Rapid, incremental delivery of software.
 The development guidelines stress delivery over analysis
and design although these activates are not discouraged,
and active and continuous communication between
developers and customers

20
 Key features must exist among the people on an agile
team and the team itself:
 Competence. ( talent, skills, knowledge)
 Common focus. ( deliver a working software increment )
 Collaboration. ( peers and stakeholders)
 Decision-making ability. ( freedom to control its own
destiny)
 Problem-solving ability. (ambiguity and constant changes,
today problem may not be tomorrow’s problem)
 Mutual trust and respect.
 Self-organization. ( themselves for the work done, process
for its local environment, the work schedule)

21
 Agile methods:
 Scrum
 Kanban
 Scrum ban
 eXtreme Programming (XP)
 Agile Unified Process (AUP)
 Feature Driven Development (FDD)
 Dynamic System Development Method (DSDM)
 Adaptive Software Development (ASD)
 Lean Software Development
 Crystal Clear Methods
 Custom Hybrids
 …

24
 Scrum in the sport of rugby, is a way of restarting the
game, either after an accidental infringement or (in
rugby league only) when the ball has gone out of play

26
 Scrum is an agile process that allows us to focus on
Delivering the highest business value in the shortest
time.
 It allows us to rapidly and repeatedly inspect actual
working software (every two weeks to one month).
 The business sets the priorities: teams self-organize to
determine the best way to deliver the highest priority
features.
 Every two weeks to a month anyone can see real
working software and decide to release it as is or
continue to enhance it for another sprint.

27
 SCRUM:
 is an agile, lightweight process.
 can manage and control software and product development.
 uses iterative, incremental practices.
 has a simple implementation
 is Team-based approach.
 increases productivity
 reduces time to benefits
 is developing systems/ products with rapidly changing
requirements.
 Controls the chaos(‫)فوضى‬ of conflicting interest and needs.
 Improve communication and maximize cooperation.
 Protecting the team form disruptions (‫اضطرابات‬) and impediments
(‫العوائق‬).

28
 Microsoft
 Yahoo
 Google
 Electronic Arts
 High Moon Studios
 Lockheed Martin
 Philips
 Siemens
 Nokia
 Capital One
 BBC
 Intuit
 Intuit
 Nielsen Media
 First American Real Estate
 BMC Software
 Ipswitch
 John Deere
 Lexis Nexis
 Sabre
 Salesforce.com
 Time Warner
 Turner Broadcasting
 Oce

29
 Commercial software
 In-house development
 Contract development
 Fixed-price projects
 Financial applications
 ISO 9001-certified
applications
 Embedded systems
 24x7 systems with 99.999%
uptime requirements
 the Joint Strike Fighter
 Video game development
 FDA-approved, life-critical
systems
 Satellite-control software
 Websites
 Handheld software
 Mobile phones
 Network switching
applications
 ISV applications
 Some of the largest
applications in use

30
 Jeff Sutherland
 Initial scrums at Easel Corp in 1993
 IDX and 500+ people doing Scrum
 Ken Schwaber
 ADM
 Scrum presented at OOPSLA 96 with Sutherland
 Author of three books on Scrum
 Mike Beedle
 Scrum patterns in PLOPD4
 Ken Schwaber and Mike Cohn
 Co-founded Scrum Alliance in 2002, initially within Agile Alliance

31
Product Backlog
As prioritized by
Product Owner
Sprint Execution
2-4 Weeks

32
Rather than doing all of
one thing at a time...
...Scrum teams do a little
of everything all the time
Requirements Design Code Test

33
•Product owner
•Scrum Master
•Team
Roles
•Sprint planning
•Sprint review
•Sprint retrospective
•Daily scrum meeting
Ceremonies
•Product backlog
•Sprint backlog
•Burndown charts
Artifacts

34
 Product Owner
 Possibly a Product Manager or Project Sponsor
 Knows what needs to be build and in what Sequence this should be
done
 Decides features, release date, prioritization, $$$
 Accept or reject work results.
 Scrum Master
 Typically a Project Manager or Team Leader
 Responsible for enacting Scrum values and practices
 Remove impediments / politics, keeps everyone productive
 Project Team
 5-9 members; Teams are self-organizing
 Cross-functional: QA, Programmers, UI Designers, etc.
 Membership should change only between sprints

35
 Pig: Team member committed to success of project
 Chicken: Not a pig; interested but not committed
A pig and a chicken are walking down a road. The chicken looks at
the pig and says, "Hey, why don't we open a restaurant?" The pig
looks back at the chicken and says, "Good idea, what do you want to
call it?" The chicken thinks about it and says, "Why don't we call it
'Ham and Eggs'?" "I don't think so," says the pig, "I'd be committed
but you'd only be involved."

36
 Sprint Planning Meeting
 Daily Scrum
 Sprint Review Meeting

37
 A collaborative meeting in the beginning of each Sprint
between the Product Owner, the Scrum Master and the
Team
 Takes 8 hours and consists of 2 parts (“before lunch and
after lunch”)
 1st Part:
• Determining the Sprint Goal.
• Participants: Product Owner, Scrum Master, Scrum Team
 2nd Part:
• Participants: Scrum Master, Scrum Team
• Creating Sprint Backlog

38
Sprint planning meeting
Sprint prioritization
• Analyze/evaluate product
backlog
• Select sprint goal
Sprint planning
• Decide how to achieve sprint
goal (design)
• Create sprint backlog (tasks)
from product backlog items (user
stories / features)
• Estimate sprint backlog in hours
Sprint
goal
Sprint
backlog
Business
conditions
Team
capacity
Product
backlog
Technology
Current
product

39
 Parameters
 Daily, ~15 minutes, Stand-up
 Anyone late pays a $1 fee
 Is NOT a problem solving session
 Is NOT a way to collect information about WHO is behind the
schedule
 Is a meeting in which team members make commitments to each
other and to the Scrum Master (Pig & chicken)
 Is a good way for a Scrum Master to track the progress of the
Team
 Three questions answered by each team member:
1. What did you do yesterday?
2. What will you do today?
3. What obstacles are in your way?

40
 Is held at the end of every sprint
 Business functionality which was created during the
Sprint is demonstrated to the Product Owner
 Informal
 2-hour prep time rule
 No slides
 Whole team participates
 Invite the world

41
 A special form of Sprint Planning Meeting
 Meeting before the begin of the Project

42
 Typical individual team is 7 ± 2 people
 Scalability comes from teams of teams
 Factors in scaling
 Type of application
 Team size
 Team dispersion
 Project duration
 Scrum has been used on multiple 500+ person projects

44
 Scrum has remarkably few artifacts
 Product Backlog
 Sprint Backlog
 Burndown Charts
 Can be managed using just an Excel spreadsheet
 More advanced / complicated tools exist:
• Expensive
• Web-based – no good for Scrum Master/project manager who
travels
• Still under development

45
 The requirements
 A list of all desired work on
project
 Ideally expressed as a list of
user stories along with "story
points", such that each item
has value to users or
customers of the product
 Prioritized by the product
owner
 Reprioritized at start of each
sprint
 Is only a FORECAST!-> is not
exact

46
 Instead of Use Cases, Agile project owners do "user stories"
 Who (user role) – Is this a customer, employee, admin, etc.?
 What (goal) – What functionality must be achieved/developed?
 Why (reason) – Why does user want to accomplish this goal?
As a [user role], I want to [goal], so I can [reason].
 Example:
 "As a user, I want to log in, so I can access subscriber content.“

47
 Story points: Rating of effort needed to implement this story
 common scales: 1-10, shirt sizes (XS, S, M, L, XL), etc.
 Methods of estimation:
 Expert Review
 Creating a Work Breakdown Structure (WBS)

48
Backlog item Estimate
Allow a guest to make a reservation 3 (story points)
As a guest, I want to cancel a reservation. 5
As a guest, I want to change the dates of a reservation. 3
As a hotel employee, I can run RevPAR reports (revenue-
per-available-room)
8
Improve exception handling 8
... 30
... 50

50
 Scrum projects make progress in a series of “sprints”
 Typical duration is 2–4 weeks or a calendar month at
most
 Product is designed, coded, and tested during the sprint
 NO outside influence can interference with the Scrum
team during the Sprint

51
 Individuals sign up for work of their own choosing
 Work is never assigned
 Estimated work remaining is updated daily
 Any team member can add, delete change sprint backlog
 If work is unclear, define a sprint backlog item with a
larger amount of time and break it down later
 No more then 300 tasks in the list
 If a task requires more than 16 hours, it should be
broken down

53
Tasks
Code the user interface
Code the middle tier
Test the middle tier
Write online help
Write the Foo class
Mon
8
16
8
12
8
Tue
4
12
16
8
Wed Thu
4
11
8
4
Fri
8
8
Add error logging
8
10
16
8
8

55
 A display of what work has been completed (work done)
and what is left to complete
 There are three-types:
 Sprint Burn down Chart (progress of the Sprint)
 Release Burn down Chart (progress of release)
 Product Burn down chart (progress of the Product)

56
Hours
 X-Axis: time (usually in days)
 Y-Axis: remaining effort

57
Hours
40
30
20
10
0
Mon Tue Wed Thu Fri
Tasks
Code the user interface
Code the middle tier
Test the middle tier
Write online help
Mon
8
16
8
12
Tue Wed Thu Fri
4
12
16
7
11
8
10
16 8
50

58
No work being performed
Sprint 1 Burndown
0
10
20
30
40
50
60
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Days in Sprint
Hoursremaining

59
Work being performed, but not fast enough
Sprint 1 Burndown
40
41
42
43
44
45
46
47
48
49
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Days in Sprint
Hoursremaining

60
Work being performed, but too fast!
Sprint 1 Burndown
0
10
20
30
40
50
60
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Days in Sprint
Hoursremaining

61
 Will the release be done on right time?
 X-axis: sprints
 Y-axis: amount of hours remaining
 The estimated work remaining can also burn up

62
 Is a “big picture” view of project’s progress (all the
releases)

63
 Advantages
 Completely developed and tested features in short iterations
 Simplicity of the process
 Clearly defined rules
 Increasing productivity
 Self-organizing
 each team member carries a lot of responsibility
 Improved communication
 Combination with Extreme Programming
 Drawbacks
 “Undisciplined hacking” (no written documentation)
 Violation of responsibility
 Current mainly carried by the inventors

64

66
Principle Description
Customer involvement
The customer should be closely involved throughout the
development process. Their role is provide and prioritise new
system requirements and to evaluate the iterations of the
system.
Incremental delivery
The software is developed in increments with the customer
specifying the requirements to be included in each increment.
People not process
The skills of the development team should be recognised and
exploited. The team should be left to develop their own ways
of working without prescriptive processes.
Embrace change
Expect the system requirements to change and design the
system so that it can accommodate these changes.
Maintain simplicity
Focus on simplicity in both the software being developed and
in the development process used. Wherever possible,
actively work to eliminate complexity from the system.

67
 It can be difficult to keep the interest of customers who
are involved in the process.
 Team members may be unsuited to the intense
involvement that characterizes agile methods.
 Prioritizing changes can be difficult where there are
multiple stakeholders.
 Maintaining simplicity requires extra work.
 Contracts may be a problem as with other approaches to
iterative development.

68
 Perhaps the best-known and most widely used agile
method.
 Extreme Programming (XP) takes an ‘extreme’ approach
to iterative development.
 New versions may be built several times per day;
 Increments are delivered to customers every 2 weeks;
 All tests must be run for every build and the build is only
accepted if tests run successfully.

69
 Formulated in 1999 by Kent Beck, Ward Cunningham and
Ron Jeffries
 Agile software development methodology (others:
Scrum, DSDM)
 Developed in reaction to high ceremony methodologies

71
 Previously:
 Get all the requirements before starting design
 Freeze the requirements before starting development
 Resist changes: they will lengthen schedule
 Build a change control process to ensure that proposed
changes are looked at carefully and no change is made
without intense scrutiny
 Deliver a product that is obsolete on release

72
 Recognize that:
 All requirements will not be known at the beginning
 Requirements will change
 A key assumption of XP is that the cost of changing a program
can be hold mostly constant over time
 Use tools to accommodate change as a natural process
 Do the simplest thing that could possibly work and refactor
mercilessly
 Emphasize values and principles rather than process
 Hence XP is a lightweight (agile) process:
 Instead of lots of documentation nailing down what customer wants up
front, XP emphasizes plenty of feedback
 Embrace change: iterate often, design and redesign, code and test
frequently, keep the customer involved
 Deliver software to the customer in short (2 week) iterations
 Eliminate defects early, thus reducing costs

73(Source: http://www.xprogramming.com/xpmag/whatisxp.htm)

74
 All contributors to an XP project are one team
 Must include a business representative--the ‘Customer’
 Provides requirements
 Sets priorities
 Steers project
 Team members are programmers, testers, analysts,
coach, manager
 Best XP teams have no specialists

75
 Two key questions in software development:
 Predict what will be accomplished by the due date
 Determine what to do next
 Need is to steer the project
 Exact prediction (which is difficult) is not necessary

76
 XP Release Planning
 Customer comes up with a list of desired features for the system
 Each feature is written out as a user story
• Describes in broad strokes what the feature requires
• Typically written in 2-3 sentences on 4x6 story cards
 Programmers estimate difficulty
 Developers estimate how much effort each story will take, and
how much effort the team can produce in a given time interval
(iteration)
 XP Iteration Planning
 Two week iterations
 Customer presents features required
 Programmers break features down into tasks
 Team members sign up for tasks
 Running software at end of each iteration

77
 Development team has continuous access to a real live
customer, that is, someone who will actually be using
the system, or a proxy
 The Customer defines one or more automated
acceptance tests for a feature
 Team builds these tests to verify that a feature is
implemented correctly
 Once the test runs, the team ensures that it keeps
running correctly thereafter
 System always improves, never backslides

78
 Start with the smallest useful feature set (release(
 Team releases running, tested software every iteration
 The Customer can evaluate or in turn, release to end
users, and provide feedback
 Important thing is that the software is visible and given
to the Customer at the end of every iteration

79
 Always use the simplest possible design that gets the job
done
 Through programmer testing and design improvement,
keep the software simple and the design suited to
current functionality
 Not a one-time thing nor an up-front thing
 Design steps in release planning and iteration planning
 Teams design and revise design through refactoring,
through the course of the project

80
 All production software is built by two programmers,
sitting side by side, at the same machine
 Driver enters code, while navigator critiques it
 Periodically switch roles
 All production code is therefore reviewed by at least
one other programmer
 Research into pair programming shows that:
 pairing produces better code (High Quality Code) in the
same time as programmers working singly
 Pair programming increases productivity
 Pairing also communicates knowledge throughout the
team

81
 Teams practice TDD by working in short cycles of adding
a test, and then making it work.
 Writing tests before code clarifies the requirements to
be implemented (or before adding a feature, write a
test for it!).
 Tests are written as programs rather than data so that
they can be executed automatically. The test includes a
check that it has executed correctly.
 Easy to produce code with 100 percent test coverage
 Each time a pair releases code to the repository, every
test must run correctly

82
 Tests come in two basic flavors…
1. Unit Tests automate testing of functionality as developers
write it
 Each unit test typically tests only a single class, or a small cluster of classes
 Unit tests typically use a unit testing framework, such as JUnit (xUnit)
 Experiments show that test-driven development reduces debugging time
 Increases confidence that new features work, and work with everything
 If a bug is discovered during development, add a test case to make sure it
doesn’t come back!
2. Acceptance Tests (or Functional Tests) are specified by the
customer to test that the overall system is functioning as
specified
 When all the acceptance tests pass, that user story is considered complete
 Could be a script of user interface actions and expected results
 Ideally acceptance tests should be automated, either using a unit testing
framework, or a separate acceptance testing framework

83
 Continuous design improvement process called
‘refactoring’:
 Removal of duplication
 Increase cohesion
 Reduce coupling
 Refactoring is supported by comprehensive testing--
customer tests and programmer tests

84
 All changes are integrated into the code base at least
daily, or multiple times a day builds
 Avoid ‘integration hell’
 Avoid code freezes
 Tests have to run 100% both before and after integration

85
 No single person "owns" a module
 Any developer (pair of programmers) can work on any
part of the code base at any time
 No ‘secure workspaces’
 All code gets the benefit of many people’s attention
 Avoid duplication
 Programmer tests catch mistakes
 Pair with expert when working on unfamiliar code

86
 Use common coding standard
 All code in the system must look as though written by an
individual
 Code must look familiar, to support collective code
ownership

87
 XP Teams develop a common vision of the system
 With or without imagery, define common system of
names
 Ensure everyone understands how the system works,
where to look for functionality, or where to add
functionality

88
 Team will produce high quality product when not overly
exerted
 Avoid overtime, maintain 40 hour weeks
 Programmers go home on time
 “fresh and eager every morning, and tired and satisfied every
night”
 In crunch mode, up to one week of overtime is allowed
 More than that and there’s something wrong with the process
 ‘Death march’ projects are unproductive and do not
produce quality software
 Work at a pace that can be sustained indefinitely

89
 Goal: Identify items to be accomplished for the day and
raise issues
 Everyone attends, including the customer
 Not a discussion forum
 Take discussions offline
 Everyone gets to speak 15 minutes

90
 Communication
 Simplicity
 Feedback
 Courage

91
 Poor communication in software teams is one of the root
causes of failure of a project
 Stress on good communication between all stakeholders-
-customers, team members, project managers
 Customer representative always on site
 Paired programming

92
 DTSTTCPW principle (‘Do the Simplest Thing That Could
Possibly Work’)
 Implement a new capability in the simplest possible way
 Refactor the system to be the simplest possible code with
the current feature set
 YAGNI principle (‘You Aren’t Going to Need It’)
 Never implement a feature you don’t need now

93
 Feedback at different time scales
 Always a running system that delivers information about
itself in a reliable way
 The system and the code provides feedback on the state
of development
 Unit tests tell programmers status of the system
 Programmers produce new releases every
2-3 weeks for customers to review
 Catalyst for change and an indicator of progress

94
 Projects are people-centric
 Ingenuity of people and not any process that causes a
project to succeed
 The courage to communicate and accept feedback
 The courage to throw code away (prototypes)
 The courage to refactor the architecture of a system

95
 Williams, L. and Kessler, R., “All I Really Need to Know
about Pair Programming I Learned In Kindergarten,”
Communications of the ACM (May 2000)
 Share everything. (Collective code ownership)
 Play fair. (Pair programming—navigator must not be passive)
 Don’t hit people. (Give and receive feedback. Stay on track.)
 Clean up your own mess. (Unit testing.)
 Wash your hands before you eat. (Wash your hands of
skepticism: buy-in is crucial to pair programming.)
 Flush. (Test-driven development, refactoring.)
 Take a nap every afternoon. (40-hour week.)
 Be aware of wonder. (Ego-less programming, metaphor.)

96
 Unrealistic--programmer centric, not business focused
 Detailed specifications are not written
 Design after testing
 Constant refactoring
 Customer availability
 12 practices are too interdependent

97
 The best design is the code.
 Testing is good. Write tests before code. Code is
complete when it passes tests.
 Simple code is better. Write only code that is needed.
Reduce complexity and duplication.
 Keep code simple. Refactor.
 Keep iterations short. Constant feedback.

98
 Will you incorporate XP practices in your projects?
 What does this life cycle imply relationship between
customer and team, analyst/designers and programmers?
 Keep customer involved?
 The planning game—learn how to estimate effort for small
tasks?
 Embrace change? Many iterations and releases?
 Pair programming? Maintain discipline of switching
drivers?
 Junit tests before writing code?
 Stand up meetings?

99

105
 Advantages:
 More effective feedback
 More effective iterations (sprints) planning
 Disadvantages:
 Smaller stories are often too small to be valuableand
difficult to identify
 In the backlog of smaller stories could be hundreds of
items, instead of couple dozen in Kent Beck’s days
(eXtreme Programming). New problem of management
of stories has emerged.

106
 Doing Scrum well is very difficult. Most teams do not
reliably deliver their sprint commitment by the end of
the sprint.
 There is no one right way to do Scrum. Both
"Successful“ and "Improvable„ teams come in all sizes
and configurations.
 At least up to a point, more stories per sprint are
better. It looks like 10 to 15 is a good number. Most teams
should consider slicing their stories smaller.
 Very big stories are unlikely to be completed in the
sprint, but an occasional moderately sized story doesn't
look like it's a problem.

107
 Development work often continues throughout a cycle while
testing starts late and never seems to get enough time.

108
 Lean has been defined in many different ways.
 Is a systematic method in which the core idea is to
maximize customer value while minimizing waste
(“Muda”)
 Derived mostly from Toyota Production System (TPS) or
“Just-in-time production”

109
 In 1990 James Womack, Daniel T. Jones, and Daniel
Roos wrote a book called “The Machine That Changed
the World: The Story of Lean Production -- Toyota's
Secret Weapon in the Global Car Wars That Is Now
Revolutionizing World Industry”
 In this book, Womack introduced the Toyota Production
System to American.
 What was new was a phrase– "Lean Manufacturing"

110
 Value = What the customer pays money for
 Waste = Everything else!
 Muda ("non-value-adding work")
• Type 1: The non value added activity for end customer but it is
necessary.
• Type 2: The non value added activity for end customer which are
not necessary. It is targeted to eliminate this type of wastage.
 The first seven types of muda in manufacturing system:
• Storage
• Transportation
• Waiting
• Motion
• Process
• Defects
• Over-production

111
 Building features no one needs
 Write more specs than you can code
 Write more code than you can test
 Test more code than you can deploy

112
 Eliminate/Minimize waste
 Amplify learning
 Decide as late as possible
 Deliver as fast as possible
 Empower the team
 Build quality in
 See the whole

113
 Continuous Flow-of-Value
 Value Stream Mapping
 Bottleneck Analysis
 Kanban (Pull System)
 Poka-Yoke (Error-proofing)
 5 Whys
 Kaizen (Continuous Improvement)
 SMART Goals (Specific, Measurable, Attainable,
Relevant, and Time-Specific)

114
 Rather than focusing on being Agile which may (and
should) lead to being successful, Kanban focuses on
becoming successful, which may lead to being Agile.
 Anyone that has used a Scrum has used a simple Kanban
system.
 In Japanese the word Kan means "signal" and "ban"
means "card" or “board”. A Kanban card is a signal that
is supposed to trigger action. Therefore Kanban refers to
"signal cards".

115
 Start with existing process
 Agree to peruse incremental, evolutionary change
 Respect current process, roles, responsibilities and titles
 Leadership at all levels

116
 Visualize the Workflow
 Lead using a team approach
 Learn and Improve Continuously
 Reduce the Batch Size of your Efforts (BASE)
 Little’s Law:
Cycle Time = Work-in-progress / Average Completion Time

120
 A concise, written description of a piece of functionality
that will be valuable to a user (or owner) of the
software.
 Stories are:
 User’s needs
 Product descriptions
 Planning items
 Tokens for a conversation
 Mechanisms for deferring conversation
 seek to combine the strengths of written and verbal
communication, where possible supported by a picture.

121
 Description - A written description of the user story
for planning purposes and as a reminder
 Conversation - A section for capturing further
information about the user story and details of any
conversations
 Confirmation - A section to convey what tests will be
carried out to confirm the user story is complete and
working as expected

122
 As a [user role] I want to [goal]
so I can [reason]
 As a [type of user] I want to [perform some task] so
that I can [reach some goal]
 Example:
 As a registered user, I want to log in, so I can access
subscriber-only content.

123
 Who (user role)
 What (goal)
 Why (reason)
 gives clarity as to why a feature is useful
 can influence how a feature should function
 can give you ideas for other useful features
that support the user's goals

124
 Steps:
 Start with a title.
 Add a concise description using the templates.
 Add other relevant notes, specifications, or sketches
 Before building software write acceptance criteria (how do we
know when we’re done?)

127
 Detailed enough
 For the team to start working from
 To establish further details and clarifications
at the time of development.

128
 Independent – User Stories should be as independent as possible.
 Negotiable – a User Story is not a contract. It is not a detailed
specification. It is a reminder of features for the team to discuss
and collaborate to clarify the details near the time of development.
 Valuable – User Stories should be valuable to the user (or owner) of
the solution. They should be written in user language. They should
be features, not tasks.
 Estimatable – User Stories need to be possible to estimate. They
need to provide enough information to estimate, without being too
detailed.
 Small – User Stories should be small. Not too small and not too big.
 Testable – User Stories need to be worded in a way that is testable,
i.e. not too subjective and to provide clear details of how the User
Story will be tested.

129
 Agile customers or product
owner prioritize stories in a
backlog
 A collection of stories for a
software product is referred to
as the product backlog
 The backlog is prioritized so
that the most valuable items
have the highest priorities

130
 User Story Mapping is an approach to Organize and
Prioritize user stories
 Unlike typical user story backlogs, Story Maps:
 make the workflow or value chain visible
 show the relationships of larger stories to their child
stories
 help confirm the completeness of your backlog
 provide a useful context for prioritization
 plan releases in complete and valuable slices of
functionality.

131
 Spatial arrangement:
 By arranging activity and task-centric story cards spatially,
we can identify bigger stories
 Arrange activities left to right in the order you’d explain
them to someone when asked the question: “What do
people do with this system?”
time

132
 Overlap user tasks vertically if a user may do one of
several tasks at approximately the same time
 If in telling the story I say the systems’ user typically
“does this or this or this, and then does that”. “or”
signal a stacking vertically, and “then” signal stepping
horizontally.
time

133
 The map shows decomposition and typical flow across
the entire system.
 Reading the activities across the top of the system helps
us understand end-to-end use of the system.
time
Below each activity, or large
story are the child stories that
make it up

134
 Prioritizing based on product goal
 Product goals describe what outcome or benefit is received by
the organization after the product is put into use
 Use product goals to identify candidate incremental releases,
where each release delivers some benefit
 Create horizontal swim-lanes to group features into releases
 Arrange features vertically by necessity from the user’s
perspective
 Split tasks into parts that can be deferred till later releases
 Use the product goals to identify slices that incrementally
realize product goals.

135
optionality
necessary
less
optional
more
optional

136
 We can also use templates to write test cases for the
use stories. One tool that employs such templates is
CUCUMBER.
 The template is as follows:
 Scenario: a short description of the test scenario
 Given: test preconditions
 When: test action – input
 Then: test result – output
 And: can be used to include more than one
precondition, input or output.

137
Scenario: memory BIT
When: we have inserted a memory fault
And: run a memory BIT
Then: the memory fault flag should be set
And: the system should move to the error state

138
 User Stories combine written and verbal communications,
supported with a picture where possible.
 User Stories should describe features that are of value to the
user, written in the user’s language.
 User Stories detail just enough information and no more.
 Details are deferred and captured through collaboration
just in time for development.
 Test cases should be written before development, when the
User Story is written.
 User Stories should be Independent, Negotiable, Valuable,
Estimatable, Small and Testable.

139

SE18_Lec 05_Agile Software Development

More Related Content

What's hot (18)

Similar to SE18_Lec 05_Agile Software Development (20)

More from Amr E. Mohamed (20)

Recently uploaded (20)

SE18_Lec 05_Agile Software Development