Kanban / Lean Scrum XP DSDM Crystal FDD: Agile One Pager

Download as pdf or txt
Download as pdf or txt
You are on page 1of 2

Agile One Pager

Principle behind
Kanban / Lean Scrum XP DSDM Crystal FDD
the Agile Manifesto

Our highest priority is to satisfy the  Visualization of top  Value based  Customers and  Build customer  Early Victory  Client-Value based
customer through early and priority items prioritization Developers work feedback into each  Walking skeleton features
continuous delivery of valuable  Pull system of work  Shippable Software together to plan iteration to converge on  Short ramp-up for
 Frequent Customer
software. assignment after each Sprint releases an effective business modeling
feedback
solution
 Sprint Review Meetings

Welcome changing requirements,  Business people can  Product Backlog  Iteration planning  MoSCoW  Re-calibration of the  Domain based model
even late in development. Agile change and re-prioritize grooming release plan fosters change
processes harness change for the work not yet started at  Re-prioritization after  Frequent User  Short cycles with
customer's competitive advantage. any time each sprint feedback complete features allow
for frequent change

Deliver working software  Work released on  Sprints (iterations)  Iterations  Develop iteratively in  Iterations  Increments (per
frequently, from a couple of weeks demand Timeboxes feature) <= 2 weeks
to a couple of months, with a  Iterations (1 or more
preference for the shorter complete features
timescale.

Business people and developers  Highly collaborative  PO as VOC  Customer is part of the  Involve the right  Easy access to expert  Client interaction during
must work  PO readily available to Team stakeholders, at the users processes #1 and #2
together daily throughout the team on a daily base right time, throughout  Frequent feedback from  Frequent demos with
project. the project end users customer feedback

Build projects around motivated  SM is only facilitator  Open work space  Process Miniature  Domain Experts
individuals. Give them the  Self-organizing teams  Pairs evolve as needed makes sure team  Class ownership
environment and support they members understand However, there is:
 Demo/Acceptance after
need and trust them to get the job the process well
each sprint  Team leadership
done.  Team decides
 Assignment of team
improvement / changes
membership based
on expertise

The most efficient and effective  Colocated teams  Colocated teams  Colocated teams  Colocated teams for  Multiple Small teams
method of  Daily Stand-Up  Daily Stand-Up  Daily Stand-Up Crystal Clear  Joint design,
conveying information to and Meetings Meetings Meetings  Osmotic inspections etc.
within a Development Team is Communication  However, a lot of
face-to-face conversation.
 Daily Stand-Up information sharing via
Meetings CMS

© 2014 SCRUMstudy.com
Agile One Pager

Principle behind
Kanban / Lean Scrum XP DSDM Crystal FDD
the Agile Manifesto

Working software is the primary  WIP limit  Working Software at the  No technical debt  Deliver “Good enough”  Walking Skeleton  Inspections
measure of progress. end of each Sprint  TDD early instead of  Automated Tests  (Unit) tests
“Perfect too late”
 Egoless software  Frequent Integration

Agile processes promote  No fix release or  Velocity  Iteration planning  -Blitz planning  Clearly defined
sustainable development. The delivery dates  Done criteria (Only  Sustainable, entry/criteria per
sponsors, developers, and users  Limit of WIP forces complete/done work predictable pace process
should be able to maintain a completion or work counts)  only completed work
constant pace indefinitely. packages counts

Continuous attention to technical  Refactoring  Continuous Integration,  Incremental Re-  Domain Object Model
excellence  Continuous Integration refactoring & building architecture as base
and good design enhances agility. often  Frequent updates

Simplicity--the art of maximizing  Small user stories  Small user stories  Small features
the amount of work not done--is  Continuous re-  Continuous re-  Focus on Client value
essential. evaluation and re- evaluation and re-  Good upfront design /
prioritization prioritization model

The best architectures,  No team leader  Pair Programming  Members of the team  Side by side  Team consensus for
requirements, and designs emerge  Team commits  Team coding standards empowered to make programming Domain Object Model
from self-organizing teams. decisions on behalf of  Small teams foster co-
 Team members select
those they represent operation across
tasks
without waiting for expertise boundaries
higher-level approval.

At regular intervals, the team  Sprint Retrospective  Sprint Retrospective  Facilitated workshops  Reflection Workshop  The 6 milestones per
reflects on how Meetings at the end of meetings at each feature allow for
to become more effective, and each sprint iteration end. Improving frequent checks for
then tunes and adjusts its the process is part of improvements
behaviour accordingly. the development.  However, no reflections
are prescribed

© 2014 SCRUMstudy.com

You might also like