Unleashed

Contents
 Rationale
 Existing categories
 Why
 About Agile
 Agile Mothodologies
 The chosen one
 What’s next

Categories of Dev. methods
 Code and Fix
 No process at all
 Development is chaotic and unplanned
 Serial
 Software processes are well defined and detailed
 Developers are expected to follow in serial manner
 Waterfall Process / Big design up front (BDUF)
 Quarter length releases
 Iterative
 Software processes are well defined and detailed
 Developers are expected to follow in an iterative manner
 Short release cycles – weeks / months
 Agile
 Software processes are defined at high-level
 People oriented approach
 Enables people to respond effectively to change
 Short release cycles – weeks / moths

Why…
 Who are we
 Small team of programmers without Designers, Tester or full time project
manager
 In most cases the requirements are general and not fully defined
 Why not Serial or Iterative methods
 Often development of small IT software for which full scale design is too time
consuming
 Usually short TTM (Time to market) needed
 Why and when yes Code and Fix
 For the really small project when first and in short period of time a prototype
needed as a POC (Proof of Concept)
 When only one developer involved
 Why and when yes Agile
 High-level design is needed to begin developing
 When several team-members involved in development
 First prototype release version can be quickly presented to the client
 Adaptive to changes in clients requirements as the projects developes

About Agile – WTF?
 "Agile Development" is an umbrella term for several iterative and
incremental software development methodologies. The most popular agile
methodologies include
 Extreme Programming (XP)
 Scrum
 Crystal Clear
 Dynamic Systems Development Method (DSDM)
 Lean Development
 Feature-Driven Development (FDD)
 While each of the agile methods is unique in its specific approach, they all
share a common vision and core value (Agile Manifesto)
 They all fundamentally incorporate
 Iteration and continuous feedback
 Lightweight
 Rapid and flexible respond to change
 All focus on empowering people to collaborate and make decisions together
quickly and effectively

About Agile – WTF?

About Agile - Characteristics
 Agile methods break tasks into small increments with minimal planning
 Iterations are short time frames that typically last from one to four weeks
 Each iteration involves a team working through a full software
development cycle
 Multiple iterations might be required to release a product or new features.
 Team members decide individually how to meet an iteration's
requirements
 Agile methods emphasize face-to-face communication over written
documents
 Each agile team will contain a customer representative which
available for developers to answer mid-iteration questions
 Most agile implementations use a routine and formal daily face-to-face
communication among team members (Stand-ups)
 TDD - Test Driven Development

Agile Methodologies - XP
 Intended to improve software quality and responsiveness to
changing customer requirements
 Frequent "releases" in short development cycles
 Improve productivity and introduce checkpoints where new
customer requirements can be adopted
 Elements of XP:
 Programming in pairs
 Extensive code review
 Unit testing
 Avoiding programming of features until they are needed
 Flat management structure
 Simplicity and clarity in code
 Expecting changes in customer requirements
 Frequent communication with the customer and among
programmers

Extreme Programming Model

Agile Methodologies -
Scrum A product owner creates a prioritized wish list called a product
backlog.
 During sprint planning, the team pulls a small chunk from the top of
that wishlist, a sprint backlog, and decides how to implement those
pieces.
 The team has a certain amount of time, a sprint, to complete its work -
usually two to four weeks - but meets each day to assess its progress
(daily scrum).
 Along the way, the ScrumMaster keeps the team focused on its goal.
 At the end of the sprint, the work should be potentially shippable, as in
ready to hand to a customer, put on a store shelf, or show to a stakeholder.
 The sprint ends with a sprint review and retrospective.
 As the next sprint begins, the team chooses another chunk of the product
backlog and begins working again.

Scrum cycle

Agile Methodologies –
Crystal Clear
 One of the most lightweight, adaptable approaches to
software development
 Actually a family of methodologies (Crystal Clear, Crystal
Yellow, Crystal Orange, etc.) whose unique characteristics
are driven by several factors such as team size, system
criticality, and project priorities
 addresses the realization that each project may require a
slightly tailored set of policies, practices, and processes in
order to meet the project’s unique characteristics.
 Several of the key tenets of Crystal include teamwork,
communication, and simplicity, as well as reflection to
frequently adjust and improve the process
Alistair Cockburn

Agile Methodologies - DSDM
 Dynamic Systems Development Method
 Iterative and incremental approach that embraces
principles of Agile development
 Fixes cost, quality and time
 Uses MoSCoW prioritisation (musts, shoulds, coulds and
won't haves) to meet the stated time constraint

DSDM - Model

Agile Methodologies –
Lean Development (Kanban)
 The term "kanban" is Japanese (看板), derived from roots which literally
translate as "visual board".
 Borrowed from the Toyota Production System, where it designates a system to
control the inventory levels of various parts. It is analogous to (and in fact
inspired by) cards placed behind products on supermarket shelves to signal
"out of stock" items and trigger a resupply "just in time".
 The Toyota system affords a precise accounting of inventory or "work in
process", and strives for a reduction of inventory levels, considered wasteful
and harmful to performance.
 Approach to continuous improvement which relies on visualizing the current
system of work scheduling, managing "flow" as the primary measure of
performance, and whole-system optimization - as a process improvement
approach, it does not prescribe any particular practices.
 can be considered first for efforts involving maintenance or ongoing evolution
(In particular of more than one products.
 The boards must have WIP (Work in Progress) limits

Kanban Board Example

Agile Methodologies - FDD
 Develop overall model
 High-level walkthrough of the scope of the system and its context
 Then detailed domain walkthroughs for each modeling area
 Then merge into an overall model
 Build feature list
 Feature list derived from the model above
 Plan by feature
 Produce development plan by deviding feature sets to chief
programmers
 Design by feature
 Design package for each feature (Description, referenced reqs.,
sequence diagrams, design alternatives, object model, task list)
 Hold design inspections
 Build by feature
 Code for the designs above
 After unit-tests and code inspections the completed feature is to
be promoted to the main build

What’s next?

Comparing Methodologies

Comparing Methodologies

Comparing Methodologies
StrengthsWeaknesses
XP
•Strong technical practices.
•Customer ownership of feature priority, developer ownership of
estimates.
•Frequent feedback opportunities.
•Most widely known and adopted approach, at least in the U.S.
•Requires onsite customer.
•Documentation primarily through verbal
communication and code. For some teams these are
the only artifacts created, others create minimal design
and user documentation.
•Difficult for new adopters to determine how to
accommodate architectural and design concerns.
Scrum
•Complements existing practices.
•Self organizing teams and feedback.
•Customer participation and steering.
•Priorities based on business value.
•Only approach here that has a certification process.
•Only provides project management support, other
disciplines are out of scope.
•Does not specify technical practices.
•Can take some time to get the business to provide
unique priorities for each requirement.
Lean
•Complements existing practices.
•Focuses on project ROI.
•Eliminates all project waste.
•Cross-functional teams.
•Does not specify technical practices.
•Requires constant gathering of metrics which may be
difficult for some environments to accommodate.
•Theory of Constraints can be a complex and difficult
aspect to adopt.
FDD
•Supports multiple teams working in parallel.
•All aspects of a project tracked by feature.
•Design by feature and build by feature aspects are easy to
understand and adopt.
•Scales to large teams or projects well.
•Promotes individual code ownership as opposed to
shared/team ownership.
•Iterations are not as well defined by the process as
other Agile methodologies.
•The model-centric aspects can have huge impacts
when working on existing systems that have no
models.

Comparing Methodologies
StrengthsWeaknesses
AUP
•Robust methodology with many artifacts and disciplines to
choose from.
•Scales up very well.
•Documentation helps communicate in distributed environments.
•Priorities set based on highest risk. Risk can be a business or
technical risk.
•Higher levels of ceremony may be a hindrance in
smaller projects.
•Minimal attention to team dynamics.
•Documentation is much more formal than most
approaches mentioned here.
Crystal
•Family of methodologies designed to scale by project size and
criticality.
•Only methodology that specifically accounts for life critical
projects.
•As project size grows, cross-functional teams are utilized to
ensure consistency.
•The "human" component has been considered for every aspect
of the project support structure.
•An emphasis on testing is so strong that at least one tester is
expected to be on each project team.
•Expects all team members to be co-located. May not
work well for distributed teams.
•Adjustments are required from one project
size/structure to another in order to follow the
prescribed flavor of Crystal for that project
size/criticality.
•Moving from one flavor of Crystal to another in mid
project doesn't work, as Crystal was not designed to
be upward or downward compatible.
DSDM
•An emphasis on testing is so strong that at least one tester is
expected to be on each project team.
•Designed from the ground up by business people, so business
value is identified and expected to be the highest priority
deliverable.
•Has specific approach to determining how important each
requirement is to an iteration.
•Sets stakeholder expectations from the start of the project that
not all requirements will make it into the final deliverable.
•Probably the most heavyweight project compared in
this survey.
•Expects continuous user involvement.
•Defines several artifacts and work products for each
phase of the project; heavier documentation.
•Access to material is controlled by a Consortium, and
fees may be charged just to access the reference
material.

Scrum vs XP
 Scrum and Extreme Programming (XP) are definitely very
aligned:
 Short iterations
 Customer involvement
 Daily stand-up meetings
 The main conceptual differences
 scrum emphasizes the management side of a project and does not
define a detail engineering practice. XP specify the software
engineering practices such as test-driven development, refactoring,
pair programming, simple design, etc.
 Scrum does not allow requirements changes during the sprint
whilst XP supports any change at any stage.
 Most recommendations are to start with Scrum and as the teem
advances and gains agile experience – adopt practices from XP
 So…….

Scrum - Defined
 Roles
 Product owner: responsible for the business value of the project
 Scrum Master: ensures that the team is functional and productive
 Team: self-organizes to get the work done
 Artifacts
 Product backlog: prioritized list of desired project outcomes/features
 Sprint backlog: set of work from the product backlog that the team agrees to
complete in a sprint, broken into tasks
 Burndown chart: at-a-glance look at the work remaining (can have two charts: one
for the sprint and one for the overall project)
 Ceremonies
 Sprint planning: the team meets with the product owner to choose a set of work to
deliver during a sprint
 Daily scrum: the team meets each day to share struggles and progress (15 minutes)
 Sprint reviews: the team demonstrates to the product owner what it has completed
during the sprint
 Sprint retrospectives: the team looks for ways to improve the product and the
process.

Scrum – Order of things
Plan the project
 Build the project backlog
 Technical and learning tasks are also
part of the backlog (i.e explore
.net 4 cababilities, create the
development environment …)
 Determine team velocity – How many story points can be completed in one
iteration (sprint)
 Establish the release plan –
 Group user stories in groups that provide a releasable version
 Determine in which sprints those user stories will be completed
 Prepare for the first sprint – prepare the product backlog
 Break the user stories down into smaller stories
 Provide details about the user stories that the team will need to break the
stories down into tasks.
Backlog Example2

Scrum – Order of things
Plan a Sprint
 Sprint planning meeting - Team commits to completing the chosen
items from the backlog
 Choose user stories to be implemented in the sprint
 Tasks
 Identify the tasks
 Evaluate each task (hours)

Scrum – Order of things
Run a Sprint
 Complete selected user stories
 The sprint is of constant length – 2 to 4
weeks, the length of the sprint cannot be
changed
 Track sprint progress – burndown report
 Finish the sprint
 Make sure user stories completed
 After the customer review,
the team will hold a retrospective meeting to
improve the process

Scrum – Order of things
Track the project
 As sprints are advancing, customers develop a better
understanding of their remaining needs, and changes
in the backlog will happen.
 Prepare for the next sprint
 Update the user stories and their priorities as customers'
needs change.
 Break down user stories that are likely to be
implemented in the next sprint.

Scrum – Order of things
Track the project
 Track Release Progress
 As the project proceeds from sprint to sprint, your team
will track the overall progress toward the next release
 Finish the Release
 Hold review retrospective meetings with the customer
to examine the process

So what’s in our case
 Mercury Rod
 User stories exist
 Build the backlog
 Project planning meeting scheduled next week (Backlog
review, understand priorities, Estimate cost)
 Sprint planning meeting the on the next 2 days (Build
sprint backlog – including tasks)
 Will use visual studio ALM to manage the project
 DOCUMENT YOUT CODE

The END…..

Ponders
 Architectural aspects – in the backlog?
 Backlog examples
 Prepare the working environment
 Continuous integration
 Acceptance tests – Gute
 Multiple tasks management
 Code Reviews