monkey see monkey do
Post on 18-Oct-2014
13.666 views
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
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
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.
Backlog
3Thursday 4 February 2010
Lets take a closer look at the stories in our backlog
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
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.
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.
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
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!
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.
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.
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.
Adaptive Planning
11Thursday 4 February 2010
Let’s look at our <sarcasm>wonderful adaptive plan</sarcasm>
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.
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.
Story: Freeze on Workshop Title
14Thursday 4 February 2010
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.
Story: Freeze on Workshop Title
16Thursday 4 February 2010
That was easy!
Story: Write workshop Abstract
17Thursday 4 February 2010
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.
Story: Write workshop Abstract
19Thursday 4 February 2010
With the Title and Abstract in place, we submitted our proposal to Agile India
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.
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.
a NEW story!
22Thursday 4 February 2010
And hence we had to create a new story which was not planned for.
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
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>.
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.
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.
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.
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.
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>)
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.
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>.
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>
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)
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.
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.
Story: Workshop Outline
36Thursday 4 February 2010
This was a very important story. Lets see what we’ve got done here...
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?
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.
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.
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.
Story: Customer Delight
41Thursday 4 February 2010
Acceptance Criteria?
42Thursday 4 February 2010
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?
43Thursday 4 February 2010
What does it mean to delight our customers?
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>
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.
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.
Story: Workshop Outline
47Thursday 4 February 2010
Ohh… yes, we need to work on the workshop outline. The hung-over story.
48Thursday 4 February 2010
Oops… <sarcasm>We are done with all our Pomodoros</sarcasm>.
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.
So this is where we are with our presentation!
50Thursday 4 February 2010
How do you think we performed?
51Thursday 4 February 2010
That brings us to the REAL title of our talk…...
52Thursday 4 February 2010
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>
Agile Way TF
54Thursday 4 February 2010
Its actually the Agile way….
Agile Way To F
55Thursday 4 February 2010
To...
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.
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.
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.
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?
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.
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?
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.
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”.
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.
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
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
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?
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.
Daily Scrum/Stand-up Meetings
69Thursday 4 February 2010
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?
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
Retrospectives
72Thursday 4 February 2010
Kiazen v/s KiakakuRetrospective coherence
Quality Assurance
73Thursday 4 February 2010
Cease Inspection
Building Quality into the Process
74Thursday 4 February 2010
Cease Inspection
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?
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