This document introduces agile software development using Scrum as an alternative to classical software development methodologies. It describes how classical approaches aim to fully define requirements upfront but often fail due to changing needs, while agile development embraces changing requirements by building software incrementally in iterations. The key aspects of Scrum are discussed, including product backlogs, daily scrums, sprints, and using visual tools like boards and burn down charts to track progress. Adopting agile practices allows teams to adapt to changes and learn from mistakes rather than trying to plan for all eventualities in advance.

1. Agile Software Development
aka
How to build a Death Star without being
squished by Darth Vader
Reinhart De Lille
R&D Manager

2. Content
• Something short about Adifo
• Prelude (to pain)
• Classical software development
• Going Agile with Scrum

3. Adifo in figures
•
•
•
•
75 employees, 700 customers
Turnover: + 8 million EUR
Export (world-wide): 80%
Customers in more than 60 countries
Turnover Adifo 2011
Belgium
NL, D, Fr
Rest Europe
Rest world

4. Products

5. Prelude
• Software development is more than coding
• And always involves a lot of people
It is a team effort
To build a software product
That effectively solves a customer’s problem
And gives value to his business

6. Prelude
Customers :
Invent requirements 
Have a real world problem and make your
computer deal with it
Product Managers / consultants :
Get requirements from customer and market
Make requirements consistent
Analysts
Analyse requirements
design UI
Architects / Developers
Design solution
Code the requirements
Write unit tests
Testers / System engineers / etc ...

7. Prelude
The whispering paradox

8. A traditional development problem

9. A real world example
• Failure and a typical customer response
– http://www.youtube.com/watch?feature=endscre
en&v=Q5BjbUiCvFQ&NR=1

10. How to deal with this?
• Introducing SW development methodologies
– And we call it Project Management !
• 2 approaches
– Classical : try to make sure we know everything in
advance !
– Agile : build the software incrementally and evolve
with the customer specs.

11. Classical
Try to make sure we know everything in advance!
• Method
–
–
–
–
–
Interview customer till you know last details
Analyse and estimate it from top to bottom
Fix the budget together with customer
And then build the bugger
Very hierarchical
• Examples
– Waterfall / CODIS / Rational Unified Process
• Typically used
– Large engineering projects, NASA, government projects, etc ...
– Or building a death star ...

12. Classical
Reality check ! There is a dark side to every project!
Managing expectations
 What does the customer need?
Scope creep
 I want more whistles & bells !
... And now you do what they told ya !
 no responsibilities ...
Very very expensive? Out of budget and
out of time?
The world changes faster than the
software !

13. Classical
• How to deal with such crisis ?
– http://www.youtube.com/watch?v=0Cl7cxopNjg&feat
ure=related
– http://www.youtube.com/watch?v=Z6B92nPs8lg

14. Going Agile
• Take the project management challenges for
reality !
• Embrace the ever-changing nature of
requirements
• Take responsibility for what you can manage
• And deal with issues as they come

15. Going Agile
Aka Incremental software development
• Characteristics
–
–
–
–
Don’t do a big bang, but
Do iterations of ‘small bangs’
Be deliverable after each iteration
In a self-organising, cross functional team
• Many methodologies
–
–
–
–
Extreme programming
Scrum
Kanban
Feature driven Development

16. Going Agile
• Some very simple concepts
–
–
–
–
Product Backlog
Daily Scrum
Scrumboard
Sprint Burndown
• Self managing Team
• Keep it visual !
• Keep learning !

17. Every 24
hours
Scrum 15 minute daily meeting
Daily Scrum
Sprint Backlog
Feature(s)
assigned
to sprint
Backlog
items
expanded
by team
Sprint
(30 days)
Teams member respond to basics:
1)
What did you do since last
Scrum Meeting?
2)
Do you have any obstacles?
3)
What will you do before
next meeting?
New functionality is
demonstrated at
end of sprint
Product Backlog
Prioritized product features desired by the customer
SCRUM
18

18. The Product Backlog Iceberg
High
Sprint
Release
Value
Priority
Future
Releases
Cost
Risk
Knowledge
Low
SCRUM
19

19. The scrumboard

20. Velocity and Burndown
It’s all about
Productivity
• How fast can we
build ?
• How good are the
estimations?

21. Some words on tools
• Very important : Application Lifecycle management system
• Eg Team Foundation Server
•
•
•
•
Project management
Source Control
Nightly builds
Automated testing

22. Going Agile
• Take reality for what it is
• Lean and mean in doing the
right stuff
• Deal with changes in a
‘natural’ way
• And learn from mistakes
http://www.youtube.com/watch?v=i38h6JRxTQM

23. And the dark side becomes the bright
side
Questions?

24. Some usefull links
• http://www.geekwire.com/2011/top-10-reasonsdarth-vader-amazing-project-manager/
• http://www.youtube.com/watch?v=Q5k7a9YEoUI
• http://www.scrum.org/
• Www.adifo.com