The document discusses various anti-patterns that can cause agile projects to fail. It notes that while many believe waterfall methods don't work, agile projects can fail too if not implemented properly. Some specific anti-patterns mentioned include blaming the methodology instead of the implementation, overreliance on documentation or rituals over outcomes, and treating agile as a one-size-fits-all approach. The document advocates for tailoring agile approaches to individual project and organization needs.

1. Agile Anti-Patterns
Yes your agile projects can and will fail too
Sander Hoogendoorn
Principal Technology Officer & Global Agile Thoughtleader
Capgemini
@aahoogendoorn
1

2. Sander Hoogendoorn
Capgemini
Principal technology officer
Global agile thought leader
Chief architect Accelerated Delivery Platform (ADP)
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
www.sanderhoogendoorn.com
sander.hoogendoorn@capgemini.com
@aahoogendoorn

4. Why waterfall won’t work
• Why waterfall won’t work

5. Waterfall?

6. Waterfall?

7. Agile!
7

8. You would believe …
because waterfall doesn’t work, right?

9. So the methodology doesn’t work
@aahoogendoorn They should never have used waterfall.
@aahoogendoorn Does the name of the project coincidently start with a C?

10. But how would you feel if …

11. @aahoogendoorn They didn’t apply Scrum right.
@aahoogendoorn This project likely did ScrumBut, not Scrum.
So it’s not the methodology, right?

12. 12

13. 13

14. 14

15. 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.
15

16. Scrumman
16

17. Dogmagile

18. Crusader Agile

19.  Scrumdamentalism 

20. Stand up meetings

21. Sit down meetings…

22. 
Scrumdamentalism 

23. Scrumdamentalism
 

24. Agilists against Zenifying
Just write down small things on small papers. It’s your kaizen.

25. Agilists against Zenifying
Don’t just write down small things on small papers. Write code. It’s your job.

26. The Bob-the-Builder-Syndrome
Can we build it? Yes, we can!

27. There is no so thing as
one-size-fits-all agile

28. Teams and roles
28

29. Customer, Coach, Developer

30. Product owner, Scrum master, Team

31. Customer, User, Domain Expert
Project Manager, Coach, Developer, Tester
Create
Stabilize
project
software
proposal
Propose Scope Realize Realize Realize Realize Finalize Manage
Write Deliver
Maintain
project working
software
plan software

32. Multiple roles

33. Teams?
33

34. What is the key
to being successful
as a team?
34

35. Collaboration
35

36. But what happens
to the old roles? 36

37. An example team
Product owner
Responsible for gathering
all business requirements
No ‘real’ business owner
Scrum team
Business analyst /2
Information analyst /2
SAP CRM /1
SAP XI/ BPM /2
SAP ABAP /1
UI developer /1
.NET developer /1
Test /2
Scrum master /1
Agile coach /1
37

38. The backlog
Where does it come from?

39. And on the
seventh day Ken
created the
backlog

40. The automagical backlog

41. The automagical backlog

42. Preliminary iterations

43. Preliminary iterations

44. Preliminary iterations
Create
Stabilize
project
software
proposal
Propose Scope Realize Realize Realize Realize Finalize Manage
Write Deliver
Maintain
project working
software
plan software

45. Documentation Frenzy

46. Documentation Frenzy
 

47. But if your IT landscape looks like this …

48. Index cards might just not do the trick

49. User stories are merely meant to get the conversation going?

50. So what about documentation?

51. The agile manifesto doesn’t say
no documentation (or modeling)

52. Eventually your software will go
into maintenance (hopefully)

53. Will you document to maintain?
 

54. Guesstimation
54

55. Apples
Team 1
55

56. Apples and oranges
Team 1 Team 2
56

57. Apples and apples
Team 1 Team 2
57

58. Distributed Apples
Off
shore
Team 1 Team 2 Team 3
Team
58

59. Mandatory burn down chart?
Bad smell: note how
the same example is
used in everyone’s
presentations.
Don’t trust a vendor’s
presentation if it has
this example of a
burndown chart in it.

60. We have our ups and downs

61. Lightweight agile can be
to enterprise projects
What Monopoly is
to solving the financial crisis

62. Agile is a sliding scale
62

63. Assembling Agile

64. Static versus Dynamic Agile
64

65. 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; }
}
65

66. 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();
}
66

67. 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 IndianTeam());
Approach.Unit = new Feature();
}
}
67

68. Assembling Agile – The basics of agile
Short Collaborative Small
Iterations Teams Unit of Work
Continuous Deliver Simplify
Planning Early & Often Communication

69. Lightweight Agile

70. Assembling Agile – Light
Short Collaborative Small
Iterations Teams Unit of Work
Continuous Deliver Simplify
Planning Early & Often Communication

71. Enterprise Agile


72. Assembling Agile – Enterprise
Short Collaborative Small
Iterations Teams Unit of Work
Continuous Deliver Simplify
Planning Early & Often Communication

73. Institutionalizing agile
73

74. Freedom and flexibility
74

75. Institutionalizing agile
75

76. In retrospective

77. Agile is no religion
So don’t be a zealot

78. Agile is a sliding scale
78

79. Assembling Agile

80. Value is found
In all agile approaces
(and yes, even in waterfall)

81. And please can we cut the crap
And go back to work?

82. 82

83. Sander Hoogendoorn
www.sanderhoogendoorn.com
@aahoogendoorn
83