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

Backlog Thursday 4 February 2010 3 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 Thursday 4 February 2010 4 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 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.

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.

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

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!

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.

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.

Adaptive Planning Thursday 4 February 2010 11 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 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.

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.

Story: Freeze on Workshop Title Thursday 4 February 2010 14

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.

Story: Freeze on Workshop Title Thursday 4 February 2010 16 That was easy!

Story: Write workshop Abstract Thursday 4 February 2010 17

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.

Story: Write workshop Abstract Thursday 4 February 2010 19 With the Title and Abstract in place, we submitted our proposal to Agile India

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.

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.

a NEW story! Thursday 4 February 2010 22 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 Thursday 4 February 2010 23 Added it to our Backlog

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

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.

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.

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.

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.

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

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.

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

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>

http://waitingforbuild.com/ Thursday 4 February 2010 33 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 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.

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.

Story: Workshop Outline Thursday 4 February 2010 36 This was a very important story. Lets see what we’ve got done here...

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?

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.

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.

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.

Story: Customer Delight Thursday 4 February 2010 41

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.

How will we know if the customer is delighted? Thursday 4 February 2010 43 What does it mean to delight our customers?

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>

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.

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.

Story: Workshop Outline Thursday 4 February 2010 47 Ohh… yes, we need to work on the workshop outline. The hung-over story.

Thursday 4 February 2010 48 Oops… <sarcasm>We are done with all our Pomodoros</sarcasm>.

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.

So this is where we are with our presentation! Thursday 4 February 2010 50

How do you think we performed? Thursday 4 February 2010 51

That brings us to the REAL title of our talk…... Thursday 4 February 2010 52

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>

Agile Way TF Thursday 4 February 2010 54 Its actually the Agile way….

Agile Way To F Thursday 4 February 2010 55 To...

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.

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.

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.

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?

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.

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?

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.

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

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

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

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?

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.

Daily Scrum/Stand-up Meetings Thursday 4 February 2010 69

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?

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

Retrospectives Thursday 4 February 2010 72 Kiazen v/s Kiakaku Retrospective coherence

Quality Assurance Thursday 4 February 2010 73 Cease Inspection

Building Quality into the Process Thursday 4 February 2010 74 Cease Inspection

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?

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

http://agilefaqs.com	33
http://www.lmodules.com	6
http://www.agilefaqs.com	1

Monkey See Monkey Do

by Naresh Jain on Jan 29, 2010

Accessibility

Categories

Tags

Upload Details

Usage Rights

3 Embeds 40

Statistics

Monkey See Monkey Do — Document Transcript