Feedback. The Lost Art Of Agile. (v2)

Transcription

1 Feedback The Lost Art Of Agile (v2)

2 Software development has a history of loosing feedback

3 Why Lost? - Waterfall The implementation described above is risky and invites failure. Winston Royce, 1970

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

5 Why Lost? - Agile early and continuous delivery Deliver working software frequently Business people and developers must work together daily face-to-face conversation

6 Feedback! - Found? Validate any assumption in maximum two weeks

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

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

9 Why feedback?

10 Why? To validate decisions To improve processes To improve team work

11 Feedback is useful for... People Process

12 What? A process in which information about the past or the present influences the same phenomenon in the present or future Wikipedia

13 Feedback in Engineering Information by itself is not feedback unless translated into action Wikipedia

14 Feedback in Scrum

15 Feedback on Code

16 Personal Feedback - BAD You always make the same mistake Your code sucks John broke the build again

17 Personal Feedback - TOOL State the facts Future oriented Objective

18 Tool: Personal Feedback - GOOD I noticed that in the past week you were late 510' to the daily Scrum. 5 of your team mates had to wait for you to arrive. What can we do to avoid this in the future?

19 Management Feedback - BAD Yearly review 3 months ago your colleagues complained that...

20 Management Feedback - TOOL One To One (121) meeting every two weeks 360 evaluation every 3 months

21 Product feedback - BAD Build it and they will come I'm sure our users are happy but we have no data to show All the features are useful because I say so We will validate this feature in 6 months, after we make the release

22 Product feedback - Tools Lean UX use prototypes to validate features Measure usage, satisfaction Usability tests Feedback built in the product Release early, release often

23 Code Feedback - BAD [Test] public void FiveDimensionedArrays(){ int[,,,,] expected = new int[2, 2, 2, 2, 2] { { { { { 1, 2 }, { 3, 4 } }, { { 5, 6 }, { 7, 8 } } }, { { { 1, 2 }, { 3, 4 } }, { { 5, 6 }, { 7, 8 } } } }, { { { { 1, 2 }, { 3, 4 } }, { { 5, 6 }, { 7, 8 } } }, { { { 1, 2 }, { 3, 4 } }, { { 5, 6 }, { 7, 8 } } } } }; int[,,,,] actual = new int[2, 2, 2, 2, 2] { { { { { 1, 2 }, { 4, 3 } }, { { 5, 6 }, { 7, 8 } } }, { { { 1, 2 }, { 3, 4 } }, { { 5, 6 }, { 7, 8 } } } }, { { { { 1, 2 }, { 3, 4 } }, { { 5, 6 }, { 7, 8 } } }, { { { 1, 2 }, { 3, 4 } }, { { 5, 6 }, { 7, 8 } } } } }; var expectedmessage = " Expected and actual are both <System.Int32[2,2,2,2,2]>" + NL + " Values differ at index [0,0,0,1,0]" + NL + TextMessageWriter.Pfx_Expected + "3" + NL + TextMessageWriter.Pfx_Actual + "4" + NL; var ex = Assert.Throws<AssertionException>(() => Assert.That(actual, Is.EqualTo(expected))); Assert.That(ex.Message, Is.EqualTo(expectedMessage)); }

24 Code Feedback - GOOD [Test] public void AllItemsAreInRange(){ int[] c = new int[] { 12, 27, 19, 32, 45, 99, 26 }; Assert.That(c, new AllItemsConstraint(new RangeConstraint(10, 100))); }

25 Feedback Quiz!

26 Quiz #1 A team mate introduces bugs in the application every sprint. 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 E)Pair with him, identify why he does that and help him

27 Quiz #2 The project you work on has automated tests. 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 E)All tests run nightly F)Fast tests are separate and run after each code change

28 Quiz #3 A team mate talks at every daily Scrum for 10' and delays 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 tell him he should stop E)Do a retrospective at the end of the meeting

29 Quiz #4 You find a piece of complicated code at the end of the sprint, 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 D)Take 15' to refactor it and then move on

30 Quiz #5 You manage a few Scrum teams and have to evaluate the people. You: 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 E)Have weekly one-on-one meetings, monthly 360º and attend meetings from time to time

31 Feedback is AWEsome and AWEful

32 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 feedback cycle, Get more feedback, Get higher quality feedback

33 Questions