We don't have all the answers. We don't know the best way to build software in the right way. But we do know one thing: the right way doesn't involve mindlessly following practices just because some "self-proclaimed expert" says you need to.
In this workshop we'll take a critical look at various "agile" practices and try to highlight the dogma and ceremony that has creeped in. We'll also question if the practices defined a decade ago are still applicable? If yes, have they evolved since? What are some of the original creators of these processes practicing today? And so on...
Breaking the Kubernetes Kill Chain: Host Path Mount
Ā
Monkey See Monkey Do! Workshop Challenges Agile Dogma
1. Monkey See Monkey Do!
Sandeep Shetty Naresh Jain
Directi Industrial Logic
Released under Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License
Thursday 4 February 2010 1
Image Src: http://itre.cis.upenn.edu/~myl/languagelog/archives/chimp.jpg
2. Backlog for the Workshop
100 BV 5 Nuts
As an agile presenter,
I want to create a backlog,
So that we can actually get it done!
Thursday 4 February 2010 2
<sarcasm>Like any expert agile practitioner we started off our mini-project with a list of well thought-
out user stories.</sarcasm> These stories of-course were prioritized based on the business value and
story point estimates and then carefully placed in our backlog. Notice weāve used NUTs (Nebulous Unit
of Time) for our story point estimate.
4. Freeze on Workshop Title
500 BV 1 Nut
As a presenter,
I want to select a title for the talk,
So that it is attractive to the
conference attendees
Thursday 4 February 2010 4
To submit a proposal to the conference, the ļ¬rst thing we needed was a title and hence this story
5. Write Workshop Abstract
500 BV 10 Nuts
As a presenter,
I want to come up with an
interesting abstract for the talk
along the conference theme,
So that it gets accepted
Thursday 4 February 2010 5
The title alone was not sufficient, we also needed a kick-ass abstract, inline with the conference theme
to get selected.
6. Workshop outline
700 BV 15 Nuts
As a presenter & co-presenter,
we want an outline,
So that we can start creating the
content for the workshop
Thursday 4 February 2010 6
Once our proposal was accepted, we had to break down the workshop into tasks and start working on
it.
7. Slide Usability
200 BV 2 Nuts
As a co-presenter,
I want the slides to be usable,
So that my message is conveyed
clearly to the conference attendees
Thursday 4 February 2010 7
Fed up with all the accusations about the Agile community not being user centric, we choose to give
high priority to Usability. We take no crap from these non-believers
8. Customer Delight
2500 BV 35 Nuts
As a conference attendee,
I want to learn something new,
So that Iām delighted
Thursday 4 February 2010 8
Having a workshop where the participants donāt learn anything is like writing unit tests without
asserts, pointless!
9. Workshop Content
2100 BV 30 Nuts
As a presenter,
I want to create workshop content,
So that we can conduct the
workshop
Thursday 4 February 2010 9
This was the most obvious story.
10. Analysis Paralysis
Thursday 4 February 2010 10
<sarcasm>Our agile zen like intuition</sarcasm> told us that we had enough stories and we could
start planning our sprints.
11. Analysis Paralysis
Thursday 4 February 2010 10
<sarcasm>Our agile zen like intuition</sarcasm> told us that we had enough stories and we could
start planning our sprints.
13. Sprint 1
Velocity 12
Capacity 5 hrs
Stories
Freeze on workshop title 1 point 500 BV
Write workshop abstract 10 points 500 BV
Thursday 4 February 2010 12
Sprint 1: Since we had worked together before on similar conference presentations, we had a
<sarcasm>clear measurement of our velocity</sarcasm>. By the time we realized we wanted to
present at the conference, it was the last day for submitting proposals to the conference, we had only
5 hours to go. (BTW, we both have full-time day jobs). Talk about real world deadlines and constraints.
14. Story Points
Burn Down
Sprints
Thursday 4 February 2010 13
To start off with, this is what our burn-down chart looked like. We had 93 story points to ļ¬nish.
15. Story: Freeze on Workshop
Title
Thursday 4 February 2010 14
16. Workshop title:
F**k that Sh*t
Thursday 4 February 2010 15
We had a growing feeling that there is a lot of dogma and ceremony creeping into the agile
community. We wanted to highlight some of our concerns. Since we did not have all the details ļ¬ushed
out, we wanted to keep the title a bit abstract. This would help us work out the details at the last
responsible moment. While throwing around ideas for the title, nothing seemed to communicate our
state of mind. Just then we remembered this strip from XKCD http://xkcd.com/137/ which captured
our sentiments. The title was also provocative (and in-your-face) to attract attention and raise
curiosity.
17. Story: Freeze on Workshop
Title
Thursday 4 February 2010 16
That was easy!
18. Story: Write workshop Abstract
Thursday 4 February 2010 17
19. We don't have all the answers. We
donāt know the best way to build
software in the right way. But we
do know one thing: the right way
doesnāt involve mindlessly following
practices just because some
"expert" says you need to.
In this workshop we'll take a
critical look at various "agile"
practices and try to highlight the
dogma and ceremony that has
creeped in. We'll also question if
the practices defined a decade ago
are still applicable? If yes, have
they evolved since? What are some
of the original creators of these
processes practicing today? And so
on...
Thursday 4 February 2010 18
As you can see this was the abstract that was published on the conference website. On the right, you
see the strip from XKCD. Please note that we donāt really have all the answers. We are no experts by
any means. Certainly over the years weāve learned what does not work well. Esp. mindlessly following
some self proclaimed expert.
So this session is dedicated to questioning the dogma and ceremony with a twist.
20. Story: Write workshop Abstract
Thursday 4 February 2010 19
With the Title and Abstract in place, we submitted our proposal to Agile India
21. Burn Down
Story Points
Sprints
Thursday 4 February 2010 20
This sprint was a slam dunk. This is an example of how every sprint should be executed. Picture
Perfect! Everything went as planned. We burnt 11 points in just under 5 hours.
22. Customer Feedback
Thursday 4 February 2010 21
Soon the conference program was published. Our workshop was accepted for both, Mumbia and
Bengaluru conference. As we were celebrating the acceptance of our proposal, potential conference
attendees (our customers) started sharing their open and honest feedback on the agileindia mailing list
(http://tech.groups.yahoo.com/group/agileindia/). We realized people were quite offended by our
rather cool & thoughtful title. Some customers said they wonāt be able to share this presentation with
the rest of their organization.
We were pissed and discussed how stupid & naive our customers were. Anyway like good Agile
practitioners we embraced our customer feedback and decided to change our title.
23. a NEW story!
Thursday 4 February 2010 22
And hence we had to create a new story which was not planned for.
24. Change Offensive Title
300 BV 3 Nut
As a Presenter,
I need to change the talk title,
So that it is not offensive to the
prospective conference attendees
Thursday 4 February 2010 23
Added it to our Backlog
25. Burn Down
Story Points
Sprints
Thursday 4 February 2010 24
Adding this story to our backlog, created a spike in our burn-down.
Sidebar: <sarcasm>With all those wonderful, cool looking, Project Management (commercial) tools,
managing scope creep is just a breeze. We donāt really need a Master to maintain our Big Visible
Charts</sarcasm>.
26. Sprint 2
Velocity 20
Capacity 10 hrs
Stories
Change Offensive Title 3 points 300 BV
Slide Usability 2 points 200 BV
Workshop Outline 15 points 700 BV
Thursday 4 February 2010 25
After the grand success of our ļ¬rst sprint, we started planning for our second sprint. This time we had
more time to spare and hence our capacity was 10 hrs. Our projected velocity was also higher this
time. You see, <sarcasm>we really inspect and adapt, unlike others who just talk about it.</sarcasm>
So this sprint, we took on 3 stories.
Even though the āChange Offensive Titleā story was just created, we had to react quickly so that we did
not loose our audience.
27. Story: Change Offensive Title
Thursday 4 February 2010 26
Since we had already burnt our hands trying to come up with an attractive title, we decided to use the
ācrowd sourcingā model. We asked people for suggestions on Twitter & on the agileindia mailing list.
28. Ze ge
he ca
n-g
g t ile
apin
Esc p an d Do
Shut-u
Which Agile Prac
tices? - A Practi
tioner's Dilemma
Enterpr ise Agile
Janta ki Adalat mein aaj Agile Practices
Practices, Practices, Practices
Thursday 4 February 2010 27
We got a lot of wonderful suggestions from people.
29. New workshop title:
Monkey See Monkey Do!
Thursday 4 February 2010 28
Finally we decided to choose this title as it seemed most appropriate (hoping that no monkeys would
get offended by this). We had to sign a 5 year MSA (Master Services Agreement) with the CHA-CHA-
CHA (Coalition of Human Anti-Capitalists Helping Animals Conquer Hominid Abuse) foundation for
using this title.
30. Story: Change Offensive Title
Thursday 4 February 2010 29
We updated the conference program and our customers seemed to be happy. (Like always we had
some customers having other preferences. <sarcasm>We let our Product Owner clearly explain to
them how this Agile stuff works </sarcasm>)
31. Story: Slide Usability
Thursday 4 February 2010 30
Since we could not hire a Usability team and we are not experts on Usability when it comes to
presentations, we thought weāll ask the group for suggestions.
32. Research
http://perl.plover.com/yak/presentation/samples/notes.html#sl-8
http://www.garrreynolds.com/Presentation/slides.html
http://www.businessweek.com/smallbiz/content/jan2008/sb20080125_269732.htm
http://www.youtube.com/watch?v=O5J0THtnPiA
http://www.goarticles.com/cgi-bin/showa.cgi?C=1542910
Thursday 4 February 2010 31
We got a huge response from the group requesting us to read up on the following links. We spent a
large chunk of our time researching this topic. Kind of overshot our estimates, <sarcasm>but hey,
next time weāll be better and learning is so central to Agile</sarcasm>.
33. The quick brown fax jumped
over the the daisy dog
Thursday 4 February 2010 32
After doing all that research, we decided to make a template using our newly acquired knowledge.
<sarcasm>Monkey 1: Wait a sec, Dude, there is a typo in this. Crap this auto-complete. Dināt our QA
run all the automated regression tests?
Monkey 2: They did but they donāt have UI tests because they are very fragile. They ran all the
acceptance tests that we write one layer below the UI.
Monkey 1: Iām going to ļ¬x this now. Its embarrassing.
Fuckā¦ I mean... Fixed. Updated. Checked In and Kick off another build. </sarcasm>
35. The quick brown fox jumped
over the the lazy dog
Thursday 4 February 2010 34
There you go. Quick like a bunny. Its all good to go.
So we decided to use this template for our entire presentation.
36. Story: Slide Usability
Thursday 4 February 2010 35
And with this weāve addressed any Usability concerns including appropriate contrast levels to capture
our slides while video recording under low light conditions.
37. Story: Workshop Outline
Thursday 4 February 2010 36
This was a very important story. Lets see what weāve got done here...
38. Double-click to edit
Thursday 4 February 2010 37
As you can see we did not get anything done. Why do you think it is? We wrote stories, we did story-
point estimates, we did velocity based adaptive planning, burn-down & other big visible chart, yada
yada yada, ...so we should have delivered something meaningful, but what went wrong?
39. Hang Over!
@#$@$$@#
Thursday 4 February 2010 38
Yeah, Monkey 1 had to fall sick. Also the usability story kind of ate into this storyās time a bit.
Anyway, stuff like this happens all the time on our projects. <sarcasm>No big deal, we inspect and
adapt.</sarcasm> This story went into the hang-over mode. Hopefully weāll play it next sprint.
40. Burn Down
Story Points
Sprints
Thursday 4 February 2010 39
This is how our release burn-down looked. We could not burn as many points as planned. Now we
have 77 more points to go.
41. Sprint 3
Velocity 45
Capacity 20 hrs
Stories
Customer Delight 35 points 2500 BV
Workshop Outline 15 points 700 BV
Thursday 4 February 2010 40
Sprint 3. <sarcasm>More capacity better Velocity (our motto)</sarcasm>. Workshop outline, which
was from last sprint and then the most important story, customer delight.
42. Story: Customer Delight
Thursday 4 February 2010 41
43. Acceptance Criteria?
Thursday 4 February 2010 42
Whenever we have a large story, we try to break it down. Starting with Acceptance Criteria always
helps.
44. How will we know if the
customer is delighted?
Thursday 4 February 2010 43
What does it mean to delight our customers?
45. Metrics
Thursday 4 February 2010 44
<sarcasm>
Because delight is a very subjective thing, we started looking for some metrics that would objectively
tell us if our customers were delighted or not. We started watching various conference presentation
videos. We noticed that the intensity of the claps closely co-related to how satisļ¬ed/delighted the
audience was. We also observed that the āThank Youā slide at the end, triggers most people to clap. So
we concluded that the āThank Youā slide is what gives audience the most delight.
</sarcasm>
46. Thank You!
Thursday 4 February 2010 45
Hence we decided to cut the chase and go straight to the slide that gives the audience the most
delight. There you have it folks. (lots of claps, and more claps) ...Thank you ..Thank you. Mention Not.
47. Story: Customer Delight
Thursday 4 February 2010 46
And this way, we achieved Customer Delight. Proved to be much simpler than we thought it would be.
48. Story: Workshop Outline
Thursday 4 February 2010 47
Ohhā¦ yes, we need to work on the workshop outline. The hung-over story.
49. Thursday 4 February 2010 48
Oopsā¦ <sarcasm>We are done with all our Pomodoros</sarcasm>.
50. Burn Down
Story Points
Sprints
Thursday 4 February 2010 49
This is how our burn-down looked this morning at 6:00. In spite of clocking in all those extra hours
through the night (and expensive coffee), we could only burn down a total of 54 points. 42 points to
go.
51. So this is where we are with
our presentation!
Thursday 4 February 2010 50
52. How do you think we
performed?
Thursday 4 February 2010 51
53. That brings us to the REAL
title of our talkā¦...
Thursday 4 February 2010 52
54. Agile WTF
Thursday 4 February 2010 53
Well its not what you think! <sarcasm>Expert Agile Practitioners donāt make the same mistakes
(offensive title) again</sarcasm>
56. Agile Way To F
Thursday 4 February 2010 55
To...
57. Agile Way To Fail
Thursday 4 February 2010 56
Failā¦. What we just presented was a demo of how you can follow agile practices by the book and still
fail. Hold that thought for a moment. We know you are going to say, that we did not follow āallā the
practices and hence we failed. But we think, you kind of miss the whole point about Agile. Its about
āPeople and Interaction OVER Process and Toolsā remember? Agile is not a silver bullet. Nothing can
be.
58. Thursday 4 February 2010 57
We assume everyone is fairly familiar with these alien Japanese cars. Some of you might even have
driven one or at least sat in one.
59. What is the top reason behind
Toyotaās success?
Thursday 4 February 2010 58
Yes, Toyota Production System, Lean Thinking, Lean Manufacturing, Lean Business Systems,
Innovation, Systems thinking, Waste Management, Focus on throughput, Humility and the list goes on.
60. So, why is there only one
Toyota?
Thursday 4 February 2010 59
We all seem to know all the reasons behind Toyotaās success. We have a pretty decent understanding
(at least we think we do) of these concepts. But then why are we not able to create more success
stories like Toyota? Why are other car manufacturers ļ¬lling for bankruptcy? Is there a problem with our
implementation or is it a bigger problem?
61. Context is King!
(or Queen if you like)
Thursday 4 February 2010 60
Monkey See Monkey Do outside the original context can rather be harmful. According to us, this is one
main reason why aping does not necessary bring success.
62. Individual Activity
What practices do you think
are indispensable for your
project?
2 mins
Thursday 4 February 2010 61
Well, letās take 2 mins and jot down some points about the practices that you think are indispensable
on your current project? What are the absolute must have practices for software development?
63. Group Activity
What practices do you think
are indispensable for every
project?
5 mins, teams of 5 ppl
Thursday 4 February 2010 62
Now that you have some indispensable practices from your project, lets form groups of 5 people each
and come up with a collective list of things that you as a group think are indispensable for every
project? These are the practices you feel every software project should follow. Be careful not to mix up
values, principles and practices. They apply at different levels.
Interestingly none of the groups came up with the same list of practices. Interesting indeed.
64. Bloat Effect
How often do you take practices out
v/s add new ones?
Thursday 4 February 2010 63
When something is not working well on your team/project, what is the most natural thing people do
on projects today?
Yup, thatās right, do some root-cause analysis, ļ¬nd an appropriate practice, document it on the
project wiki and mandate future process improvement on the team. Some call this āinspect and adaptā.
When you proceed with this philosophy, over a period of time, your process gets heavier and heavier,
your software bloats up, team size increases, amount of planning required starts increasing,
documents and artifacts get bulkier, bug count goes up and so on. But what happens to your user
satisfaction, company proļ¬ts, joy of working?
Unfortunately more and more organizations adopt the āmore the merrierā philosophy instead of āless is
moreā or āless is beautifulā philosophy. Why not embrace simplicity?
Simplicity is deļ¬ned as āthe art of maximizing work not doneā.
65. Sacred Agile Practice
Thursday 4 February 2010 64
Lets talk about some Agile Practices that some people hold dear to their heart.
Disclaimer: We are not saying these practices are not required. We are asking you to question the need
for these practices on every project, through-out the project.
66. Release & Sprint Planning
Thursday 4 February 2010 65
Coordination - inside & outside
Managing uncertainty
Optimal resource utilization
Adaptive Planning
Planning is important, but plans are use less
We plan to deliver not deliver to plan
Ends up leading to a lot of overhead
Plans gives you a false sense of certainty and end up building walls between teams
Continuous Flow
67. Iterations & Time Boxes
Thursday 4 February 2010 66
To avoid Thrashing
To get commitment
-ve
Batching - Capacity Utilization centric rather than through-put centric, leads to inventory
Leads to a min-waterfall
Commitment & ļ¬xed time box - leads to effort estimation - which leads to analysis & design upfront &
buffering
68. Estimation
Thursday 4 February 2010 67
For years I thought I was a poor developer because I could not estimate well
Predictability Paradox
Lack of trust
Buffering
Student Syndrome
Optimism bias
Sophistication
Dead Lines?
69. Sustainable Pace
Thursday 4 February 2010 68
Sustainable Pace as deļ¬ned by x number of hrs per week is not really sustainable. As humans, esp.
Software artists, we are not productive linearly. There are times when we are ultra productive and there
are times when we have not idea what we are doing. We are not questioning Sustainable Pace. The
interpretation of sustainable pace is very questionable. People dumb it down to a very mundane,
clocking x hrs per week makes something sustainable. We think there is lot more to sustainable pace.
Weāve worked on lots of projects were we have clocked in more than x hrs every day and were able to
sustain it for at least a few months. We would argue that if you enjoy doing something and truly
believe in it sustainable pace automatically falls in place.
How many people have cleared exams here? How many people studied through out the year?
There it is, most of us have cleared our exams by studying the previous night. And weāve been able to
sustain this for 16 years. In some sense its so need and goal driven.
71. Clean Code
TDD, Refactoring, Simple Design
Thursday 4 February 2010 70
How many code bases have you worked on which you would say is clean code?
Clean Code is not sustainable
How much clean code is sufficient?
72. Requirements
Use cases, User Stories, Epics, Personas
Thursday 4 February 2010 71
Want v/s Need
Requirements belongs to the solution domain
Business Analysis capturing the requirements, it reminds me of waiters in a restaurant
Instead of personas, lets get our product idea out there and get feedback from real users
76. Individual Activity
Now what practices do you
think can be thrown out of your
project?
Thursday 4 February 2010 75
Are there any practices that are not really adding value, may be even getting in your way of getting
things done? Do you think you can do without them?
77. Thank You!
(for real this time)
No monkeys were harmed in the making of this presentation.
This presentation was made using only recycled pixels
Thursday 4 February 2010 76