monkey see monkey do

77
Monkey See Monkey Do! Sandeep Shetty Directi Naresh Jain Industrial Logic Released under Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License 1 Thursday 4 February 2010 Image Src: http://itre.cis.upenn.edu/~myl/languagelog/archives/chimp.jpg

Post on 18-Oct-2014

13.666 views

Category:

Technology


1 download

DESCRIPTION

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

TRANSCRIPT

Page 1: Monkey See Monkey Do

Monkey See Monkey Do!

Sandeep ShettyDirecti

Naresh JainIndustrial Logic

Released under Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License

1Thursday 4 February 2010

Image Src: http://itre.cis.upenn.edu/~myl/languagelog/archives/chimp.jpg

Page 2: Monkey See Monkey Do

As an agile presenter,I want to create a backlog,

So that we can actually get it done!

5 Nuts100 BV

Backlog for the Workshop

2Thursday 4 February 2010

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

Page 3: Monkey See Monkey Do

Backlog

3Thursday 4 February 2010

Lets take a closer look at the stories in our backlog

Page 4: Monkey See Monkey Do

As a presenter,I want to select a title for the talk,

So that it is attractive to the conference attendees

1 Nut500 BV

Freeze on Workshop Title

4Thursday 4 February 2010

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

Page 5: Monkey See Monkey Do

As a presenter,I want to come up with an

interesting abstract for the talk along the conference theme,

So that it gets accepted

10 Nuts500 BV

Write Workshop Abstract

5Thursday 4 February 2010

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

Page 6: Monkey See Monkey Do

As a presenter & co-presenter,we want an outline,

So that we can start creating the content for the workshop

15 Nuts700 BVWorkshop outline

6Thursday 4 February 2010

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

Page 7: Monkey See Monkey Do

As a co-presenter,I want the slides to be usable,

So that my message is conveyed clearly to the conference attendees

2 Nuts200 BV

Slide Usability

7Thursday 4 February 2010

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

Page 8: Monkey See Monkey Do

As a conference attendee,I want to learn something new,

So that I’m delighted

35 Nuts2500 BVCustomer Delight

8Thursday 4 February 2010

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

Page 9: Monkey See Monkey Do

As a presenter,I want to create workshop content,

So that we can conduct the workshop

30 Nuts2100 BV

Workshop Content

9Thursday 4 February 2010

This was the most obvious story.

Page 10: Monkey See Monkey Do

Analysis Paralysis

10Thursday 4 February 2010

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

Page 11: Monkey See Monkey Do

Analysis Paralysis

10Thursday 4 February 2010

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

Page 12: Monkey See Monkey Do

Adaptive Planning

11Thursday 4 February 2010

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

Page 13: Monkey See Monkey Do

Sprint 1Velocity 12

Capacity 5 hrs

Freeze on workshop title 1 point 500 BV

Write workshop abstract 10 points 500 BV

Stories

12Thursday 4 February 2010

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.

Page 14: Monkey See Monkey Do

Stor

y Po

ints

Sprints

Burn Down

13Thursday 4 February 2010

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

Page 15: Monkey See Monkey Do

Story: Freeze on Workshop Title

14Thursday 4 February 2010

Page 16: Monkey See Monkey Do

Workshop title:F**k that Sh*t

15Thursday 4 February 2010

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

Page 17: Monkey See Monkey Do

Story: Freeze on Workshop Title

16Thursday 4 February 2010

That was easy!

Page 18: Monkey See Monkey Do

Story: Write workshop Abstract

17Thursday 4 February 2010

Page 19: Monkey See Monkey Do

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

18Thursday 4 February 2010

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.

Page 20: Monkey See Monkey Do

Story: Write workshop Abstract

19Thursday 4 February 2010

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

Page 21: Monkey See Monkey Do

Stor

y Po

ints

Sprints

Burn Down

20Thursday 4 February 2010

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.

Page 22: Monkey See Monkey Do

Customer Feedback

21Thursday 4 February 2010

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.

Page 23: Monkey See Monkey Do

a NEW story!

22Thursday 4 February 2010

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

Page 24: Monkey See Monkey Do

As a Presenter,I need to change the talk title,

So that it is not offensive to the prospective conference attendees

3 Nut300 BV

Change Offensive Title

23Thursday 4 February 2010

Added it to our Backlog

Page 25: Monkey See Monkey Do

Stor

y Po

ints

Sprints

Burn Down

24Thursday 4 February 2010

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

Page 26: Monkey See Monkey Do

Sprint 2Velocity 20

Capacity 10 hrs

Change Offensive Title 3 points 300 BV

Slide Usability 2 points 200 BVWorkshop Outline 15 points 700 BV

Stories

25Thursday 4 February 2010

After the grand success of our first 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.

Page 27: Monkey See Monkey Do

Story: Change Offensive Title

26Thursday 4 February 2010

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.

Page 28: Monkey See Monkey Do

Janta ki Adalat mein aaj Agile Practices

Escaping the cage

Which Agile Practices? - A Practitioner's Dilemma

Practices, Practices, Practices

Shut-up and Do

Zen-gile

Enterprise Agile

27Thursday 4 February 2010

We got a lot of wonderful suggestions from people.

Page 29: Monkey See Monkey Do

New workshop title:Monkey See Monkey Do!

28Thursday 4 February 2010

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.

Page 30: Monkey See Monkey Do

Story: Change Offensive Title

29Thursday 4 February 2010

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

Page 31: Monkey See Monkey Do

Story: Slide Usability

30Thursday 4 February 2010

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.

Page 32: Monkey See Monkey Do

http://perl.plover.com/yak/presentation/samples/notes.html#sl-8http://www.garrreynolds.com/Presentation/slides.htmlhttp://www.businessweek.com/smallbiz/content/jan2008/sb20080125_269732.htmhttp://www.youtube.com/watch?v=O5J0THtnPiAhttp://www.goarticles.com/cgi-bin/showa.cgi?C=1542910

Research

31Thursday 4 February 2010

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

Page 33: Monkey See Monkey Do

The quick brown fax jumped over the the daisy dog

32Thursday 4 February 2010

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 fix this now. Its embarrassing. Fuck… I mean... Fixed. Updated. Checked In and Kick off another build. </sarcasm>

Page 34: Monkey See Monkey Do

http://waitingforbuild.com/

33Thursday 4 February 2010

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

Page 35: Monkey See Monkey Do

The quick brown fox jumped over the the lazy dog

34Thursday 4 February 2010

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

Page 36: Monkey See Monkey Do

Story: Slide Usability

35Thursday 4 February 2010

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

Page 37: Monkey See Monkey Do

Story: Workshop Outline

36Thursday 4 February 2010

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

Page 38: Monkey See Monkey Do

Double-click to edit

37Thursday 4 February 2010

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?

Page 39: Monkey See Monkey Do

Hang Over!@#$@$$@#

38Thursday 4 February 2010

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.

Page 40: Monkey See Monkey Do

Stor

y Po

ints

Sprints

Burn Down

39Thursday 4 February 2010

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.

Page 41: Monkey See Monkey Do

Sprint 3

Velocity 45

Capacity 20 hrs

Customer Delight 35 points 2500 BV

Workshop Outline 15 points 700 BV

Stories

40Thursday 4 February 2010

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.

Page 42: Monkey See Monkey Do

Story: Customer Delight

41Thursday 4 February 2010

Page 43: Monkey See Monkey Do

Acceptance Criteria?

42Thursday 4 February 2010

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

Page 44: Monkey See Monkey Do

How will we know if the customer is delighted?

43Thursday 4 February 2010

What does it mean to delight our customers?

Page 45: Monkey See Monkey Do

Metrics

44Thursday 4 February 2010

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

Page 46: Monkey See Monkey Do

Thank You!

45Thursday 4 February 2010

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.

Page 47: Monkey See Monkey Do

Story: Customer Delight

46Thursday 4 February 2010

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

Page 48: Monkey See Monkey Do

Story: Workshop Outline

47Thursday 4 February 2010

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

Page 49: Monkey See Monkey Do

48Thursday 4 February 2010

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

Page 50: Monkey See Monkey Do

Stor

y Po

ints

Sprints

Burn Down

49Thursday 4 February 2010

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.

Page 51: Monkey See Monkey Do

So this is where we are with our presentation!

50Thursday 4 February 2010

Page 52: Monkey See Monkey Do

How do you think we performed?

51Thursday 4 February 2010

Page 53: Monkey See Monkey Do

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

52Thursday 4 February 2010

Page 54: Monkey See Monkey Do

Agile WTF

53Thursday 4 February 2010

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

Page 55: Monkey See Monkey Do

Agile Way TF

54Thursday 4 February 2010

Its actually the Agile way….

Page 56: Monkey See Monkey Do

Agile Way To F

55Thursday 4 February 2010

To...

Page 57: Monkey See Monkey Do

Agile Way To Fail

56Thursday 4 February 2010

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.

Page 58: Monkey See Monkey Do

57Thursday 4 February 2010

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.

Page 59: Monkey See Monkey Do

What is the top reason behind Toyota’s success?

58Thursday 4 February 2010

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.

Page 60: Monkey See Monkey Do

So, why is there only one Toyota?

59Thursday 4 February 2010

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 filling for bankruptcy? Is there a problem with our implementation or is it a bigger problem?

Page 61: Monkey See Monkey Do

Context is King! (or Queen if you like)

60Thursday 4 February 2010

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.

Page 62: Monkey See Monkey Do

What practices do you think are indispensable for your

project?

2 mins

Individual Activity

61Thursday 4 February 2010

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?

Page 63: Monkey See Monkey Do

What practices do you think are indispensable for every

project?

5 mins, teams of 5 ppl

Group Activity

62Thursday 4 February 2010

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.

Page 64: Monkey See Monkey Do

Bloat EffectHow often do you take practices out

v/s add new ones?

63Thursday 4 February 2010

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

Page 65: Monkey See Monkey Do

Sacred Agile Practice

64Thursday 4 February 2010

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.

Page 66: Monkey See Monkey Do

Release & Sprint Planning

65Thursday 4 February 2010

Coordination - inside & outsideManaging uncertainty Optimal resource utilization

Adaptive PlanningPlanning is important, but plans are use lessWe plan to deliver not deliver to planEnds up leading to a lot of overheadPlans gives you a false sense of certainty and end up building walls between teams

Continuous Flow

Page 67: Monkey See Monkey Do

Iterations & Time Boxes

66Thursday 4 February 2010

To avoid Thrashing To get commitment

-veBatching - Capacity Utilization centric rather than through-put centric, leads to inventoryLeads to a min-waterfallCommitment & fixed time box - leads to effort estimation - which leads to analysis & design upfront & buffering

Page 68: Monkey See Monkey Do

Estimation

67Thursday 4 February 2010For years I thought I was a poor developer because I could not estimate wellPredictability ParadoxLack of trustBufferingStudent SyndromeOptimism biasSophisticationDead Lines?

Page 69: Monkey See Monkey Do

Sustainable Pace

68Thursday 4 February 2010

Sustainable Pace as defined 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.

Page 70: Monkey See Monkey Do

Daily Scrum/Stand-up Meetings

69Thursday 4 February 2010

Page 71: Monkey See Monkey Do

Clean CodeTDD, Refactoring, Simple Design

70Thursday 4 February 2010

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?

Page 72: Monkey See Monkey Do

RequirementsUse cases, User Stories, Epics, Personas

71Thursday 4 February 2010

Want v/s NeedRequirements belongs to the solution domainBusiness Analysis capturing the requirements, it reminds me of waiters in a restaurantInstead of personas, lets get our product idea out there and get feedback from real users

Page 73: Monkey See Monkey Do

Retrospectives

72Thursday 4 February 2010

Kiazen v/s KiakakuRetrospective coherence

Page 74: Monkey See Monkey Do

Quality Assurance

73Thursday 4 February 2010

Cease Inspection

Page 75: Monkey See Monkey Do

Building Quality into the Process

74Thursday 4 February 2010

Cease Inspection

Page 76: Monkey See Monkey Do

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

project?

Individual Activity

75Thursday 4 February 2010

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?

Page 77: Monkey See Monkey Do

Thank You!(for real this time)

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

76Thursday 4 February 2010