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.
Agile is just a system of values...
There are many ways to implement it in a process.
Why not waterfall?
Requirements Gathering
Analysis / Design
Development
Testing
Bug Fix
Deploy
The Problem is Feedback!
Waterfall Projects
Have...
BIG UPFRONT
DESIGN
Let's look at an example:
Questions:
- Did documentation get updated?
- What condition is the code after the change?
- Is the solution good, or merely "acceptable"?
- How much did the project run over time?
- Over budget?
What is Agile?
Lets Talk Methodologies...
Scrum
- Highly prescriptive - tells you what to do.
- Disruptive. Organization must change from top down.
- Planning and estimation for determining project progress.
- Clearly defined roles - ScrumMaster, Product Owner, Team.
- 15 minute stand up meetings or "Scrum meetings."
- Artificially time boxed into "sprints."
- Talks more about process than standards.
XP - Extreme Programming
- Highly prescriptive - very strict rules.
- Disruptive. Developers must change. Paired programming is required. Test Driven Development is required. Very strict rules.
- Principles and best practices are part of the process.
- Excellent set of development practices.
- Can be very difficult to implement.
- Doesn't control work in progress.
Kanban
- Not prescriptive - only requirement is a Kanban board.
- Doesn't say anything about best practices.
- Doesn't say anything about team structure.
- Eliminates waste from development project.
- Focused on reducing work in progress to increase effectiveness.
- Lower impact to existing teams.
Iteration 4
Iteration 3
Iteration 1
Iteration 2
Taking it one step further
Analysis / Design
Requirements Gathering
If shortening the feedback cycle is good...
What if we shorten it more?
What if we make it continuous?
Development
Deploy
Testing
Bug Fix
Time
Waterfall
What is happening here?
- We have made the feedback loop smaller.
- We have accounted for change in our process, instead of trying to fight change... Change is inevitable.
- We are going to go through the whole SDLC process every 2 weeks, or so.
- We have increased the accuracy of our planning, because we can accurately estimate how much of the system is implemented.
There isn't any!
Better hit the brakes!
Think about driving a car
Uh oh!
Too late
The brakes take
1 minute to respond
to your push
But, you can only see
the road once every
10 minutes
By the time you see the rock in the road
It's too late!
Iteration 1
Iteration 4
Iteration 2
Iteration 3
12 months
3 months
1 month
24 months
(Redesigning an already
built system can take as
long as initially building the
system)
What is happening here?
- We are blurring the lines between the "phases" of software development in order to make our feedback loop tighter.
- Testing is happening as close to development as possible in order to catch problems as early as possible.
- We are making the customer or customer represenative an active part of the development process in order to reduce miscommunication and better deliver what the customer wants.
Engineering teams begin building
the widget making machine.
Requirements are analyzed.
Design of the new widget making
machine is written in a spec.
Engineering teams "complete"
brand new widget making machine.
Test widgets are produced.
At the widget factory, we get
the requirements for building
and new kind of widget making
machine.
Customer looks at test widgets and
realizes that is not what they want
at all.
Machine has already been built
no time to redesign it, only option
is duct tape and "super engineer".
Repeat until customer is happy
Or product provides enough value
to release.
Big picture of creating
a new kind of widget making
machine is approved.
Limiting WIP, Kanban board
Users work with team to define
high level goals of the new
widget making machine.
High level goals are broken
into stories which development
teams can build
Development team iteratively develops
a user story, getting details from
working directly with customers.
Working prototypes of functionality are demonstrated to the customer as it
is built.
Feedback is used to improve product
each cycle.
Some process
Development principles