The document discusses how feedback has been lost in software development processes over time, but is essential for validating decisions, improving processes and teamwork. It provides examples of how feedback works in agile practices like Scrum and explains that feedback is only useful if it is translated into action. The presentation concludes that software development is rediscovering the importance of frequent, high-quality feedback at its core.

1. Feedback
The Lost Art Of Agile
A talk by for:

2. Software development
has a history of
loosing feedback
A talk by for:

3. Why Lost? - Waterfall
“The
implementa tion
described above
is risky and
invites failure.”
Winston Royce,
1970
A talk by for:

4. Why Lost? - Unit Testing
1985: book on structured
programming talks about unit
testing
1989: “we sketched out a set of
test cases before putting pencil
to coding pad … These were
punched into cards and put in
the permanent test case library”
Gerry Weinberg
A talk by for:

5. Why Lost? - Agile
“earl and continuous
y
delivery”
“Deliver working
software frequentl y”
“Business people and
developers must work
together dail y”
“face-to-face
conversa tion”
A talk by for:

6. Feedback! - Found?
Validate
any
assumptio
n in
maximum
two weeks
A talk by for:

7. Why Art?
Not Science.
Some science might be
involved: Statistics,
Psychology, Systems
Theory.
A talk by for:

8. Why feedback? The Thesis.
Software development
is on a quest for
high quality fast feedback
,
A talk by for:

9. Why feedback?
A talk by for:

10. Why?
●
To validate decisions
●
To improve processes
●
To improve team work
A talk by for:

11. Feedback is useful for...
People
Process
A talk by for:

12. What?
“A process in which
information about
the past or the
present influences
the same
phenomenon in the
present or future”
Wikipedia
A talk by for:

13. Feedback in Engineering
“Information by itself is not
feedback unless translated
into action”
Wikipedia
A talk by for:

14. Feedback in Scrum
A talk by for:

15. Feedback on Code
A talk by for:

16. Feedback Quiz!
A talk by for:

17. A team mate introduces bugs in
the application every sprint.
Quiz #1
You:
A)Don't care
B)Tell him he should stop
programming
C)Review his code and tell him
the problems
D)Ask him how you can help to
avoid it
A talk by for:
E)Pair with him, identify why he

18. automated tests.
Quiz #2
A)You don't run them, it's
integration department's
business
B)50 tests fail from time to
time
C)When making a change, 20
tests fail
D)At most two tests fail in
case of a mistake
A talk by for:
E)All tests run nightly

19. daily Scrum for 10' and delays
Quiz #3
the meeting. You are the Scrum
Master. You:
A)Think at something different
while he speaks
B)Find ways to leave earlier
C)Tell him to stop talking
because he's annoying
D)Talk to him in private and
A talk by for:
tell him he should stop

20. You find a piece of complicated
code at the end of the sprint,
Quiz #4
while modifying in other parts
of the application. You:
A)Ignore it, maybe you won't
have to change it
B)Write the issue down and
forget about it
C)Discuss it in the team and add
it to the backlog
A talk by for:
D)Take 15' to refactor it and

21. team and have to evaluate the
people. You:
Quiz #5
A)Don't evaluate them, whoever
asks for a raise might get it
B)Do a yearly evaluation
according to company policies
C)Go at the team meetings to
evaluate the people
D)Do a 360º evaluation every 2
months
A talk by for:
E)Have weekly one-on-one

22. Feedback is HARD
A talk by for:

23. Tools
Introduce a feedback
cycle
More feedback
Better quality
feedback
A talk by for:

24. Time to reflect...
A talk by for:

25. Case Study: Startup
●
Deploy every 2-3 days
●
Feedback form built in
A talk by for:

26. Case Study: My Unit Testing Class
●
Source: feedback form,
conversations, clarification
questions
●
Integrated in the course
●
Fewer clarification
questions, higher feedback
(>9.5 / 10)
A talk by for:

27. Case Study: Mozaic Works
●
Distributed team,
different roles and
backgrounds, flat
structure
●
6 months team
retreats
●
2 weeks company
sprints
●
Full visibility
A talk by for:

28. Case Study: Presentation Creation
●
Slides, practice
●
Slides, record, listen
●
Brainstorm, structure,
record, listen, slides
●
From 3 days to 4 hrs
●
Need more practice and
feedback :)
A talk by for:

29. Main Ideas
●
Software development is
on a quest for more, higher
quality feedback
●
It is feedback only if you
do something about it
●
Tools: Introduce cycle,
Get more, Get better
●
Feedback is hard
A talk by for:

30. Conclusions
We are rediscovering
that feedback is at the
core of software
development.
A talk by for:

31. Your turn to give feedback!
A talk by for:

32. Questions?
A talk by for: