Agile Racecar: Software, Magic, and Life

I've previously said that User Stories are the most powerful construct in Agile methods, more than TDD, in my view. The challenge in using User Stories though lies in the fact that they shift the responsibility of getting things right - and quite fairly I might add - from the Engineering team onto the Product Owner/Product Manager. And unless you have strong buy-in from management, it's difficult to make it to the end of the Product Management process and to a point where you're cranking out iterations one by one. The key lies in efficiency in creating and managing User Stories, and tying them effectively to an evolving User Interface even as the product starts coming alive. I'm planning to share some of my experiences and thoughts on this soon. Meanwhile, I found this interesting article while searching the net for splitting stories along CRUD capabilities. Ways to split user stories .

Failure to effectively transition to Agile development is often based on a fundamental failure to understand what a User Story is. Allow me to explain. The most important aspect of a User Story is that it's an independently *schedulable* unit of requirement (feature). The key to achieving the "independently schedulable" characteristic of a user story is that you express it in terms of how a "user" would use it. This leads you to a unit of functionality that's implemented end-to-end (UI to backend) that a user can actually interact with. Not surprisingly, because of the focus on how a user would think about a feature, a user stories are highly readable - and could very well be written by the users themselves. However, the other important and less obvious aspect of a User Story is the emphasis on communication with the end-user and getting confirmation on the acceptance criteria. Describing all the requirements as User Stories for a decent sized product is rig...

Chances are you've heard about Agile before but you don't know what the heck it is - even if you think you do . Chances are: if I say "Agile", you think "methodology" if I say "Agile process", you think "Scrum" if I say "Scrum", you think "daily standup meetings" if I say "XP", you think "Pair Programming if I say "Requirements", you think "PRD" The problem with the above word/phrase associations is that they establish an incorrect image in your mind about the essence of XP, Scrum and Agile. It is this image that determines in the end whether you succeed or fail when you attempt any Agile method; in fact, it is this image that decides if you'll ever seriously attempt to use an Agile method to build software. No wonder that Agile methods often get such a bad rap from smart, well-intentioned, successful software develope...

Being Agile: my occasional ramblings on Agile development & Extreme Programming I constantly run into people who claim to be Agile but don't understand XP (extreme programming). And a lot of people fail to grasp the essence of XP because they get stuck on an XP principle that they find threatening - 'pair programming' and 'test driven development' are the usual suspects. I'll focus on Pair Programming and TDD another day. Today I want to discuss the most important and fundamental aspect of XP - User Stories. User Stories are like better, state-of-the-art Use-Cases - simpler and lending themselves to be scheduled individually. Think of a User Story as a fine-grained Use-Case, leading to better estimation of effort, tracking of progress, and higher quality of implementation (fewer bugs due to requirements that are fine-grained, thorough and less ambiguous). A User Story looks just like a bug would in a bug tracking system: a one-line title summarizing the r...

I have often said that people should be selected and rewarded based on productivity, not mere experience.  In fact, this belief forms the basis of the 'pay by productivity' contract system we use in the services division of Crystal Ball. But today I'm not going to talk about how we do things at Crystal Ball. Instead, let me just point you to this very cool article on incentivizing, measuring and rewarding productivity. Quoting: Software defect measurements are frequently attributed to individual developers, but the development environment often conspires against individual developers and makes it impossible to write defect-free code. Instead of charting errors by developer, a systematic effort to provide developers with immediate testing feedback, along with a root cause analysis of remaining defects, is much more effective at reducing the overall software defect rate. By aggregating defect counts into an informational measurement, and hi...

I'm posting my response to a question asked on LinkedIn Answers by Sramana Mitra : " Bootstrapping a Product Company from India? " Here's what I had to say: One aspect of bootstrapping is money. The other is people- good people. We're solving both problems with our strategy of treating our offshore team in India as a services company that specializes in high-quality, low-cost product development for early-stage startups in the Silicon Valley. But we are really a web-based product startup based in the Silicon Valley with our offshore team based at Hyderabad, India, since June 2005. When I came back from India in September 2005 after putting it all together, I had a team that boasted a University gold-medalist who turned down an offer from Google and deferred PhD at MIT to join us, a national programming competition winner, and a seasoned manager from Wipro. Then one fine day, in March 2006, my whole team just disappeared, and I only had 85 pages of use...

Formally known as the Pareto principle, the 80-20 rule states that "80% of the consequences stem from 20% of the causes." Startups - who by definition are starved for resources - would do well to apply the Pareto principle to everything they do. From Wikipedia: It is a common rule of thumb in business; e.g., "80% of your sales come from 20% of your clients." It also applies to a variety of more mundane matters: we wear our 20% most favoured clothes about 80% of the time, we spend 80% of the time with 20% of our acquaintances etc. In business, dramatic improvements can often be achieved by identifying the 20% of customers, activities, products or processes that account for the 80% of contribution to profit and maximising the attention applied to them. The idea has rule-of-thumb application in many places, but it is commonly misused. For example, it is a misuse to state that a solution to a problem "fits the 80-20 rule" just because it fits...

I have not met a single person who doesn't acknowledge the inherent values in XP when we talk about the values and not "this thing called XP". It is obvious to *anyone* who has enough years of experience behind them. * The challenge then they often face in accepting XP/Agile is their own conflict-of-interest. * You see, XP and Agile are brutal if you are lazy or if you are (or have become) mediocre. There's no place to hide in XP- everything is exposed. You can't create the anecdotal "job security hacks" so that you can't be replaced- because there are others in your team who know your code and can replace you if you're not pulling your weight. Or if you're a contractor, you now risk being caught for overbilling if you don't have "velocity" commensurate with the hours you're billing. I speak, of course, from my experience as a programmer. But more currently, I speak from my experience as the founder of a startup- as the em...

The problem I see with most objections to Extreme Programing (XP) and Agile development is that they are often speculations on theory, rather than wisdom based on actual practice. It's amazing to see the amount of time and energy people spend in *discussing* process than actually building something and learning from the experience. The following is my real-world take on this subject, directed at no one in particular, but at everyone in general who is critical or afraid of XP (often the same people who don't have meaningful experience of using it): XP is a process that has *evolved* through the collective experience of programmers through the mess that the software industry had become- always late, always over-budget, always buggy. And we were told to accept it as a fact of life. In the midst of all the chaos, there were programmers working after hours doing what they weren't allowed to do during the day - writing tests for code (TDD), automating builds ...

The Agile entrepreneur has a choice all too common these days. Implement it yourself. Or hire smart people for equity only- easier to do in the Silicon Valley than anywhere else (it's amazing what a single ad in Craigslist can do). Or pay young, super-smart programmers in India for a fraction of your monthly salary- you may not be able to afford it for a whole year, but we're talking about 3 weeks (i.e. iterations) here at a time. Regardless of the approach, practically every software entrepreneur in the US now has the ability to incrementally implement the features defined by the customer(s) , one iteration at a time. And get valuable feedback. And sooner or later, you'll have a paying customer as long as you stay true to the principles of Agile- "The Customer Is Always Right At The Beginning Of Each Iteration" (apologies to Sam Walton and Kent Beck:). Alternately, the customer(s) might realize soon enough and declare that the product doesn't have as mu...

Too often wannabe entrepreneurs fade out because they do not have the resources to put their ideas to the test. They may be able to talk to a customer or two, but there they often reach a dead end when the customer asks for a prototype or demo. It costs money - and takes time - to build one. And most aspiring entrepreneurs don't have a lot of money- or not enough - at least that's what they think. If you're an aspiring software entrepreneur, without an infinite capacity for risk, your prayers have just been answered. Imagine this scenario. The entrepreneur uses an online (web-based) agile project management tool to define the requirements. He then meets with potential customers, gets their feedback and refines the requirements, and prioritizes the features. Next the entrepreneur defines a short Release that contains the bare minimum functionality needed to "validate the business model". In plain English, this means that there's a customer out there who...

Mark my words, it is going to start happening within a year. I can see it in my Crystal Ball :) And remember, you read about it here first- Friday, Jan 27, 2006! Agile methodology, XP, and Hosted Agile Project Management tools (like Rally) are poised to take software entpreneurship and offshore outsourcing to the next level. India is finally going to shake off it's mentality of servitude and take major steps towards fostering Silicon Valley style innovation. How? Agile/XP approach of rapid, iterative development with customer feedback at its core is screaming from rooftops with a megaphone for very very v... early stage startups and budding software entrepreneurs to notice it. It's a marriage made in heaven! I can't think of a more natural fit of a solution to a problem. Agile development is for software entrepreneurs what lithium is for bipolar disorder (ok, so I guess the analogy proves that I can actually think of a more natural fit). ... contd. in "Ag...

UPDATE: Feb 2010: I wrote the following in Jan 2006 before I had enough exposure to User Stories and before I got stuck in the quagmire that Rally - at least in that version - turned out to be. I stopped using it a month later. The problem was ironically the same problem Agile development evolved to solve- Rally itself was over-engineered, tried to do much and did the simple & important things not well enough-- if at all. To make matters worse, it was very slow and highly cumbersome to input info into- these were the early days of Web 2.0 and Rally seemed to be going overboard with use of AJAX. I've heard good things about Rally again lately but haven't validated it for myself. I'll do a separate blog post on this topic when I do. I'm smitten by the Agile software development methodology. It's not as if I've heard about it only today, but now I have a tool that can (I believe) help me manage the CommuterStation product development in India more effectivel...