Unleashed

Contents
Rationale
Existing categories
Why
About Agile
Agile Mothodologies
The chosen one
Whats 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 Alistair Cockburn

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 projects 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
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
Whats next?
Comparing Methodologies
Comparing Methodologies
 Comparing Methodologies
Weaknesses Strengths
Requires onsite customer. Strong technical practices.
Documentation primarily through verbal Customer ownership of feature priority, developer ownership of
communication and code. For some teams these are estimates.
the only artifacts created, others create minimal design Frequent feedback opportunities. XP
and user documentation. Most widely known and adopted approach, at least in the U.S.
Difficult for new adopters to determine how to
accommodate architectural and design concerns.
Only provides project management support, other Complements existing practices.
disciplines are out of scope. Self organizing teams and feedback.
Does not specify technical practices. Customer participation and steering. Scrum
Can take some time to get the business to provide Priorities based on business value.
unique priorities for each requirement. Only approach here that has a certification process.
Does not specify technical practices. Complements existing practices.
Requires constant gathering of metrics which may be Focuses on project ROI.
difficult for some environments to accommodate. Eliminates all project waste. Lean
Theory of Constraints can be a complex and difficult Cross-functional teams.
aspect to adopt.
Promotes individual code ownership as opposed to Supports multiple teams working in parallel.
shared/team ownership. All aspects of a project tracked by feature.
Iterations are not as well defined by the process as Design by feature and build by feature aspects are easy to
other Agile methodologies. understand and adopt. FDD
The model-centric aspects can have huge impacts Scales to large teams or projects well.
when working on existing systems that have no
models.
 Comparing Methodologies
Weaknesses Strengths
Higher levels of ceremony may be a hindrance in Robust methodology with many artifacts and disciplines to
smaller projects. choose from.
Minimal attention to team dynamics. Scales up very well.
AUP
Documentation is much more formal than most Documentation helps communicate in distributed environments.
approaches mentioned here. Priorities set based on highest risk. Risk can be a business or
technical risk.
Expects all team members to be co-located. May not Family of methodologies designed to scale by project size and
work well for distributed teams. criticality.
Adjustments are required from one project Only methodology that specifically accounts for life critical
size/structure to another in order to follow the projects.
prescribed flavor of Crystal for that project As project size grows, cross-functional teams are utilized to
Crystal
size/criticality. ensure consistency.
Moving from one flavor of Crystal to another in mid The "human" component has been considered for every aspect
project doesn't work, as Crystal was not designed to of the project support structure.
be upward or downward compatible. An emphasis on testing is so strong that at least one tester is
expected to be on each project team.
Probably the most heavyweight project compared in An emphasis on testing is so strong that at least one tester is
this survey. expected to be on each project team.
Expects continuous user involvement. Designed from the ground up by business people, so business
Defines several artifacts and work products for each value is identified and expected to be the highest priority
phase of the project; heavier documentation. deliverable. DSDM
Access to material is controlled by a Consortium, and Has specific approach to determining how important each
fees may be charged just to access the reference requirement is to an iteration.
material. Sets stakeholder expectations from the start of the project that
not all requirements will make it into the final deliverable.
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 )

Backlog Example2

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