Agile Software Development - making programming fun again

1. Agile Software Development
making programming fun again

2. How Projects Really Work
Software engineering done right.

3. How the customer explained it
Software engineering done right.

4. How the project leader understood it
Software engineering done right.

5. How the analyst designed it
Software engineering done right.

6. How the programmer wrote it
Software engineering done right.

7. How the business consultant described it
Software engineering done right.

8. How the project was documented
Software engineering done right.

9. How much the project cost
Software engineering done right.

10. What the customer really needed
Software engineering done right.

11. “CHAOS Report” by Standish Group
Software engineering done right.

12. Challenged Projects - Reasons

Lack of User Input 
Technology

Incomplete Incompetence
Requirements & 
Lack of Resources
Specifications 
Unrealistic Expectations

Changing Requirements 
Unclear Objectives
& Specifications 
Unrealistic Time Frames

Lack of Executive 
New Technology
Support
Software engineering done right.

13. Failed Projects - Reasons

Incomplete 
Changing Requirements
Requirements & Specifications

Lack of User 
Lack of Planning
Involvement 
Didn't Need It Any

Lack of Resources Longer

Unrealistic Expectations 
Lack of IT Management

Lack of Executive 
Technology Illiteracy
Support
Software engineering done right.

14. Successful Projects - Reasons

User involvement 
Project manager

Executive management expertise
support 
Financial management

Clear business 
Skilled resources
objectives 
Formal methodology

Optimizing scope 
Standard tools and

Agile process methodology
Software engineering done right.

15. What's wrong with “Waterfall”?
Software engineering done right.

16. What's wrong with “Waterfall”?

Mistakes are hard to find in early stages

Expensive to fix mistakes in later stages

Customers don't know what they want from the
beginning

Developers don't know how long a project will take
from the beginning

Business needs change
Software engineering done right.

17. Effects of “Waterfall”

Death March projects
‒
Mis-estimated schedules lead to successive overtime
‒
Delays in one stage cause delays in succeeding stages

Conflict between customers and developers
‒
Customers don't get the software that they want
‒
Developers don't get clear requirements

Process and tool obsession
‒
People focus on creating artifacts but lose sight of the
goal of working software
‒
Processes replace natural communication
Software engineering done right.

18. The Agile Manifesto
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.
Software engineering done right.

19. Selected Practices

Iterative Development

User Stories

Test-Driven Development

One Team

Self-Managed Teams

Sustainable Pace
Software engineering done right.

20. Iterative Development

Software development as an evolutionary process
Software engineering done right.

21. Iterative Development

All steps of SDLC are done at each iteration
Software engineering done right.

22. Iterative Development

Working software produced at each iteration
– No such thing as “X% complete”, only done and not
done
Software engineering done right.

23. Iterative Development

Benefits
‒ Customers can evaluate what they want and adjust
requirements
‒ Developers get better estimates of future tasks
‒ Better communication between customer and
developers and among developers

Talk is about something concrete, not abstract
‒ Just enough artifacts are created to produce working
software

Less waste
Software engineering done right.

24. User Stories
Traditional requirements: “The system shall... the
system shall...”
Software engineering done right.

25. User Stories
As a < user role >
In order to < business goal >
I want to < behavior >

Focus on business goals
- Requirements have context

Story-telling is the most natural way of
communication
Software engineering done right.

26. Test-Driven Development
 Bugs are harder to find
and fix when found later
 Modifying code tends to
introduce bugs
- Difficult to know if one has
introduced bugs without
tests
 Manual tests are
expensive to repeat and
provide limited
information
Software engineering done right.

27. Test-Driven Development

Programmers should write automated tests as they
code
- Write test before implementation

Provides immediate feedback if their code works

Builds suite of automated tests that can be run each
time code is modified

Makes it safe to modify existing code

Frameworks: JUnit, NUnit, hundreds of others...
Software engineering done right.

28. Software engineering done right.

29. TDD Benefits

Code is safe to modify

Tests are excellent documentation
- Programmers hate writing documentation, but they like to
code

Design improves
- Programmers think of their code's behavior before coding
- Programmers see their code from a second-person's
point-of-view
• Is my code readable? Easy to use?
- Components become decoupled to facilitate testing
Software engineering done right.

30. One Team

Everyone is
considered part of one
team, including the
customer

Developers, testers,
business analysts,
project managers, web
designers, etc, work in
the same place,
place
usually on the same
table
Software engineering done right.

31. Software engineering done right.

32. One Team

Faster communication
– Issues resolved faster

Natural communication
– Face-to-face, ad hoc and continuous throughout the
day

Less misunderstanding and antagonism between
functional groups
Software engineering done right.

33. Self-Managed Teams
When teams manage themselves...

Higher motivation

More creative solutions

Faster resolution of issues

Drive for continuous improvement
Software engineering done right.

34. Self-Managed Teams
Practices/Tools

Daily Stand-Up Meetings

Retrospectives

Big Visible Charts,
Whiteboards

Direct access to
customers
Software engineering done right.

35. Sustainable Pace

Overtime leads to
lower productivity

Lowers morale
Software engineering done right.

36. Sustainable Pace

Team should measure “velocity” at each iteration

Keep work load within velocity

If iteration load was underestimated, ask customer
to decide which features to move to future iterations
Software engineering done right.

37. Other Practices...

Planning

Tracking

Continuous Integration

Pair Programming

Refactoring

Planning Boards

Burn-Down Charts

Collective Code Ownership

Coding Standards
Many more...
Software engineering done right.

38. Agile at Orange & Bronze
• Been doing Agile since its foundation in 2005
– Before it became mainstream
• We've tried different methodologies and practices
– XP, Scrum, Kanban
– Not all practices work in all conditions
• The first to offer training in Agile methodologies and
practices
– Scrum, TDD, Agile Business Analysis, Agile QA, etc
– Trainers are seasoned practictioners
Software engineering done right.

39. Open Workspaces
Software engineering done right.

40. Project Automation
Software engineering done right.

41. Collaborative Design
Software engineering done right.

42. Agile Training
Software engineering done right.