Chapter 2 Time boxing & agile models

Sofware Process 2
Time boxing
 Time boxing – fix an iteration duration, determine
specs. acc.
 Development is done iteratively in fixed duration
time boxes
 Each time box divided in fixed stages
 Each stage approximately equal in duration
 Each stage performs a clearly defined task that can
be done independently
 Use pipelining concepts to execute iterations in

Sofware Process 3
Time Boxed Iterations
 General iterative
development – fix the
functionality for each
iteration, then plan and
execute it
 In time boxed
iterations – fix the
duration of iteration
and adjust the
functionality to fit in
◦ Completion time is fixed,
the functionality to be
delivered is flexible

Sofware Process 4
Example
 An iteration with three stages – Analyis,
Build, Deploy
◦ These stages are appx. equal in many situations
◦ Can adjust durations by determining the
boundaries
◦ Can adjust duration by adjusting the team size
for each stage
 There is a dedicated team for each stage
(A, B, and D)
 When one stage team finishes, it hands
over the project to the next team -
Pipelining

Sofware Process 5
Timeboxing Execution
Software
Requirements Build Deploy
TB1
TB2
TB2
TB3
TB4

Sofware Process 6
Pipelined Execution
 AT starts executing it-1
 AT finishes, hands over it-1 to BT,
starts executing it-2
 AT finishes it-2, hands over to BT; BT
finishes it-1, hands over to DT; AT
starts it-3, BT starts it-2 (and DT, it-1)
 …

Sofware Process 7
Time boxed Iteration usage
 This itself very useful in many situations
 Has predictable delivery times
 Overall product release and marketing can be
better planned
 Makes time a non-negotiable parameter and
helps focus attention on schedule
 Prevents requirements bloating
 Overall dev. time is still unchanged

Sofware Process 8
Timeboxing execution
 First iteration finishes at time T
 Second finishes at T+T/3; third at T+2 T/3,
and so on
 In steady state, delivery every T/3 time
 If T is 3 weeks, first delivery after 3 wks, 2nd
after 4 wks, 3rd after 5 wks,…
 In linear execution, delivery times will be 3
wks, 6 wks, 9 wks,…

Sofware Process 9
Timeboxing execution
 Duration of each iteration still the same
 Total work done in a time box is also the same
 Productivity of a time box is same
 Yet, average cycle time or delivery time has
reduced to a third

Sofware Process 10
Team Size
 In linear execution of iterations, the same
team performs all stages
 If each stage has a team of S, in linear
execution the team size is S
 In pipelined execution, the team size is
three times (one for each stage)
 I.e. the total team size in time boxing is
larger; and this reduces cycle time

Sofware Process 11
Work Allocation of Teams
Requirements
Team
Requirements
Analysis for TB1
Requirements
Analysis for TB3
Requirements
Analysis for TB2
Requirements
Analysis for TB4
Build Team
Deployment
Team
Build for TB1 Build for TB2 Build for TB3
Deployment for TB1Deployment for TB2
Build for TB4
Deployment for TB3
Requirements
Team
Requirements
Analysis for TB1
Requirements
Analysis for TB3
Requirements
Analysis for TB2
Requirements
Analysis for TB4
Build Team
Deployment
Team
Build for TB1 Build for TB2 Build for TB3
Deployment for TB1Deployment for TB2
Build for TB4
Deployment for TB3

Sofware Process 12
Team Size
 Merely by increasing the team size we
cannot reduce cycle time - Brook’s law
 Time boxing allows structured way to add
manpower to reduce cycle time
 Note that we cannot change the time of an
iteration – Brook’s law still holds
 Work allocation different to allow larger
team to function properly

Sofware Process 13
Timeboxing
 Advantages: Shortened delivery times,
iterative, distributed execution
 Disadvantages: Larger teams, proj. mgmt
is harder, high synchronization needed, CM
is harder
 Applicability: When short delivery times v.
imp.; architecture is stable; flexibility in
feature grouping

Agile Models
 Iterative + incremental process
 Focus -> flexibility in producing software quickly and
capably
 Agile:
◦ break the product into small incremental builds.
◦ these builds are provided in iterations.
◦ each iteration typically lasts from about one to three
weeks
◦ At the end of the iteration, a working product is
displayed to the customer and important
stakeholders

 Following are the Agile manifesto principles:
◦ Value individuals and interactions over process
and tools
◦ Prefer to invest time in producing working
software rather than in producing comprehensive
documentation
◦ Focus on continuous customer collaboration to
get proper product requirements.
◦ Responding to change rather than on creating a
plan and then following it

Agility Principles
1) Highest priority is to satisfy the customer through early
and continuous delivery of valuable software.
2) Welcome changing requirements, even late in
development.
3) Deliver working software frequently, from a couple of
weeks to months
4) Business people and developers must work together
daily throughout the project.
5) Build projects around motivated individuals. Give them
the environment and support they need, and trust
them to get the job done.
6) The most efficient and effective method of conveying
information to and within a development team is face-
to-face conversation.

7) Working software is the primary measure of
progress.
8) Agile processes promote sustainable development.
The sponsors, developers, and users should be
able to maintain a constant pace indefinitely.
9) Continuous attention to technical excellence and
good design enhances agility
10) Simplicity–the art of maximizing the amount of
work not done–is essential.
11) The best architectures, requirements, and designs
emerge from self-organizing teams
12) At regular intervals, the team reflects on how to
become more effective, then tunes and adjusts its
behavior accordingly.

THE POLITICS OF AGILE DEVELOPMENT
 Jim Highsmith states “Traditional methodologists
are a bunch of stick-in-the-muds who’d rather
produce flawless documentation than a working
system that meets business needs”.
 As a counterpart he states “Light-weight, ‘agile’
methodologists are a bunch of glorified hackers
who are going to be in for a heck of a surprise
when they try to scale up their toys into enterprise-
wide software”
 Customer Interaction (backbone), Open
communication with minimum documentation -
Agile methodology

Agile Vs Traditional SDLC
Models
 Agile is based on the adaptive software development
methods
 Traditional SDLC models like the waterfall model is based on
a predictive approach.
 Predictive methods depend on the requirement analysis
and planning done in the beginning of cycle with strict
change management
 In Adaptive approach, feature driven development and the
team adapts to the changing product requirements
dynamically.

Human Factors
Some of fundamental characteristics and skills that will facilitate the
implementation of agile practices at its core.
1) Competency: The staff should be competent in knowing
software and the technologies
2) Collaboration:
◦ Ability to work in a team
◦ Cooperate among themselves involved in project
3) Focus:
◦ Common goal:
“Deliver customer an increment of working software in
agreed time”
◦ Continuous adaptations, always improving the process as
needed.

4) Decision making:
◦ Development team should have freedom, in technical
matters and project.
◦ Company can suggest good practice, but in the end is
the staff (self-organizing) which will adopt the methods or
processes that you think best.
◦ Development team must learn to deal with conflicting
situations, ambiguity and frequent changes, which will
facilitate the continual improvement process.

4) Trust and respect:
◦ Team must be consistent
◦ Team demonstrate trust and respect needed to make a
strong team.
◦ Main Objective: Make the team strong enough that the
whole is greater than the sum of its parts.
5) Self organization:
◦ Self organized Team to perform the work.
◦ Continuous evaluation for process improvement
◦ Self organization has technical benefits : Team selects
how much work believed to be capable of performing the
iteration and commits.

There Is Nothing Noble In Being Superior
To Your Fellow Man; True Nobility Is Being
Superior To Your Former Self.

Some Agile Methods
 Rapid Application Development (RAD)
 Extreme Programming (XP)
 Rational Unify Process (RUP)
 Adaptive Software Development (ASD)
 Feature Driven Development (FDD)
 Crystal Clear
 Incremental SDLC
 Scrum
 Dynamic Software Development Method (DSDM)

Sofware Process 26
EXTREME PROGRAMMING (XP)
 eXtreme Programming (XP) is one of the most popular
 An XP project starts with user stories, which are short description
of user needs
◦ Details are not included
◦ User stories written on a separate card
 Team estimates time to implement a user story – Rough Estimates
 Release planning is done
◦ Defines which stories are to be built in which release, & release
dates
◦ Encourages Frequent and small releases
◦ Acceptance tests built from user stories; used to test before
release
◦ Bugs found in AT are fixed in next release

Sofware Process 27
XP – Overall Process

Sofware Process 28
Overall Process
 Development done in iterations of a few
weeks each
◦ Iteration starts with planning, in which stories to
be implemented are selected – high risk high
value are chosen first
◦ Details of stories obtained during the
development are implemented
◦ Failed AT of previous iteration are also fixed

Sofware Process 29
XP - Summary
 Well suited for situations where volume and
pace of requirements is high
 Customer is willing to engage heavily with
the team
 The team is collocated and is not too large
(less than 20 or so)
 Requires strong capability in team
members

 Prototyping + Iterative development with no specific
planning
 Focus:
◦ Gather customer requirements
◦ Early testing of the prototypes by the customer using iterative
concept
◦ Reuse of the existing prototypes (components)
◦ Continuous integration and rapid delivery
 No detailed preplanning - easier to incorporate the changes
 Team comprises of developers, domain experts, customer
representatives and other IT resources
Rapid Application Model (RAD)

RAD Phases
 Requirements planning phase
◦ Structured discussion of business problems
◦ Does System planning and analysis
◦ Users, managers, and IT staff members discuss and
agree on business needs, project scope, constraints,
and system requirements.
◦ It ends when the team agrees on the key issues and
obtains management authorization to continue

 User description phase
◦ automated tools capture information from users
◦ Users interact with systems analysts and develop models
and prototypes that represent all system processes,
inputs, and outputs.
◦ Use tools & techniques to translate user needs into
working models.
◦ Continuous interactive process to understand, modify,
and eventually approve a working model.

 Construction phase
◦ Uses productivity tools, such as code generators,
screen generators, etc. inside a time-box. (“Do
until done”)
◦ Users continue to participate and suggest
changes or improvements
◦ Tasks are programming and application
development, coding, unit-integration, and
system testing.

 Cutover phase
◦ System installation, user acceptance testing and
user training
◦ Resembles the final tasks
◦ New system is built, delivered, and placed in
operation
◦ Tasks are data conversion, full-scale testing,
system changeover, user training.

RAD Strengths
 Changing requirements can be accommodated.
 Progress can be measured.
 Iteration time can be short with use of powerful
RAD tools.
 Productivity with fewer people in a short time.
 Reduced development time.
 Increases reusability of components.
 Quick initial reviews occur.
 Encourages customer feedback.
 Integration from very beginning solves a lot of
integration issues.

RAD Weaknesses
 Dependency on technically strong team members for
identifying business requirements.
 Only system that can be modularized can be built using RAD.
 Requires highly skilled developers/designers.
 High dependency on modeling skills.
 Inapplicable to cheaper projects as cost of modeling and
automated code generation is very high.
 Management complexity is more.
 Suitable for systems that are component based and scalable.
 Requires user involvement throughout the life cycle.
 Suitable for project requiring shorter development times.

When to use RAD
 Reasonably well-known requirements
 User involved throughout the life cycle
 Project can be time-boxed
 Functionality delivered in increments
 High performance not required
 Low technical risks
 System can be modularized

Sofware Process 39
Rational Unified
Process(RUP)
 Iterative model
 Software development is divided into cycles, each
cycle delivering a fully working system
 Each cycle executed as separate project
 Execution of a cycle is broken into four consecutive
phases, each phase ending with a milestone
achievement

Sofware Process 40
Phases in a Project
◦ Inception phase: ends with Lifecycle Objectives
milestone; vision and high level capability of
system defined
◦ Elaboration phase: Lifecycle architecture
milestone; most requirements defined and
architecture designed
◦ Construction phase: Initial operational
capability milestone
◦ Transition phase: Product release; transition
product from development to production

Sofware Process 41
Phases and Milestones

Sofware Process 42
Execution of phases
 Each phase itself can be done in multiple
iterations, each iteration having an
external/internal customer
 Generally construction has multiple
iterations; elaboration can also be
meaningfully done in multiple iterations

Advantages of Agile Model
 Realistic approach
 Promotes teamwork and cross training
 Flexibility to developers
 Functionality can be 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
 Enables concurrent development and delivery within an
overall planned context.
 Little or no planning required
 Easy to manage

Disadvantages of Agile Model
 Not suitable for handling complex dependencies.
 More risk of sustainability, maintainability and extensibility.
 Strict delivery management
 Depends heavily on customer interaction, so if customer is
not clear, team can be driven in the wrong direction.
 High individual dependency, since there is minimum
documentation generated.
 Transfer of technology to new team members may be quite
challenging due to lack of documentation.

Sofware Process 45
Summary
 Process is a means to achieve project objectives of high
QP
 Process models define generic process, which can form
basis of project process
 Process typically has stages, each stage focusing on an
identifiable task
 Many models for development process have been
proposed
 Model should be selected based on the nature of the
problem

Chapter 2 Time boxing & agile models

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Chapter 2 Time boxing & agile models

Similar to Chapter 2 Time boxing & agile models (20)

Recently uploaded

Recently uploaded (20)