tag:blogger.com,1999:blog-453031041068049872024-02-06T20:45:23.856-08:00Business AnalysisAnonymoushttp://www.blogger.com/profile/03105245771080772055noreply@blogger.comBlogger50125tag:blogger.com,1999:blog-45303104106804987.post-50165162715257024232012-10-01T18:13:00.003-07:002012-10-09T14:40:15.344-07:00The ethics of missed callsThoughtWorks is a crazy place. You're walking on thin rope all the time and there's super opiniated crowds on both sides who will eat you alive if you take one wrong step. Most of these arguments are <a href="http://jimhighsmith.com/2012/08/28/embracing-paradox/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+AgileImagineering+%28Jim+Highsmith+%7C+Agile+Imagineering%29&utm_content=Google+Reader" target="_blank">paradoxical</a> as described by Jim Highsmith, and get boring and repetitive very soon... "growth", "specialization", etc. Then there are arguments that are totally futile and endless. Like the lunch served in the India offices. People can go on arguing about how they like OR don't like the "current" caterer and obviously never get anywhere because people have different tastes in food and there's no caterer in the world that will be able to make everyone happy.<br />
<br />
But every once in a while a really nice juicy argument comes along and makes it all worth the while :)<br />
<br />
<h2>
Missed calls</h2>
Missed Calls were (are?) a big part of the Indian (youth) culture when I was going through college. Cellphones were getting cheap enough for college kids to carry one, but call rates were not cheap in any sense of the word. In that situation missed calls were a legitimate form of communication.<br />
<ol>
<li>Giving missed calls to the "wealthy" party so they could call back and bear the cost of the call. This worked well with parents :D and sometimes with wealthy / generous friends.</li>
<li>Giving missed calls to indicate yes / no (one ring = yes, two = no). Useful in all manners of covert transactions including flirting with guys / girls from orthodox families that WOULD NOT allow calls from friends of the opposite sex. err... yes this is true.</li>
<li>Giving missed calls to indicate "I'm here". When you were meeting a friend and expected him/her to come down / out of the house so you can get going, you don't go to the house. That's weird; a waste of time; a thing to avoid at all costs (exchanging pleasantaries with the friend's family, having a bit of snack / tea offered to you, sharing awkward silence with your friend's super cute sibling, etc). So you give a missed call meaning "Waiting downstairs. Let's go."</li>
</ol>
There are several other examples of using missed calls to communicate important stuff. If you picked up your friends call before three rings it was considered treason. It meant you were out to get your friend and in complete violation of the "code"!<br />
<br />
<h2>
A question of ethics!?</h2>
Apparently the US is new to all this. No one in the US gives missed calls. People just talk. How boring. But when this subject came up couple of weeks back in the TW NY Office, one of the arguments presented was around ethics!! The argument was something like this...<br />
<blockquote class="tr_bq">
Although the missed call is free to you, the telecom company incurs cost to connect the call and so it is unethical to use missed calls to communicate because you are not paying the telephone company!!</blockquote>
My very first reaction was, of course, "That's a ridiculous argument!!". After thinking about it long and hard I my reaction changed to "It really is a ridiculous argument!!". I vehemently believe that missed calls are legitimate and you are a fool not to use them. You are totally within your rights & not doing anything illegal. Its the contract that the phone company signed up for and so if you can legitimately use the exploit in the system. I consider is <a href="http://randomfoo.net/oscon/2002/lessig/free.html" target="_blank">"Fair Use"</a>. <i>(listen to that regardless; its a masterpiece)</i><br />
<br />
Its not like the <a href="http://en.wikipedia.org/wiki/Missed_call" target="_blank">phone companies don't know about this.</a> They can't do anything because of a deadlock in a competitive market. If one of them starts monetizing missed calls the others will eat it alive and gain significant market shares.<br />
<br />
<h2>
The catch</h2>
There is however a roadblock I faced while making this argument. I was looking for other examples of this behavior (using the free part of a service to gain benefit) and I couldn't find a single one! I know its impossible but you have to help me out here. Missed calls are at stake! Is this really the last legitimate exploit that we have on out hands? Are we so boring? Say its not true...<br />
<br />
<b>UPDATE: </b>A friend pointed me to <a href="http://www.thisamericanlife.org/radio-archives/episode/473/loopholes" target="_blank">this episode of "This American Life"</a> that explores the question of loopholes and ethics at a much deeper level than missed calls.Anonymoushttp://www.blogger.com/profile/03105245771080772055noreply@blogger.com8tag:blogger.com,1999:blog-45303104106804987.post-82079247060251415762012-09-20T16:56:00.001-07:002012-09-28T20:14:29.844-07:00Laundry<i>Its sad that my first post after so many months has to be a rant but I am infuriated by this stupid laundry card system. Someone should be shot multiple times for inventing this and making innocent travelers become victims of this insanity.</i><br />
<i><br /></i>
<i>To be sure, I mean this rant as a view into one of the most ill-designed system that I have come across. As software professionals and entrpreneurs, we have to keep in mind what our users have to go through to use our systems.</i><br />
<br />
I move into my New York apartment 2 weeks back. I find a series of instructions. The ones around laundry are the most incomprehensible but "I'll cross that bridge when I have to..." I say. Two days back I decide that I have to get the laundry done and so the battle begins.<br />
<br />
<h3>
1) RTFM</h3>
The instructions tell me to<br />
<ol>
<li>locate the laundry card stuck to my refrigerator </li>
<li>go to www.sdirevalue.com and add money to it</li>
<li>go to the building across the street to "activate" it </li>
<li>and then go to my basement and wash my clothes.</li>
</ol>
<i>(Weird. But hey I'm new in New York. Maybe this is some really intelligent system so let me play along.)</i><br />
<br />
<h3>
2) 1st problem</h3>
sdirevalue.com asks me to "Create a new account". Whatever. I got to get these clothes washed. I register.<br />
<br />
Now it asks me at "Add a card" to my profile. I guess that makes sense. So I enter the serial number of the card as required. "This card is already associated to another users account" it says...<br />
<br />
<i>(Obviously the last resident didn't think of de-registering this card from his account. Neither would I. Its stupid to expect that someone would remember to de-register their effing laundry card when moving out!!!)</i><br />
<br />
<h3>
3) Customer Support</h3>
I call customer support but they close at 5pm so I have to wait till the next day. When I call them the next day they tell me it will take two days to give me a new card. <i>(Sigh... what option do I have?)</i><br />
<br />
Two days later I see two cards dropped in my apartment.<br />
<br />
<i>(Obviously this is a well known problem and there is a possibility that the second card will turn out to be "Already Registered". So they gave a third one just in case. Great!)</i><br />
<br />
<h3>
4) I need to blog about this</h3>
So I try to add the second card. It works!! <i>(I don't have to wear formals to ThoughtWorks tomorrow like I did today!! I will have washed clothes.)</i><br />
<br />
But alas its not so easy.<br />
<br />
When I click on "Revalue" which I can only assume adds credit to this card, this site asks me to enter the code on some machine that looks like this.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi2nlhq1yVWQBzBU8hhGcrIDVazOvbEVq_XFAYrOXRTzgBRMQzLSc3wxbX_VwXE3HB1xADljLW_Yt6b6K9iuj34mH3aidteqKDFgev3g3TI_8CL8aWfpLULpvyjt2e2jA6f1-50U0p9mPQ/s1600/CVA+ID.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="282" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi2nlhq1yVWQBzBU8hhGcrIDVazOvbEVq_XFAYrOXRTzgBRMQzLSc3wxbX_VwXE3HB1xADljLW_Yt6b6K9iuj34mH3aidteqKDFgev3g3TI_8CL8aWfpLULpvyjt2e2jA6f1-50U0p9mPQ/s320/CVA+ID.jpg" width="320" /></a></div>
<br />
<br />
What. The. Fuck???<br />
<br />
I'm <strike>assuming</strike> hoping this machine is in my basement OR the building across the street where I'm supposed to "activate" my card. So now I have to<br />
<ol>
<li>go to this machine</li>
<li>find the serial number </li>
<li>come back and enter it on this site</li>
<li>add value to my card (like that's going to be straightforward)</li>
<li>go wash my clothes.</li>
</ol>
I have no idea what fresh hell am I to expect. But I am determined to get laundry done today. Unless of course if I end up requiring customer support... cause those happy people are at home prancing about in their fresh clothes...<br />
<br />
Who came up with this shit?? No wonder there's still debates about gun control in America.<br />
<br />
<i>Even as I'm publishing this I'm hoping I'm wrong. There must be some higher purpose for me taking these pains to do laundry (apart from being merciful to my fellow subway commuters). I hope someone comments and lets me know what this higher purpose is. But I don't think it likely.</i><br />
<br />
UPDATE: This isn't over yet.<br />
<br />
I went to the other building and found the code on this machine and added money to my card. One would have thought he could wash his clothes at last... but NO!!<br />
<br />
The money that I added is being "held" by this company. They have given me a "Revalue Code". Now I have go to the other building and enter the revalue code in the machine. That will actually add the amount to my card. Oh and the "Revalue Code" expires in 7 days!!!<i><br /></i>Anonymoushttp://www.blogger.com/profile/03105245771080772055noreply@blogger.com1tag:blogger.com,1999:blog-45303104106804987.post-24504210852667486282012-09-20T08:09:00.000-07:002012-09-20T09:57:18.180-07:00And we're backFor several very good reasons, I made a move to wordpress about an year back. But the google ranking for this blog never went down. It ranked second on a search for "akshay dhavle" after more than a year of having a single post saying the blog had moved!<br />
<br />
90% of the traffic to the new blog was referral traffic from agileanalysis.blogspot.com :(<br />
<br />
The other stupid mistake I made was two merge my business analysis blog with my everything else blog. It diluted the content significantly.<br />
<br />
So here we are. I am back to the "new & improved" blogger platform which is essentially as crappy as it was earlier if not worse. I hate the templates, I hate the lack of customizations, I hate how much "post-production" work I have to do after writing a post just to make headings and paragraphs work the way they are supposed to. I hope it'll get better.<br />
<br />
But I am happy that I will be posting more regularly about business analysis.Anonymoushttp://www.blogger.com/profile/03105245771080772055noreply@blogger.com0tag:blogger.com,1999:blog-45303104106804987.post-8412576598386250472011-04-17T08:51:00.000-07:002012-09-20T07:30:13.061-07:00The Sichuan RestaurantI am in Bangalore for an agile training for a client. I'm staying near our office in Koramangala so I went to this chinese restaurant called "Sichuan" near Raheja Residency for dinner. First of all let me say that its a really good restaurant. If I had to nitpick, it was a bit warm in there but that's about it. Food, ambience, service, rates, everything is very nice.<br />
<br />
I had a soup and a main course that was delicious. Even the fresh lime soda was nice. So I am absolutely positive that they can serve excellent desserts as well.<br />
<br />
But... there's a Natural's ice cream store just next door!! (Natural's is a very well established brand in India). I overheard the waiter ask at least 4 customers if they'd like to have dessert and they all very frankly told the waiter that they would have it next door. No offense meant and none taken either!<br />
<br />
The Sichuan restaurant clearly has two choices.<br />
<ol>
<li>Make better dessert than the Naturals chain<br />OR</li>
<li>Strike a deal with naturals so that they either serve natural's ice cream at the restaurant / give some kind of discount on naturals ice cream if you've dined at Sichuan</li>
</ol>
What would you do as the owner of the Sichuan restaurant?Anonymoushttp://www.blogger.com/profile/03105245771080772055noreply@blogger.com4tag:blogger.com,1999:blog-45303104106804987.post-50870221662216205982011-04-16T04:30:00.000-07:002013-03-05T19:26:12.551-08:00The Project OwnerI recently paired on an <a href="http://www.thoughtworks-studios.com/services/agile-foundations" target="_blank">Agile Fundamentals</a> training for an organization. Its a two day course in agile philosophy, principles and basic practices offered by ThoughtWorks Studios. Its more of an awareness programme than training that you can put to use in your daily life. This makes sense as any two-day training that promises "take-away"s that can directly be applied to your situation is probably bogus.<br />
<br />
Although the training itself is pretty much "canned" in terms of material, the discussions that happen over those two days are very important. In discussing various aspects with people from this organisation, I saw another instance of an engagement setup anti-pattern.<br />
<br />
There were multiple stakeholders in the client organization (there always are) and the IT team was dealing with all of them. There were a lot of conflicting priorities, priorities changed while development was going on, people who made decisions went away and new people made opposite decisions due to lack of context, etc. Here's where I think the problems is but first lets talk about the product owner role for a bit and then we can discuss how this ought to work in a services context.<br />
<br />
<h2>
<span style="font-weight: normal;">The Product Owner</span></h2>
In my view a product owner role is defined by two simple characteristics:<br />
<ol><br />
<li>She has absolute authority over what features go into the product.</li>
<br />
<li>She is absolutely responsible if the product doesn't work.</li>
</ol>
<br />
<span style="font-family: Georgia, 'Bitstream Charter', serif; font-size: 16px; line-height: 24px;">To satisfy these conditions, the product owner will show several behaviors.</span><br />
<ul><br />
<li>Has a clear vision of what the product should be</li>
<br />
<li>Knows exactly what the product is currently capable of doing</li>
<br />
<li>Knows the target market (user segment) and the trends in that market</li>
<br />
<li>Takes inputs from the organization, the development team, the marketing guys, the market itself and base</li>
<br />
<li>Based on such inputs, is able to prioritize between planned features, bugs and new ideas</li>
</ul>
<br />
For a product, this role is absolutely necessary. And companies usually don't go wrong there. But when companies set themselves up for running a project, they usually miss this role. It leads to a lot of heartache for everyone and needs to be taken seriously while setting up the project governance.<br />
<br />
<h2>
<span style="font-weight: normal;">The "Project" Owner (for lack of a better name)</span></h2>
Let me try to explain what this role should do in a project context. I will also add some context around each point and why I think its important.<br />
<br />
1) The Project Owner <b>should ideally be from the client organization</b><br />
<ul><br />
<li style="font-weight: bold;"><span style="font-weight: normal;">Since the product owner is supposed to be the absolute authority on what features are developed, he should be part of the client organization.</span></li>
<br />
<li style="font-weight: bold;"><span style="font-weight: normal;">If the product is not external facing, it is probably going to be used by employees of the organization. An internal person will be able to understand their needs better</span></li>
</ul>
<br />
2) The Project Owner <b>should be fully involved in the development process</b><br />
<ul><br />
<li>To understand the current capabilities and gaps in the product, the product owner should be fully involved in the development.</li>
<br />
<li>She should attend all the showcases, test the application and give feedback to the development team</li>
<br />
<li>She should be involved in story discussions so that she can give inputs about the best way to achieve a piece of functionality based on her knowledge of the user base</li>
</ul>
<br />
3) The Project Owner <b>should have complete authority and responsibility</b><br />
<ul><br />
<li>She should be the Business Sponsor herself (possible in small startup like companies) OR be someone who is completely trusted by the business sponsor.</li>
<br />
<li>She will take inputs from various parties but will decide what to do herself.</li>
<br />
<li>She will have to have a strong personality to negotiate within various stakeholders in the client organization to make sure the product stay true to its purpose and doesn't go off track because one of the stakeholders shouts louder. <span style="font-weight: normal;"> </span></li>
</ul>
<span style="font-weight: normal;"> </span><br />
<h3>
<span style="font-weight: normal;">Common arguments and pitfalls</span></h3>
<i>If I am an IT vendor and I ask my client to create this new (almost full time) role, why would they listen?</i>Well, it can turn out to be a tough conversation with some clients. But the basic idea is the same. The way you ask for time commitment from the client, you should also ask for such a role. Its in everyone's best interest. For some clients, you might need to prove the requirement before you ask for someone to take on the role.<br />
<br />
<i>Can it be someone from the IT organization?</i>Well... its better than having no one I guess. But its not ideal because there's a lot of client context required for the role. Maybe a smart BA/PM who is permanently stationed at the client site can do it but its not where you want to go.Anonymoushttp://www.blogger.com/profile/03105245771080772055noreply@blogger.com4tag:blogger.com,1999:blog-45303104106804987.post-172999650672458102011-04-12T12:33:00.000-07:002012-09-20T07:03:07.280-07:00Iterations, Batches and Flow<br /><br />I've recently had a lot of conversations with people who are thinking of iterations as batches. By definition that's what they are. You sign up for a "batch" of stories, at the beginning of the iteration, and you deliver them by the end of that iteration. However, it is useful to think of requirements (stories) as units of work that flow through the value stream. Here is why I think so.<br /><br /><h2>
What is a batch? </h2>
<blockquote class="tr_bq">
"A batch is a group of items that will be processed at once as a single unit"</blockquote>
<br />Items are usually batched to achieve "economies of scale". This usually means that there are some overhead activities associated with the items in question and it is better to distribute the cost of such activities over a batch of items than to perform such activities for each individual item. A good example is transportation. It is always more economical to transport a whole container full of items than to transport individual items.<br /><br /><br /> You can batch items up at various levels. Coming back to the software world, you could batch requirements (stories) at an iteration level, at a release level or even at a project level if you must. That's what classic waterfall does, it batches requirements at the project level. But the point is, you need to work on the whole batch at once at each step of the process. Which means you'd prioritize the whole batch, analyse the whole batch, develop the whole batch, test the whole batch and then deploy the whole batch.<br /> <br />
<h2>
So what's the big problem?</h2>
<br />Well, by batching items, you are limiting what you can do with each of them individually because as we discussed you have to process a whole batch at once. So where you could have prioritized, analysed, developed, tested and deployed individual requirements (stories), you can now prioritize, analyze, develop, test and deploy only iterations, releases or entire projects.<br />
<br />
<h2>
Flow</h2>
Instead, think about requirements (stories) continuously flowing through the value stream. This way you can assess individual requirements and make sure that only the most valuable make it into the value stream. Then you can analyze, develop, test and deploy these faster because they are small. Now all you need to do is take stock of how your team is doing at regular intervals. This is the time when you would showcase to your client stakeholders, check your throughput for the given time (velocity OR number of stories), have a retrospective, brainstorm technical approach, assess technical debt, etc.<br /> <br />
<h3>
And what about those "economies of scale"?</h3>
<br /> You do lose out on them to some extent. But here are two points to make you feel better because economies of scale are overrated anyways (at least in context of software development).<br /><br /><br /> <b>Firstly</b>, remember that the more you do of something, the better you get at it. So by doing small parts of the overhead activities, you get better and faster at those activities and they don't remain such a big cost anymore. For example, take deployment as an overhead activity. The whole process of deploying to production is usually so tedious and time-consuming that you prefer to do it only when you have a sizable "batch" of features to be deployed. But if you start deploying each story to production, you will have to better that tedious process. You will have to automate most of the deployment. You will have to automate most of the testing. After 10-15 stories are deployed this way, the process will not remain tedious anymore.<br /><br /><br /> <b>Secondly</b>, stop thinking of it as extra cost and start thinking about is as the price the business pays for being able to delay decisions and for getting the opportunity to course-correct. <br />
<br />
<h4>
Example:</h4>
Let's say you were developing a feature which was split in 10 stories. After deploying the first 3, which formed the minimum marketable feature (MMF), you saw that your users are not using the feature as expected. You either need to change the approach for the remaining 7 stories OR you need to stop working on that feature altogether because, given the users' response, other features have become more valuable.<br /><br /> As business, you would have saved some time & money if you had waited for all the 10 stories to be finished and then deployed. But those savings are insignificant compared to first hand user feedback about the feature and the chance to act based on that information.<br /><br /> As the development team, don't feel bad because your efforts on the first 3 stories were wasted. They weren't. You invested that time and effort to find out whether that feature works for your business. You already got more than what you bargained for.<br /><br />
<h2>
So what about iterations?</h2>
Have them by all means. But don't worry about hangover*. Don't try to sign up and finish a particular set of stories in the same iteration. If you can well and good. But what you are really aiming for is to perform consistent amount of work every iteration. <br /><br /> *So as long as your hangover remains constant you are good. If its increasing, you need to change your approach. For example by signing up for lesser stories.Anonymoushttp://www.blogger.com/profile/03105245771080772055noreply@blogger.com0tag:blogger.com,1999:blog-45303104106804987.post-5835317908737172952011-02-14T12:18:00.000-08:002012-10-03T12:17:12.691-07:00Where do RFPs come from?<h2>
Once upon a time in a big corporation...</h2>
<b>Mr. X</b> (you know? the one who does all the work) : <i>Aaaaaargh! I am fed up of watching this screen 24x7 just to let Mr. Y (the boss) know if I ever see a red dot in the top right corner</i><b> </b><br />
<br />
<b>Mr. Z </b>(co-worker) : <i>Hey we can probably get some software to do that. You should talk to Mr. Y (the boss) about it.</i><b> </b><br />
<br />
<b>Mr. X</b> (to himself) : <i>Sure! that'll get me fired.</i><br />
<br />
So Mr. X doesn't talk to the boss(Mr. Y). But Mr. Z plots an evil plot to get Mr. X out of the way. He tells Mr. Y that they should get software to replace Mr. X.<br />
<br />
The Mr. Y loves the idea.<br />
He makes a presentation to his boss...<br />
who presents it to his boss (as if it was his own idea)...<br />
who arranges for a meeting with Mr. P (a guy he knows in the IT department)...<br />
who rants for the full duration of the meeting about how he doesn't have any time / resources to build new software.<br />
<br />
Mr. P then goes and whines about it to his boss (Mr. Q)<br />
who says he has some money left from this years budget that needs to be spent. "Let's get the software built by a vendor" he says.<br />
<br />
Mr. Q talks to his boss<br />
who tells him he should talk to Purchase department<br />
who tells him he should talk to Legal first to write a request for proposal<br />
who tell them he will need to hire 2 college grads and a really sadistic lawyer to create an incomprehensible document about what needs to be done. He spends all his budget on the college grads and sadistic lawyer and gets a document that totally impresses the Purchase department who awards him with the "King of Kickass RFPs" award.<br />
<br />
Purchase then takes the RFP document and sits/sleeps/(i-dont-want-to-know)s on it for the rest of the year because there is no budget anyway. Then new money arrives in the next year and Purchase floats the RFP.<br />
<br />
It goes to vendors who start acting like they actually understand the whole business and asking difficult questions. Purchase gets scared and calls Mr. Q. However, Mr. Q has left the organization to go and join another one as "Chief RFPist" after his award winning RFP last year. Mr. R has taken his job. He doesn't know head or tail of the RFP in question.<br />
<br />
He talks to his boss who says "Oh! Yeah I remember! So and so had talked to Mr. P last year about replacing his subordinate's subordinate's subordinate's subordinate with a software." Have him talk to the vendors. But Mr. X has already left the agonizing job, Mr. Y is on vacation and Mr. Z is too busy staring at the screen looking for a red dot in the top right corner to be able to get on a call with the vendors.<br />
<br />
So Mr. P talks to the vendors and gives the "requirements". The vendors write more bullshit in their "Response to the Request for Proposal". They too have a couple of grads and a smart ass legal guy. Mr. P then takes all the responses to the purchase and legal department for their recommendation for the cheapest quote with the maximum loopholes and awards the project to the most "suitable" vendor.<br />
<br />
And then they say 70% of IT projects fail.Anonymoushttp://www.blogger.com/profile/03105245771080772055noreply@blogger.com2tag:blogger.com,1999:blog-45303104106804987.post-24758065721784195442010-10-31T02:49:00.000-07:002012-09-19T09:12:22.515-07:00When in a inception...<strong>Everyone is an analyst</strong><br/>Don't get bound by role boundaries. Everyone needs to understand the system. Talk to the clients, ask questions, draw diagrams, make suggestions, understand problems and solve them.<br/><br/><strong>Make sure everyone facilitates sessions at least once</strong><br/>Especially the BAs since they have to interact the most with the clients. Clients need to feel confident about the BAs on the team. Other members should also be actively involved. Don't let a single person be the scribe all the time. The client might ask "why am I paying for this guy" at some point.<br/><br/><strong>Have an intent for each session</strong><br/>and strive to achieve it. Have back up plans ready in case you find that your planned tools / techniques are not working for the client. Fail fast, change your approach, take a break and regroup, but make sure you get the right information out of a session.<br/><br/><strong>Educate the client about the way you work</strong><br/>They should know what it would be like to work with you day-to-day. Clarify time commitments and kind of inputs required from your clients (suggestions during analysis of stories, showcase feedback, testing). Have special sessions that cover methodology. Offline the subject if it comes up elsewhere. It can derail your session plans easily.<br/><br/><strong>Be honest and upfront</strong><br/>About any shortcuts you have taken, any information that you don't have, any help that you need.<br/><br/><strong>Understand each stakeholder</strong><br/>You should know the pressures that they are dealing with, individually. Know how you can help them.<br/><br/><font size="5">Create. Shared. Vision.</font>Anonymoushttp://www.blogger.com/profile/03105245771080772055noreply@blogger.com1tag:blogger.com,1999:blog-45303104106804987.post-32188636868315605242010-07-19T14:21:00.000-07:002012-09-19T09:12:22.515-07:00Livescribe Pulse Smartpen<strong>Ooooh! Ooooooh! I love it!!</strong><br/><br/>This is the <a href="http://www.amazon.com/gp/product/B002DJV83Y?ie=UTF8&tag=httpwwwakshay-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=B002DJV83Y">most awesomest thing</a><img src="http://www.assoc-amazon.com/e/ir?t=httpwwwakshay-20&l=as2&o=1&a=B002DJV83Y" width="1" height="1" border="0" alt="" style="border:none !important; margin:0px !important;" /> I have bought this year.<br/><br/>There are <a href="http://gizmodo.com/386809/review-livescribe-pulse-digital-penrecorder-verdict-its-good-for-notetakers">enough</a> <a href="http://www.youtube.com/watch?v=OU_RKv5zemM">reviews</a> <a href="http://www.pcmag.com/article2/0,1895,2317477,00.asp">online</a> for me not to write one of my own. But I'll mention the most useful features here:<br/><ul><br/> <li> Captures everything I write / draw. This is the basic promise. A very well kept one.</li><br/> <li> Captures good audio. It's not crystal clear or anything, but is it works well in a meeting setting. I recorded three interviews today, alongwith notes. <em>After I get the headset that someone took by mistake, I'll experiment with the more clear 3D recording capabilities.</em></li><br/> <li> It links the audio and notes together so you can replay what you were saying when you wrote a particular word.</li><br/> <li> It searches. Even cursive handwriting.</li><br/> <li> And then there's other fun stuff like drawing a paper piano and playing it. Or using a calculator by tapping the paper calculator on the inside cover of the starter notebook. Or drawing a cross for navigating the pen's main menus. Or bookmarking audio at specific points.</li><br/> <li> It uses dot paper for all the magic. But you are not restricted to the notebooks supplied by the company. You can <strong>print your own dot paper for free</strong> using any half decent printer!<br/></ul><br/><br/>All in all this is going to be very useful. The 2GB storage is more than enough. My 1:02:14 audio session used 12MB. So if you download the data even once a week, you'll be alright.<br/><br/>I'm loving it!Anonymoushttp://www.blogger.com/profile/03105245771080772055noreply@blogger.com1tag:blogger.com,1999:blog-45303104106804987.post-79595547993128354762010-05-23T16:41:00.000-07:002012-09-19T09:12:22.537-07:00Commitments<div style="text-align: justify;">I facilitated immersion for the March 2010 batch alongwith Arun. On the first day we went through the ThoughtWorks values, culture and history. Then had a session on feedback. We value feedback a lot in ThoughtWorks because the way we deliver is based heavily on <b>Constant Feedback</b> and <b>Continuous Improvement</b> (thanks Sarah). One the second day we went through a brief description of the ThoughtWorks way of running projects (based on agile / lean principles). On the third day we were talking about iterations and about the problems with velocity becoming a target rather than remaining as a basis for planning. I was saying that when we sign up for stories, we don't commit to the points signed up for. It is just a guess based on some information (yesterday's weather) and some gut feel. At this point someone asked the question.</div><div style="text-align: justify;"><blockquote>When do we commit? What do you commit to? The client can't just trust you... there needs to be some concrete commitment.</blockquote>I didn't realize how important this question was when it was asked. But thinking about it I see that it is the basis of everything we* do isn't it? The basic agile principle of </div><div style="text-align: justify;"><blockquote>Customer Collaboration over Contract Negotiation</blockquote>The success of a software project does not depend on its completion on time or within budget. It depends on what benefit you get out of it.</div>Anonymoushttp://www.blogger.com/profile/03105245771080772055noreply@blogger.com2tag:blogger.com,1999:blog-45303104106804987.post-65227776336536225562010-03-17T14:34:00.000-07:002012-09-19T09:12:22.539-07:00Number Lust<div style="text-align: justify;">I am an amateur photographer while I am not not hacking project teams and building custom software at ThoughtWorks. Photographers are known to have bouts of <i>lens lust</i>* time and again, especially at the beginning. I realize that some managers seem to have similar urges when it comes to numbers, metrics. They suffer from acute number lust.</div><div style="text-align: justify;"><br /></div><div style="text-align: justify;">In ThoughtWorks, we believe in and encourage self organizing teams. BAs gather requirements, developers write code, QAs test and automate and the customer signs stories off in a flow. <b>The Project Manager role is therefore reduced to making sure that nothing obstructs this flow.</b></div><div style="text-align: justify;"><br /></div><div style="text-align: justify;">The way this would be done is to gather and analyze the right data and take actions based on this analysis. Examples being:</div><div style="text-align: justify;"><ul><li><a href="http://agileanalysis.blogspot.com/2008/12/choose-your-lanes.html">Finding bottlenecks from the wall</a> or a <a href="http://agileanalysis.blogspot.com/2008/12/finger-charts.html">CFD</a> and taking actions to fix the problems.</li><li>Looking critically at retrospective action items and seeing that all those issues are fixed (especially if they are issues outside the teams control, like infrastructure).</li><li>Making sure that the right capabilities exist in the team at the right time. If not, get people from outside, arrange training, etc.</li></ul></div><div style="text-align: justify;">Some PMs are content in gathering just enough data to spot problems. But then there are some who can't get enough data ever.<br /><br />They want to organise the whole world into neat boxes and label them and track anything and everything possible. The walls soon fill up with useless charts with graphs and numbers that the team can't use in any way. The worst part is, there is no analysis done around the data even by the people who gather it. Having people in a 15 member team draw emotional seismographs every iteration and sticking them on the wall is of no use if you are not going to make any decisions based on them.</div><div style="text-align: justify;"><br />Now I agree that gathering all possible information can enlighten us to some extent. But its a matter of marginal utility. If I have to do 5 extra things to do my job, just because we want to gather data, I am not doing it.<br /><br />So guys, here's a humble request. Figure out with your client what kind of data he would like to see. Figure out as a team what you would like to improve and what data needs to be gathered to help you get there. Don't burden your team with things that obstruct OR slow down the flow. Keep it simple and keep it lean.<br /><br />Our job is to provide quality software not elaborate reports.<br /></div><div style="text-align: justify;"><br /></div><div style="text-align: justify;"><i><span class="Apple-style-span" style="font-size:small;"><b>* lens lust</b></span></i><span class="Apple-style-span" style="font-size:small;"> - the dangerous urge to keep buying new, expensive lenses not realizing that its practice that will improve your photography, not lenses!!</span></div>Anonymoushttp://www.blogger.com/profile/03105245771080772055noreply@blogger.com2tag:blogger.com,1999:blog-45303104106804987.post-39956365453689682322010-03-17T05:07:00.000-07:002012-09-19T09:12:22.540-07:00Onsite Business Analyst<div>
<div style="text-align: justify;">
This has come up in various discussions recently and I want to put down my thoughts about the role and responsibilities.</div>
<div style="text-align: justify;">
<br /></div>
<div>
<div style="text-align: justify;">
For a ThoughtWorks team in India (or China) most of the work is offshore agile development. Clients are usually in the UK or the USA. The team is structured as follows:</div>
<div>
<ol>
<li style="text-align: justify;">Offshore PM</li>
<li style="text-align: justify;">Offshore Devs</li>
<li style="text-align: justify;">Offshore QA(s)</li>
<li style="text-align: justify;">Offshore BA(s)</li>
<li style="text-align: justify;"><b>Onsite BA(s)</b></li>
</ol>
<div style="text-align: justify;">
This is how the communication works.</div>
<div style="text-align: justify;">
<br /></div>
<br />
<a href="http://akshaydhavle.com/blog/wp-content/uploads/2010/03/onsite-offshore.png"><img alt="" class="alignnone size-medium wp-image-183" height="180" src="http://akshaydhavle.com/blog/wp-content/uploads/2010/03/onsite-offshore-300x180.png" title="onsite-offshore" width="300" /></a><br />
<div style="text-align: justify;">
<span class="Apple-style-span" style="-webkit-border-horizontal-spacing: 2px; -webkit-border-vertical-spacing: 2px; font-size: medium;"></span><br />
<div style="text-align: justify;">
<span class="Apple-style-span" style="-webkit-border-horizontal-spacing: 2px; -webkit-border-vertical-spacing: 2px; font-size: medium;"><span class="Apple-style-span" style="-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px;"><span class="Apple-style-span" style="-webkit-border-horizontal-spacing: 2px; -webkit-border-vertical-spacing: 2px;">Of course there are other exchanges that take place but the Business Q & A and the Technical Q & A are the most important pieces of concrete information exchanged. </span></span></span></div>
<div style="text-align: justify;">
<span class="Apple-style-span" style="-webkit-border-horizontal-spacing: 2px; -webkit-border-vertical-spacing: 2px; font-size: medium;"><span class="Apple-style-span" style="-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px;"><span class="Apple-style-span" style="-webkit-border-horizontal-spacing: 2px; -webkit-border-vertical-spacing: 2px;"><br /></span></span></span></div>
</div>
<div style="text-align: justify;">
Other companies, even traditional development outfits, have a role called the <b>Onsite co-ordinator. </b>I believe this role facilitates similar discussions (although I hear that they are more technical than business related)</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
The onsite business analyst's main role is to facilitate business and technical discussions between the team sitting offshore and the client. She is not restricted to be just an onsite co-ordinator. She can take up a new stream to analyze by herself. Even feed it to an onsite development team, if there is one. But all this keeping in mind that the main purpose is bridging the communication gap between the client and the development team.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
At the same time the onsite business analyst shouldn't go overboard with this and become a single point of failure. The direct communication lines between the offshore team and client should always be open.</div>
</div>
</div>
</div>
Anonymoushttp://www.blogger.com/profile/03105245771080772055noreply@blogger.com4tag:blogger.com,1999:blog-45303104106804987.post-87513687031785320962010-03-02T03:47:00.000-08:002012-09-19T09:12:22.540-07:00Metrics<div style="text-align: justify;">I have recently come out of a consulting assignment which has given me loads of time to read and think about processes, improvements and effectiveness. (People who follow me on google reader must have noticed). It also had me thinking about introduction of agile into a traditional IT outfit and what would make it more effective.</div><div style="text-align: justify;"><br /></div><div style="text-align: justify;"><b>Top -> Down</b></div><div style="text-align: justify;">The Top -> Down approach is where someone in the top management realizes (or is convinced) that agile is the solution to all their problems and goes on to "mandate" agile. This is not necessarily bad. If the organization hires the right consultants to bring agility into the project teams at the ground level.</div><div style="text-align: justify;"><br /></div><div style="text-align: justify;"><b>Bottom -> Up</b> </div><div style="text-align: justify;">The Bottom -> Up is not really an approach. Its just a team realizing that they can do their stuff better and try to bring in improvements in their team without affecting the organization. This is later, agility may spread into other teams virally and this might trigger an organizational transformation with eventual buy-in from the management.</div><div style="text-align: justify;"><br /></div><div style="text-align: justify;">Here's what I think works best. Like any win-win solution, its a mix of the two extreme approaches described above.</div><div style="text-align: justify;"><br /></div><div style="text-align: justify;"><b>Top -> Down buy-in, Bottom-Up implementation</b></div><div style="text-align: justify;">The management decides, that they require to be agile to meet the market conditions but instead of pushing "agile" down the throats of people below, they let the people on the ground level realize what agile means and how it changes the way the team works. Agile Coaches are useful in this transition. </div><div style="text-align: justify;"><br /></div><div style="text-align: justify;">Sounds simple enough? Well here's the catch. How does the management know that the new process is effective?</div><div style="text-align: justify;"><br /></div><div style="text-align: justify;">The sad part is in a traditional organization's hierarchy, the only interface between the management and the teams is "Reports". Reports on various parameters (metrics) that the management believe should be monitored to see how stuff is going on. Whether the teams embrace agile themselves OR whether management asks teams to be agile, the teams will need to report the right metrics to the management to gain their confidence. If the teams don't do this, the management might start tracking the wrong metrics and hence encourage wrong practices. <a href="http://www.vimeo.com/7849591">What you measure is what you get.</a></div><div style="text-align: justify;"><br /></div><div style="text-align: justify;">I opened this topic to a bunch of people from the client organization and we came up with a bunch of metrics based on the principle that we should report consistency rather than hard numbers. Consistency gives a measure of effectiveness and also encourages the right activities.</div><div style="text-align: justify;"><br /></div><div style="text-align: justify;">Here's the list that we came up with (There can be many more. The basic principle is to use proportions / percentages instead of hard numbers):</div><div><ol><li style="text-align: justify;"><b>Velocity Barometer</b> without numbers (we mark completed stories in red on a barometer, but we take out the numbers. Consistent color means good, ups and downs means trouble)</li><li style="text-align: justify;"><b>Cumulative Flow Diagram</b> (consistent thickness of bands v/s actual numbers)</li><li style="text-align: justify;"><b>Ratio of open V/s closed bugs</b> (Percentage. Instead of bugs found and bugs fixed)</li><li style="text-align: justify;"><b>Test Coverage</b> (Percentage)</li><li style="text-align: justify;"><b>Automated V/s Manual tests</b> (Percentage)</li></ol><div style="text-align: justify;">Really speaking it all boils down to using just <a href="http://en.wikipedia.org/wiki/Control_chart">Control Charts</a> for project reporting and management. What do you think?</div></div>Anonymoushttp://www.blogger.com/profile/03105245771080772055noreply@blogger.com2tag:blogger.com,1999:blog-45303104106804987.post-15496483966129909782010-02-18T17:57:00.000-08:002013-03-05T19:20:36.522-08:00Testing considered wasteful??<div style="text-align: justify;">
<span class="Apple-style-span" style="font-family: verdana;"><span class="Apple-style-span" style="font-size: small;">@silvercatalyst posted on twitter a few days back that one of the trainees in his session counted testing as waste. I retweeted with a #funny but @silvercatalyst said he actually agreed with it. So we twiscussed it for a while. (By the way twitter is just the wrong tool for discussing interesting things). Back to the story.</span></span></div>
<div style="text-align: justify;">
<span class="Apple-style-span" style="font-family: verdana;"><span class="Apple-style-span" style="font-size: small;"><br /></span></span></div>
<div style="text-align: justify;">
<span class="Apple-style-span" style="font-family: verdana;"><span class="Apple-style-span" style="font-size: small;">Here's what we ended with after a few emails had been exchanged:</span></span></div>
<div>
<ul>
<li style="text-align: justify;"><span class="Apple-style-span" style="font-family: verdana;"><span class="Apple-style-span" style="font-size: small;">Testing is not wasteful. But testing as an activity after development (especially after a time gap) is wasteful</span></span></li>
<li style="text-align: justify;"><span class="Apple-style-span" style="font-family: verdana;"><span class="Apple-style-span" style="font-size: small;">Some types of testing can be done upfront but other types still have to be done after the story is complete</span></span></li>
<li style="text-align: justify;"><span class="Apple-style-span" style="font-family: verdana;"><span class="Apple-style-span" style="font-size: small;">There are ways to prevent bugs (rather than catch them) by Dev + QA and BA + QA pairing</span></span></li>
</ul>
<div style="text-align: justify;">
<span class="Apple-style-span" style="font-family: verdana;"><span class="Apple-style-span" style="font-size: small;">Mixing this conversation with </span></span><a href="http://limitedwipsociety.org/2009/05/27/feature-injection/"><span class="Apple-style-span" style="font-family: verdana;"><span class="Apple-style-span" style="font-size: small;">Feature Injection</span></span></a><span class="Apple-style-span" style="font-family: verdana;"><span class="Apple-style-span" style="font-size: small;"> technique and Mike Cohn's post on </span></span><a href="http://blog.mountaingoatsoftware.com/remove-finish-to-start-activities-on-agile-projects"><span class="Apple-style-span" style="font-family: verdana;"><span class="Apple-style-span" style="font-size: small;">removing Finish to Start activities</span></span></a><span class="Apple-style-span" style="font-family: verdana;"><span class="Apple-style-span" style="font-size: small;">, I think that BA(or Customer), Dev and QA pairing on a story will provide tremendous boost to cycle time and significant reduction in bugs. But to achieve this, you need certain pre-conditions to be true.</span></span></div>
<div>
<ol>
<li style="text-align: justify;"><span class="Apple-style-span" style="font-family: verdana;"><span class="Apple-style-span" style="font-size: small;">Co-location with customer. Else a great BA who is an excellent customer proxy</span></span></li>
<li style="text-align: justify;"><span class="Apple-style-span" style="font-family: verdana;"><span class="Apple-style-span" style="font-size: small;">Poly-skilled team members (not just smart)</span></span></li>
<li style="text-align: justify;"><span class="Apple-style-span" style="font-family: verdana;"><span class="Apple-style-span" style="font-size: small;">Team members (including the Customer) open to work towards a moving target (with negotiable stories)</span></span></li>
</ol>
<div style="text-align: justify;">
<span class="Apple-style-span" style="font-family: verdana;"><span class="Apple-style-span" style="font-size: small;">My next project will hopefully see this implemented, at least in small steps. Something a step ahead of the </span></span><span class="Apple-style-span" style="line-height: 19px;"><a href="http://christianralph.blogspot.com/2010/02/menage-trois-in-kinky-teams.html"><span class="Apple-style-span" style="font-family: verdana;"><span class="Apple-style-span" style="font-size: small;">Ménage à trois</span></span></a><span class="Apple-style-span" style="font-family: verdana;"><span class="Apple-style-span" style="font-size: small;"> that's already been tried out successfully.</span></span></span></div>
<div style="text-align: justify;">
<span class="Apple-style-span" style="line-height: 19px;"><span class="Apple-style-span" style="font-family: verdana;"><span class="Apple-style-span" style="font-size: small;"><br /></span></span></span></div>
<div style="text-align: justify;">
<span class="Apple-style-span" style="line-height: 19px;"><span class="Apple-style-span" style="font-family: verdana;"><span class="Apple-style-span" style="font-size: small;">Thanks @silvercatalyst for an interesting discussion and helping me put my thoughts together on a bunch of stuff I had read recently.</span></span></span></div>
</div>
</div>
Anonymoushttp://www.blogger.com/profile/03105245771080772055noreply@blogger.com1tag:blogger.com,1999:blog-45303104106804987.post-70415775638563753642010-02-05T12:58:00.000-08:002012-09-19T09:12:22.540-07:00Back to the Basics - 1 - The problem<div style="text-align: justify;">Reading Martin's <a href="http://martinfowler.com/bliki/ConversationalStories.html">ConversationalStories</a> renewed my confidence in this draft post from about an year ago. I just couldn't put it in the right words and gave up on it. I keep talking about deterministic universes over randomness and stuff like that but the gist of the matter is simple.</div><div style="text-align: justify;"><br /></div><div style="text-align: justify;"><blockquote></blockquote><blockquote>Writing stories is not the JOB of a Business Analyst in agile development. Writing stories is a collaborative effort in which Customer, BA, Dev, QA should all take part. This is the N in the INVEST principle.</blockquote> </div><div style="text-align: justify;"><br /></div><div style="text-align: justify;">And here's the post</div><div style="text-align: justify;"><br /></div><div style="text-align: justify;">==============</div><div style="text-align: justify;"><br /></div><div style="text-align: justify;">I have been talking about tracking and trends and smells and quantum physics for sometime but here's a post that takes us back to the basics. This is about the very problems (with waterfall) that we are trying to solve using alternative approaches (agile, lean, hybrid, etc).<br /><br />As everything in life should start, we start by defining the problem. Waterfall is an approach that borrows heavily from Einstein's idea of a deterministic universe. The idea is that <blockquote>If you know the position and velocity of each atom in the universe, you can accurately determine the state of the universe at a given point in future or the past.</blockquote>The point is that this is just a theory. I am not contradicting the theory but I am just pointing to the simple fact that gathering knowledge about the position and velocity of each atom takes too much time to be of any use.<br /><br />Waterfall tries to do the same thing at a very small scale; at a project level. And the argument remains the same. It'll take you too much time to understand every aspect of a problem for you to be able to successfully solve it while it's worth solving.<br /><br />Agile is about improvisation. You accept the inherent randomness of the universe. This might be genuine randomness OR it might just feel random because we are not able to understand it, but at any rate the universe is random to Human Beings.<br /><br />So we say, given that things are going to change in ways that cannot be determined, let's do our best to adapt to those changes as quickly as possible. To adapt is to understand what has changed, how it affects us and what can we do to "maximize our happiness" in the given situation.<br /><br />This is where you require the key component of anything worth calling a success. Collaboration.<br /><br />In the deterministic world of waterfall, the Business Analyst is supposed to be this wizard, who understands the whole problem, whose affected and how and formulates a solution to it all by herself. Few have succeeded at meeting this unrealistic expectation.<br /><br />Agile says let us all work together towards solving this problem and I think that's a more realistic way of getting an optimum solution. Now what this means is that nobody's word is final on any solution unless everyone is happy. Neither the client, nor the Business Analyst and nor the Developers. That is what it means when we say that a user story is <span style="font-weight: bold;">Negotiable </span>(i-N-v-e-s-t).<br /><br />* Increasing happiness as in the sole purpose of life.<br /></div><div style="text-align: justify;"><br /></div><div style="text-align: justify;">==========</div>Anonymoushttp://www.blogger.com/profile/03105245771080772055noreply@blogger.com2tag:blogger.com,1999:blog-45303104106804987.post-34492448055328395102009-06-23T23:46:00.000-07:002012-09-19T09:12:22.540-07:00The Revolution<div style="text-align: justify;"><span style="font-size:100%;"><span style="font-style: italic;">Software Development - Art OR Science?</span></span><br /><br />A seemingly <em>clichéd</em> question. Never passed my mind all these years. But let me tell you how I got thinking about this and maybe it'll interest you a bit.<br /><br />Like I said earlier, I have been following a lot of Lean-Kanban discussions, articles, etc lately. Some such material is Little's Law & WIP limits. Now the moment I saw an equation, I couldn't resist the temptation of trying out some math to see if the size and composition of my current team is optimal. Furthermore, I thought, given a few specifications of the project like domain complexity and technology, could I find the optimum team size and composition?<br /><br />I hit two forums with this idea and most of the feedback was that there are too many things to consider and difficult things as well like the skills and experience of the people on the team. And I agree that people make most if not all the difference. But that's the problem isn't it?<br /><br />What's so special about our people? Skills. Experience. Talent even. It's a sign. It's a sign of our industry being immature. I think its in around the occupation stage on this scale.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiNxvPJdgG72-L9j1vMoldW9oY2bFJRKRHgE-8hdevmhqDPnGCAZ5xnyVqT9jllkosusopoLlSC2A1bRD99sjVGrnQZ56k_MD3QfP2v41u8D4gQj6y_pv26Eae3vpvgclTGqQX2s7MAJIE/s800/Art-Science.png"><img style="cursor: pointer; width: 767px; height: 325px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiNxvPJdgG72-L9j1vMoldW9oY2bFJRKRHgE-8hdevmhqDPnGCAZ5xnyVqT9jllkosusopoLlSC2A1bRD99sjVGrnQZ56k_MD3QfP2v41u8D4gQj6y_pv26Eae3vpvgclTGqQX2s7MAJIE/s800/Art-Science.png" alt="" border="0" /></a><br /><br />Enough demand can trigger the Art - Occupation - Industry - Science transitions for any activity. Note that the transition is never 100%. There's Art and Science in everything. The question is whether something is "more of" art OR science.<br /><br />People keep arguing that Software Development is different. We are not like construction, we are not like assembly line manufacturing, we are not like Product Development either. I used to believe it till a few days back. But the more I think about it the more I feel that these are arguments of a losing population of craftsmen who are finding it increasingly difficult to meet the demand for their craft (which has BTW risen at unusual rates).<br /><br />Think about the guy somewhere around current Pakistan who created the first piece of leather clothing many hundred years ago. Think about the leather industry right now. Think about the transition. At some point he must be saying "This is different. This needs skills. This needs experience". It took centuries for the transition but it happened. I am sure it can be co-related to the rise in demand for leather products.<br /><br />The funny thing is, if you look at the list of general characteristics of the Art and Science sides, the first three points on each side don't really fit in with the IT occupation do they? We have loads of unskilled people sitting around producing amazing amounts of useless code all over the world.<br /><br />So I think the revolution is inevitable. At some point the people who pays us boatloads of money for bad software are going to revolt. We either have to change OR die.<br /><br /><a href="http://www.virtualschool.edu/cox/pub/PSIR/">Here's another article</a> roughly talking about similar things. The author anticipated a code market to emerge where reusable components would be bought and sold (which didn't happen OR hasn't happened yet). But the rest of the content is around the same theme as this post.<br /></div>Anonymoushttp://www.blogger.com/profile/03105245771080772055noreply@blogger.com8tag:blogger.com,1999:blog-45303104106804987.post-67974838266289798462009-04-28T17:08:00.000-07:002012-09-19T09:12:22.540-07:00KanbanAlthough I am not in the thick of things right now (because I am onsite, alone, so far away from my team) I follow the very active <a href="http://finance.groups.yahoo.com/group/kanbandev/"><span style="font-weight: bold;">kanbandev</span></a> yahoo group. It's a great resource for thoughts and questions on lean and kanban software engineering.<br /><br />David Joyce, a group member, posted about a presentation he gave and I found it really good. So <a href="http://leanandkanban.files.wordpress.com/2009/04/kanban-for-software-engineering-apr-242.pdf">here's the presentation</a> for anyone else interested.<br /><br />It's definitely a long one but take some time to go through it.<br /><br />Good stuff David.Anonymoushttp://www.blogger.com/profile/03105245771080772055noreply@blogger.com2tag:blogger.com,1999:blog-45303104106804987.post-37503277690484352572009-03-16T19:36:00.000-07:002012-09-19T09:12:22.540-07:00Story Dependencies<div style="text-align: justify;">As I mentioned in <a href="http://agileanalysis.blogspot.com/2009/02/can-you-shuffle-your-stories.html">this</a> post, I am pretty annoyed with myself because of the way I structured stories in the first release of my current project. Here are a few things that I learnt.<br /><br />First of all when we say that Story A is dependent on Story B, it means that Story B development cannot start until Story A development is complete<br /><br />There are different situations where one story is dependent on another. Each situation needs to be dealt with in a different manner.<br /><br /><span style="font-weight: bold;font-size:130%;" >Types and Approaches</span><br /><br /><span style="font-weight: bold;">Situation 1 - The wrong split</span><br />This is the classic vertical split. Many have advised against it but many more fall into the same trap again and again. Myself included :)<br /><br />Look out for the vertical split problem.<br />Remember,<br />If your body is horizontally split in half as in you have no legs, you can still do something with yourself.<br /><br />If your body is vertically split in half as in your left is separate from your right...<br /><br />The first place to look for the vertical split is Admin Functionality / User side of the application. If you see your stories divided like Admin Stories and User Stories make as big a noise as you can quickly.<br /><br /><span style="font-weight: bold;">Situation 2 - The application flow</span><br />This is where we just plainly don't think.<br /><br />Example:<br />When you get a message on Yammer, Yammer sends you an email. You can click on the email to look at the message you have got. BUT you can obviously keep your Yammer client open and see the message instantaneously and thats the way it's supposed to be used.<br /><br />Email notification is a nicety. Showing the message on Yammer client DOES NOT depend on sending an email notification to the user.<br /><br />Such errors are much easier to spot. Beware of the Business Process Workflows that you refer to. The business process workflow DOES NOT represent development flow. Mark the niceties and essentials apart in your workflow.<br /><br /><span style="font-weight: bold;">Situation 3 - Data dependence</span><br />This is a little more tricky. But I have seen this a lot of times as well. This is closer to David's comment on my earlier post.<br /><br />Surely to sell an item, you need to set the item up in the system. Doesn't this mean that you have to build the Item CRUD features into the system before you can sell it.<br />NO!!<br />Theoretically the items could be setup directly in the database. If the goal of the system is to sell an item, then that's what should be done first.<br /><br />Practically you should be doing the absolute minimum "item setup" before you build the functionality to sell it.<br /><br />The first thing is to concentrate on the crux of the system. Selling Stuff, Lending Books, Renting out DVDs, Playing Music, these are the things to achieve as early as possible in respective projects. Therefore you need to do whatever is needed to get to these areas as soon as possible.<br /><br /><span style="font-weight: bold;font-size:130%;" >Musings-at-the-end</span><br />I was mostly plagued by the admin V/s user situation throughout this release. We split stories that way because there was a tough deadline to meet and we thought it's better to split the work so that more pairs can work on the project. It worked out alright and we are in the last iteration and even able to provide a few more story points than promised. But we did face a lot of problems in scheduling because we split the stories in a wrong way. So that's definitely something to avoid.<br /><br />Another thought that keeps popping in my head is the idea of Programming by Convention. Like RoR.<br /><br />If you have a team of fairly experienced, "like minded" developers... can they agree upon a few conventions to follow so that two pairs can work on "Setting up the Item" (Admin part) and "Using the Item" (User part) simultaneously? I am still talking about evolutionary design (code as well as database). I seem to think that with good build processes, this should be possible.<br /><br />What do you think?<br /></div>Anonymoushttp://www.blogger.com/profile/03105245771080772055noreply@blogger.com7tag:blogger.com,1999:blog-45303104106804987.post-44081447606079676612009-03-06T18:31:00.000-08:002012-09-19T09:12:22.540-07:00Credit Cards, PCards and Level 3 data<div style="text-align: justify;">Here's a post that talks about business more than business analysis.<br /><br />I have been researching what it means to process level 3 data for credit cards. For quite a while now. Finally today I had that "Oh!" moment and I want to share it because I have had trouble finding data.<br /><br /><span style="font-weight: bold;">Basics</span><br />Credit Card processing is simple. I am assuming e-commerce here.<br /><br />1. Customer enters credit card information (Number, expiry date, billing address, CVV)<br />2. Site (Merchant) sends the information to a CC processor.<br />3. CC processor talks to the issuing bank and authorizes the card<br />4. Site (Merchant) gets paid by issuing bank<br />5. Customer pays the issuing bank later<br /><br /><span style="font-weight: bold;">Not So Basics</span> - <span style="font-weight: bold;">PCards</span><br />Large Corporations and Government Agencies (LCGAs) realized one day that they could save a lot with electronic transactions and decided to use credit cards. But the employees went crazy with their personal credit cards. So Visa and MasterCard came out with special cards that were issued to employees specifically for official purchases. This is the Purchasing Card (PCard).<br /><br /><span style="font-weight: bold;">Level 3</span><br />However, the usual credit card transactions were difficult to settle. LCGAs realized that if the Merchant sent more data about the purchase to the CC processor while charging the card, LCGAs could get this data back from the CC Processor and thus could reconcile all transactions electronically and hence easily.<br /><br />So the merchants started sending "Level 3" data to the CC processors. This is detailed data about the line items for which the card is being charged.<br /><br /><span style="font-weight: bold;">Benefit</span><br /><span style="font-weight: bold;"></span>The basic benefit of Level 3 data<span style="font-weight: bold;"> </span>is that LCGAs can reconcile the purchases made by their employees easily. They can also keep a check on what the employees are buying.<br /><br /><span style="font-weight: bold;">Conclusion</span><br />Level 3 processing is only beneficial for PCards. Not for consumer Credit Cards. It's advisable for merchants to pass Level 3 data to CC processors because it increases their chance of working for LCGAs as well as gets them some discount on transaction processing fees.<br /><span style="font-weight: bold;"></span></div>Anonymoushttp://www.blogger.com/profile/03105245771080772055noreply@blogger.com0tag:blogger.com,1999:blog-45303104106804987.post-38711005659928747452009-02-25T19:13:00.000-08:002012-09-19T09:12:22.540-07:00Can you shuffle your stories?<div style="text-align: justify;">No? Neither can I and I am not happy about it.<br /><br />So I got my new iPod Touch. One thing I find slightly annoying is the fact that when you select an album it gives you the list of songs. But the first option is "Shuffle". Being used to LPs and Cassettes and CDs I don't really like to shuffle songs. I have listened to my favorite albums in a given order of songs for so long, that I want to listen to them in that order.<br /><br />So I started wondering about the requirement for a shuffle option itself. And I conclude that it does nothing but brings a tiny bit of randomness in our lives. A little bit of surprise. That's all.<br /><br />What is also important is that the songs that we listen to usually are shufflable :) Because I do listen to Indian classical music and you can't shuffle that. The khayal has to come before the drut rendition.<br /><br />So what's this got to do with user stories? Well, I am currently plagued by dependant stories and I suddenly realized that they are like India Classical music. They can't be shuffled. Separate post about why I have too many dependant stories on the current project.<br /><br />Dependant stories are not always avoidable. But it is ideal to have a lot of stories that can be shuffled.<br /></div>Anonymoushttp://www.blogger.com/profile/03105245771080772055noreply@blogger.com5tag:blogger.com,1999:blog-45303104106804987.post-55940711500759969472009-01-02T05:23:00.000-08:002012-09-19T09:12:22.541-07:00A Bunker Buster coming!!!<span style="font-weight: bold;font-size:180%;" >Get Down!!! Take Cover!!!</span><br /><br />A <a href="http://agileanalysis.blogspot.com/2006/08/grenades-shells-bunker-busters.html">bunker buster</a> on it's way here guys...<br />...been a long time since I wrote one of those :D<br /><br />But then again, as <a href="http://en.wikipedia.org/wiki/Nassim_Taleb">Nassim Taleb</a> says in <a href="http://en.wikipedia.org/wiki/The_Black_Swan_%28book%29">The Black Swan</a><br /><blockquote><span style="font-size:130%;">What you know can't hurt you (much)</span></blockquote><blockquote></blockquote>More on the book later. I still got to finish it.<br />And by the way, have a wonderful New Year guys.Anonymoushttp://www.blogger.com/profile/03105245771080772055noreply@blogger.com1tag:blogger.com,1999:blog-45303104106804987.post-23912474792040700942008-12-19T09:30:00.000-08:002012-09-19T09:12:22.541-07:00Features V/s Sophistication<div style="text-align: justify;"><span style="font-weight: bold;font-size:130%;" >Usefulness of software:</span><br />Letting the user do what s(he) wants <span style="font-weight: bold;"><u>easily</u></span> and <span style="font-weight: bold;"><u>fast</u>.</span><br /><br /><span style="font-weight: bold;font-size:130%;" >Features:</span><br /><span style="font-weight: bold;"><u>Number of activities</u></span> a user can perform with the software.<br /><br /><span style="font-size:130%;"><span style="font-weight: bold;">Sophistication:</span></span><br />Software <span style="font-weight: bold;"><u>intelligence</u></span> which simplifies user interactions.<br /><br />Software, like anything else follows the laws of Diminishing Marginal Utility. Here are the graphs as per my experience with software (Not as a software professional but as a simple user)<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj26proLxEgMJ9ACWbdMxPXGl1Z36kisjbqiJ1b4KUXm-q24PAeAmzCBZK8_zU9yc8usTGJZ_Sphky0XqOtvXeqrjMZuCLZcG-D2PFotZZjgeAV2WchNXtMo7KOJubcZEZ5YbzBrfC1T0M/s800/DMU.JPG"><img style="cursor: pointer; width: 670px; height: 495px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj26proLxEgMJ9ACWbdMxPXGl1Z36kisjbqiJ1b4KUXm-q24PAeAmzCBZK8_zU9yc8usTGJZ_Sphky0XqOtvXeqrjMZuCLZcG-D2PFotZZjgeAV2WchNXtMo7KOJubcZEZ5YbzBrfC1T0M/s800/DMU.JPG" alt="" border="0" /></a><br /><br /><br /><span style="font-weight: bold;">Features</span><br />I think the marginal utility of adding more "features" to the software diminishes at a much higher rate.<br /></div><ul style="text-align: justify;"><li>Firstly because individual users don't use all the features but have to pay the price, in terms of money as well as processing power, disk space, etc. </li><li>Secondly because users have to deal with all the "genericness" of the software and hence cannot do what they want <span style="font-weight: bold;">easily</span> and <span style="font-weight: bold;">fast</span></li></ul><div style="text-align: justify;">Best example of such software is (my beloved) <span style="font-weight: bold;">Lotus Notes</span>.<br /><br /><span style="font-weight: bold;">Sophistication</span><br />The marginal utility of making software intelligent also diminishes albeit at a much slower rate. Google Calendar Quick Entry is a good example of software intelligence. So is GMail's <a href="http://gmailblog.blogspot.com/2008/10/new-in-labs-stop-sending-mail-you-later.html">drunk email protection</a>.<br /><br />What keeps GMail, GMail is that everyone (creators and consumers) abides by the simple rule that GMail is for sending and receiving email. If you want to do something else, you will have to use something else.<br /><br />There are a couple of software that come to mind which do have a huge feature set but still keep the crux simple enough. Microsoft Word for example has done it rather well in that I can go in and create a simple document as easily as I could when it ran on Windows 3.1<br /><br />As a business analyst this translates into a simple rule:<br /><span style="font-weight: bold;">Know the crux of your application and stick to it</span>.<br /><br />When you set out to start a new project, get your users to agree upon the problem to be solved and do whatever it takes to solve that problem; not a penny more, not a penny less.<br /><br /><span style="font-weight: bold;">Software for Everything</span> is as enticing a concept as the <span style="font-weight: bold;">Theory for everything</span>. I think there's a reason we haven't found it :-)<br /></div>Anonymoushttp://www.blogger.com/profile/03105245771080772055noreply@blogger.com5tag:blogger.com,1999:blog-45303104106804987.post-32341278706510099272008-12-16T15:05:00.000-08:002012-09-19T09:12:22.541-07:00Cumulative Flow DiagramsOnce you have your wall in place, it’s time to start monitoring your progress through the project. Best done on a daily basis and best done with a “Finger Chart”. Here’s an example.<br /><div style="text-align: justify;"><br />A finger chart is basically your wall turned sideways so that your swim lanes are horizontal rather than vertical. Now what you track is the number of stories in each state (finger).<br /><br />This chart may not make sense to you immediately but there’s a lot of useful data hidden in here. Here are the different inferences you can make by looking at a finger chart.<br /><br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjKn4GfOEtxEv6FQkEYBhMyEhJSWmHDMmp2CiAUnbS-ADEXq4PU5Ltpv4-KxVMiRdrlOODPx0c1zhe9fX1a5J6HANyiQlr2NQMXSE6s-u7n05aLaTtcRrWG8MRp8AzGVL6D1T3459gl3KE/s800/finger%20chart%20zoomed.png"><img style="cursor: pointer; width: 589px; height: 520px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjKn4GfOEtxEv6FQkEYBhMyEhJSWmHDMmp2CiAUnbS-ADEXq4PU5Ltpv4-KxVMiRdrlOODPx0c1zhe9fX1a5J6HANyiQlr2NQMXSE6s-u7n05aLaTtcRrWG8MRp8AzGVL6D1T3459gl3KE/s800/finger%20chart%20zoomed.png" alt="" border="0" /></a><br /><span style="font-weight: bold;">1) Bottlenecks</span><br />The first thing that you monitor on a finger chart is bottlenecks. This is easy. Just check for a band thickening consistently. A band <span style="font-weight: bold;">thickening</span> means that there is either a <a href="http://agileanalysis.blogspot.com/2008/12/choose-your-lanes.html"><span style="font-weight: bold;">capacity problem</span> or a <span style="font-weight: bold;">capabili</span><span style="font-weight: bold;">ty problem</span></a> in the next band. For example, the BA/QA band consistently thickens a suddenly rises at specific intervals. This is because the Client is signing off the stories only at the end of each week. This may be due to various reasons which need to be investigated to see if something is wrong OR can be made better. The ultimate goal is to achieve a smooth graph.<br /><br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj0RkCc4LFHqVWWs3cL8QxKbP6SBYcMkboPJ2R2orBq7Ig4gARXmoivWTla5H0AzR5VjwEgQ90J5PoLdqWATOuepobVR6TWLuRBm_KkhvlHHNA231UkvSE2lUFrC6UOmexE3em0bQJqRwY/s800/finger%20chart.png"><img style="cursor: pointer; width: 598px; height: 628px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj0RkCc4LFHqVWWs3cL8QxKbP6SBYcMkboPJ2R2orBq7Ig4gARXmoivWTla5H0AzR5VjwEgQ90J5PoLdqWATOuepobVR6TWLuRBm_KkhvlHHNA231UkvSE2lUFrC6UOmexE3em0bQJqRwY/s800/finger%20chart.png" alt="" border="0" /></a><br /><span style="font-weight: bold;">2) Work in progress</span><br />At any given point if you measure the total across all bands <span style="font-weight: bold;">vertically, </span>it will give you the total work in progress. This is a total of everything that needs attention from someone or the other on the team.<span style="font-weight: bold;"> Always try to keep this as low as possible.</span> You should ignore the <span style="font-weight: bold;">Celebration State</span> for this calculation.<br /><br /><span style="font-weight: bold;">3) Average Turnaround Time</span><br />If you measure the time across all bands horizontally, you get the turn around time for a story. This is a good measure of your entire process. How lean your processes are, how good the team is, how involved and keen the client is, etc. This is what tells you how much time your team needs on an average to turn an idea into working software.<br /><br />Remember that the finger chart is a cumulative of all stories. Therefore the top line of the graph should never dip down unless you have really reduced scope.<br /><br />Now whether to track Number of Stories OR Story Points on a finger chart is an interesting debate. I will try to present my ideas on that in another post.<br /><br />UPDATE : As David pointed out these are called Cumulative Flow Diagrams in the Lean world. Finger Charts is/was more of a ThoughtWorks term.<br /></div>Anonymoushttp://www.blogger.com/profile/03105245771080772055noreply@blogger.com2tag:blogger.com,1999:blog-45303104106804987.post-91443692727524858362008-12-12T02:29:00.000-08:002012-09-19T09:12:22.541-07:00Choose your lanes<div style="text-align: justify;">Starting a new project is always fun. For Agile/Lean teams setting up the story wall is a part of the fun.<br /><br />Some would say you are defining the process that you want to follow. The life-cycle of the user stories from being analyzed to delivered. But there’s more to a wall than defining the story lifecycle. In its wall the team chooses what it wants to monitor.<br /><br />The lanes on the story wall are statuses in which the story can be. An agile team wants to track these statuses to quickly find problems that are slowing the team down. These problems can broadly be classified into two categories.<br /></div><br /><img style="cursor: pointer; width: 680px; height: 237px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjGJhS350ZZt08EsuSZ-HnDAejZVb7wMcV-n6MMozqmZEsZr_4_m6KYklCbAxIGsTON6XGTA5d51jydxXUU2p2QZDfUqT-P8TcgziCAScCw3lPmI1IJvA9bRu_w9QpGMAea8nEFNwkU3uU/s800/states.png" alt="" border="0" /><br /><div><br /><span style="font-weight: bold;font-size:130%;" >Capacity Problems</span> – Found by tracking <span style="font-weight: bold;">Wait States</span><br /><ul><br /><li>There is a bottle neck because people have too much on their plate<br /></li><li>Can be solved by<br /><ul><br /><li>Adding more people<br /></li><li>Finding out better ways of doing the work<br /></li><li>Prioritizing the work correctly<br /></li><li>Making the process leaner by removing statuses<br /></li></ul><br /></li></ul><br /><span style="font-weight: bold;font-size:130%;" >Capability Problems </span>– Found by tracking <span style="font-weight: bold;">Work In Progress States</span><br /><ul><br /><li>There is a slowdown the right people are not doing the right job<br /></li><li>There is are problems external to the team which are slowing the team down<br /></li><li>Can be solved by<br /><ul><br /><li>Training people if there is enough time<br /></li><li>Bringing in specialists who can help out<br /></li><li>Addressing external problems<br /></li></ul><br /></li></ul><br />Monitoring every state that the story is in is ideal but not optimum.<br /><br />So choose your lanes keeping in mind what you want to monitor.<br /><br />When something is not happening on its own, make it a ritual by adding a lane.<br /><br />Keep your process lean by removing unnecessary statuses from the wall as well as the process.<br /></div>Anonymoushttp://www.blogger.com/profile/03105245771080772055noreply@blogger.com1tag:blogger.com,1999:blog-45303104106804987.post-71495078454948432762008-12-10T02:20:00.000-08:002012-09-19T09:12:22.541-07:00Can't negotiate size... and a good thing too<div style="text-align: justify;">In many companies the Business Analyst or the Project Manager “estimate” the project and bind developers on the project to that estimate. This is an absolutely brutal thing to do to your project. But even within agile teams where the developers estimate, the Business Analysts or Project Managers sometimes tend to challenge and negotiate developer estimates. Not because they don’t trust the developers but merely out of selfishness. Because it gives a tremendous kick to deliver something that a client wants faster.<br /><br />Now if the team is “estimating” in a “time based” unit such negotiations make some sense. Because a developer might say “Well I’ll take 3 days to do it but developer X is really good at XML so he can probably do it in 2 days”. And that might help given that you can assign the task to developer X (who in all probability is good a everything).<br /><br />Another way of doing this is for the team to “size” user stories based on relative complexity. <a href="http://en.wikipedia.org/wiki/Story_points">Here’s how it works</a>.<br /><br />As a developer on the team you are only classifying the stories into buckets of high, medium or low complexity. Nothing you can do is going to change the complexity of a given story.<br /><br />As an analyst or project manager on the team please don’t ask developers questions like “Are you sure this is a 4-pointer?” The only one who can simplify stories is you.<br /><br /><span style="font-weight: bold;">Something Faster</span> is better than <span style="font-weight: bold;">Everything Later</span>.<br /><span style="font-weight: bold;">Everything Faster doesn’t exist</span><br /><br /></div>Anonymoushttp://www.blogger.com/profile/03105245771080772055noreply@blogger.com1