Monkey See Monkey Do

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

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!


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

Backlog


Lets take a closer look at the stories in our backlog

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


To submit a proposal to the conference, the ﬁrst thing we needed was a title and hence this story

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


The title alone was not sufficient, we also needed a kick-ass abstract, inline with the conference theme
to get selected.

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


Once our proposal was accepted, we had to break down the workshop into tasks and start working on
it.

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


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

Customer Delight
2500 BV 35 Nuts

As a conference attendee,
I want to learn something new,
So that I’m delighted


Having a workshop where the participants don’t learn anything is like writing unit tests without
asserts, pointless!

Workshop Content
2100 BV 30 Nuts

As a presenter,
I want to create workshop content,
So that we can conduct the
workshop


This was the most obvious story.

Analysis Paralysis


<sarcasm>Our agile zen like intuition</sarcasm> told us that we had enough stories and we could
start planning our sprints.

Adaptive Planning


Let’s look at our <sarcasm>wonderful adaptive plan</sarcasm>

Sprint 1
Velocity 12
Capacity 5 hrs

Stories
Freeze on workshop title 1 point 500 BV
Write workshop abstract 10 points 500 BV


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.

Story Points
Burn Down

Sprints


To start off with, this is what our burn-down chart looked like. We had 93 story points to ﬁnish.

Story: Freeze on Workshop
Title


Workshop title:
F**k that Sh*t


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.

Story: Freeze on Workshop
Title


That was easy!

Story: Write workshop Abstract


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


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.

Story: Write workshop Abstract


With the Title and Abstract in place, we submitted our proposal to Agile India

Burn Down
Story Points

Sprints


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.

Customer Feedback


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.

a NEW story!


And hence we had to create a new story which was not planned for.

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


Added it to our Backlog

Burn Down
Story Points

Sprints


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

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


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.

Story: Change Offensive Title


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.

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


We got a lot of wonderful suggestions from people.

New workshop title:
Monkey See Monkey Do!


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.

Story: Change Offensive Title


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>)

Story: Slide Usability


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.

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


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

The quick brown fax jumped
over the the daisy dog


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>

http://waitingforbuild.com/


CI is such a wonderful thing. While our presentation is getting built & tested, lets exercise our brain a
bit. (Its been a while)

The quick brown fox jumped
over the the lazy dog


There you go. Quick like a bunny. Its all good to go.
So we decided to use this template for our entire presentation.

Story: Slide Usability


And with this we’ve addressed any Usability concerns including appropriate contrast levels to capture
our slides while video recording under low light conditions.

Story: Workshop Outline


This was a very important story. Lets see what we’ve got done here...

Double-click to edit


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?

Hang Over!
@#$@$$@#


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.

Burn Down
Story Points

Sprints


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.

Sprint 3
Velocity 45
Capacity 20 hrs

Stories
Customer Delight 35 points 2500 BV
Workshop Outline 15 points 700 BV


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.

Story: Customer Delight


Acceptance Criteria?


Whenever we have a large story, we try to break it down. Starting with Acceptance Criteria always
helps.

How will we know if the
customer is delighted?


What does it mean to delight our customers?

Metrics


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

Thank You!


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.

Story: Customer Delight


And this way, we achieved Customer Delight. Proved to be much simpler than we thought it would be.

Story: Workshop Outline


Ohh… yes, we need to work on the workshop outline. The hung-over story.


Oops… <sarcasm>We are done with all our Pomodoros</sarcasm>.

Burn Down
Story Points

Sprints


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.

So this is where we are with
our presentation!


How do you think we
performed?


That brings us to the REAL
title of our talk…...


Agile WTF


Well its not what you think! <sarcasm>Expert Agile Practitioners don’t make the same mistakes
(offensive title) again</sarcasm>

Agile Way TF


Its actually the Agile way….

Agile Way To F


To...

Agile Way To Fail


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.


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.

What is the top reason behind
Toyota’s success?


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.

So, why is there only one
Toyota?


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?

Context is King!
(or Queen if you like)


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.

Individual Activity

What practices do you think
are indispensable for your
project?

2 mins

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?

Group Activity

What practices do you think
are indispensable for every
project?

5 mins, teams of 5 ppl

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.

Bloat Effect
How often do you take practices out
v/s add new ones?


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, find 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 profits, 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 defined as “the art of maximizing work not done”.

Sacred Agile Practice


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.

Release & Sprint Planning


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

Iterations & Time Boxes


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

Estimation

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?

Sustainable Pace


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.

Daily Scrum/Stand-up
Meetings


Clean Code
TDD, Refactoring, Simple Design


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?

Requirements
Use cases, User Stories, Epics, Personas


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

Retrospectives


Kiazen v/s Kiakaku
Retrospective coherence

Quality Assurance


Cease Inspection

Building Quality into the Process


Cease Inspection

Individual Activity

Now what practices do you
think can be thrown out of your
project?


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?

Thank You!
(for real this time)

No monkeys were harmed in the making of this presentation.
This presentation was made using only recycled pixels


Monkey See Monkey Do

More Related Content

Similar to Monkey See Monkey Do

More from Naresh Jain

Recently uploaded

Monkey See Monkey Do