Death by dogma versus assembling agile
|
|
|
- Debra Pitts
- 5 years ago
- Views:
Transcription
1 Death by dogma versus assembling agile Sander Hoogendoorn Principal Technology Officer & Global Agile Thoughtleader Capgemini 1
2 Sander Hoogendoorn Capgemini Principal technology officer Global agile thought leader Chief architect Accelerated Delivery Platform Other Author books on UML, agile Author +200 articles, columns Speaker +100 international conferences Microsoft Partner Advisory Council.NET Editorial boards & Advisory boards Capping IT Off Blog Web
3
4 4
5 On being a developer... 5
6 Why waterfall won t work Why waterfall won t work
7 Waterfall?
8 Waterfall?
9 Agile! 9
10 You would believe because waterfall doesn t work, right?
11 So the methodology doesn t work They should never have used waterfall. Does the name of the project coincidently start with a C?
12 But how would you feel if
13 They didn t apply Scrum right. This project likely did ScrumBut, not Scrum. So it s not the methodology, right?
14 14
15 15
16 16
17 Jack states that we have over 300 resources who are trained as SCRUM master. As it happens I m meeting him this afternoon. I ll ask him. 17
18 Lowering Our Fences
19 Scrumman 19
20 Dogmagile
21 Crusader Agile
22 Scrumdamentalism
23 Stand up meetings
24 Sit down meetings
25 Scrumdamentalism
26 Agilists against Zenifying Just write down small things on small papers. It s your kaizen.
27 Agilists against Zenifying Don t just write down small things on small papers. Write code. It s your job.
28 There is no so thing as one-size-fits-all agile
29 Teams and roles 29
30 Customer, Coach, Developer
31 Product owner, Scrum master, Team
32 Customer, User, Domain Expert Project Manager, Coach, Developer, Tester Create project proposal Deliver working software Stabilize software Maintain software Write project plan 32
33 Multiple roles
34 Teams? 34
35 What is the key to being successful as a team? 35
36 Collaboration 36
37 Self-organization 37
38 But what happens to old roles? 38
39 An example team A typical Scrum team? Product owner /1 Business analyst /2 Information analyst /2 SAP CRM /1 SAP XI/ BPM /2 SAP ABAP /1 UI developer /1.NET developer /1 Java developer /1 Tester /2 Scrum master /1 Agile coach /1 39
40 Rowing Contest Collaboration Enterprise Architects End Users Development Team Test Team Offshore Development Team 40
41 The Bob-the-Builder-Syndrome Can we build it? Yes, we can!
42 The backlog Where does it come from?
43 And on the seventh day Ken created the backlog
44 The automagical backlog
45 The automagical backlog
46 Preliminary iterations
47 Preliminary iterations
48 Preliminary iterations Create project proposal Deliver working software Stabilize software Maintain software Write project plan 48
49 Documentation Frenzy
50 Documentation Frenzy
51 User stories
52 User stories
53 But if your IT landscape looks like this
54 Index cards might just not do the trick
55 User stories are merely meant to get the conversation going?
56 So what about documentation?
57 The agile manifesto doesn t say no documentation (or modeling)
58 Will you document to maintain?
59 Eventually your software will go into maintenance (hopefully)
60 Levels of requirements
61 Huge cases Hard to build, impossible to test
62 Different levels of use cases User goal Sub function
63 Smart use cases
64 Work item life cycle
65 Quality? 65
66 Quality in iterations 66
67 Quality per work item 67
68 Smart Use Case Cycle Accept use case Define work on use case Adjust use case Describe use case Run test cases Write test cases Generate and build use case
69 Work item life cycle
70 Life cycle dashboard
71 Kanban is NOT another agile approach Kanban is JUST an approach to improve your processes 71
72 The theory of constraints 1. Identify the system's constraint(s). That which prevents the organization from obtaining more of the goal in a unit of time. 2. Decide how to exploit the system's constraint(s). How to get the most out of the constraint. 3. Subordinate everything else to above decision. Align the whole system or organization to support the decision made above. 4. Elevate the system's constraint(s). Make other major changes needed to break the constraint. 5. Go back to step 1 And remember: a chain is no stronger than its weakest link
73 On when to estimate 73
74 When?
75 When?
76 Again preliminary iterations
77 The overall model
78 Smart use case model Create project proposal Deliver working software Stabilize software Maintain software Write project plan 78
79 Guesstimation 79
80 Apples Team 1 80
81 Apples and apples Team 1 Team 2 81
82 Apples and oranges Team 1 Team 2 82
83 Distributed Apples Team 1 Team 2 Team 3 Off shore Team 83
84 Mandatory burn down chart? Bad smell: note how the same example is used in everyone s presentations. Don t trust a vendor presentation if it has this example of a burndown chart in it.
85 We have our ups and downs
86 Lightweight agile can be to enterprise projects What Monopoly is to solving the financial crisis
87 Agile is a sliding scale 87
88 Assembling Agile
89 Static versus Dynamic Agile 89
90 Project Approach public interface IApproach { List<ITeam> Teams { get; set; } IDashBoard Board { get; set; } IUnitOfWork Unit { get; set; } } public abstract class Approach : IApproach { public List<ITeam> Teams { get; set; } public IDashBoard Board { get; set; } public IUnitOfWork Unit { get; set; } } 90
91 Static Approach public class Scrum : Approach { public Scrum() { Teams = new List<ITeam> {new LocalTeam()}; } } Board = new TaskBoard(); Unit = new UserStory(); public class ScrumProject { public Scrum Approach = new Scrum(); } 91
92 Dynamic Approach public class Project { public IApproach Approach { get; set; } } public class MyProject : Project { public MyProject() { Approach = new Smart(); Approach.Board = new KanbanBoard(); Approach.Teams.Add(new LocalTeam()); Approach.Teams.Add(new LocalTeam()); Approach.Teams.Add(new UkranianTeam()); } } Approach.Unit = new Feature(); 92
93 Assembling Agile The basics of agile Short Iterations Collaborative Teams Small Unit of Work Continuous Planning Deliver Early & Often Simplify Communication
94 Lightweight Agile
95 Assembling Agile Light Short Iterations Collaborative Teams Small Unit of Work Continuous Planning Deliver Early & Often Simplify Communication
96 Enterprise Agile
97 Assembling Agile Enterprise Short Iterations Collaborative Teams Small Unit of Work Continuous Planning Deliver Early & Often Simplify Communication
98 Institutionalizing agile 98
99 Freedom and flexibility 99
100 Institutionalizing agile 100
101 In retrospective
102
103 Agile is no religion So don t be a zealot
104 Agile is a sliding scale 104
105 Assembling Agile
106 Value is found In all agile approaches (and yes, even in waterfall)
107 And please can we cut the fluffiness And go back to work?
108 108
109 Sander Hoogendoorn 109