Skip to content

December 2008

Features V/s Sophistication

Usefulness of software:Letting the user do what s(he) wants easily and fast. Features:Number of activities a user can perform with the software. Sophistication:Software intelligence which simplifies user interactions. 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) FeaturesI think the marginal utility of adding more “features” to the software diminishes at a much higher rate. Firstly because individual users don’t use all the features but have to pay the price, in terms of money as well as processing… Read More »Features V/s Sophistication

Cumulative Flow Diagrams

Once 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. 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). 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. 1) BottlenecksThe… Read More »Cumulative Flow Diagrams

Choose your lanes

Starting a new project is always fun. For Agile/Lean teams setting up the story wall is a part of the fun. 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. 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… Read More »Choose your lanes

Can’t negotiate size… and a good thing too

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. Now if the team is “estimating” in a “time based” unit such negotiations make some sense. Because a… Read More »Can’t negotiate size… and a good thing too