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)




Features
I 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 power, disk space, etc.
• Secondly because users have to deal with all the "genericness" of the software and hence cannot do what they want easily and fast

Best example of such software is (my beloved) Lotus Notes.

Sophistication
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 drunk email protection.

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.

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

As a business analyst this translates into a simple rule:
Know the crux of your application and stick to it.

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.

Software for Everything is as enticing a concept as the Theory for everything. I think there's a reason we haven't found it :-)

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) Bottlenecks
The first thing that you monitor on a finger chart is bottlenecks. This is easy. Just check for a band thickening consistently. A band thickening means that there is either a capacity problem or a capability problem 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.



2) Work in progress
At any given point if you measure the total across all bands vertically, 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. Always try to keep this as low as possible. You should ignore the Celebration State for this calculation.

3) Average Turnaround Time
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.

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.

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.

UPDATE : As David pointed out these are called Cumulative Flow Diagrams in the Lean world. Finger Charts is/was more of a ThoughtWorks term.

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 problems can broadly be classified into two categories.

Capacity Problems – Found by tracking Wait States

• There is a bottle neck because people have too much on their plate
  
• Can be solved by
  
  
  
  • Adding more people
    
  • Finding out better ways of doing the work
    
  • Prioritizing the work correctly
    
  • Making the process leaner by removing statuses
    
  
  

Capability Problems – Found by tracking Work In Progress States

• There is a slowdown the right people are not doing the right job
  
• There is are problems external to the team which are slowing the team down
  
• Can be solved by
  
  
  
  • Training people if there is enough time
    
  • Bringing in specialists who can help out
    
  • Addressing external problems
    
  
  

Monitoring every state that the story is in is ideal but not optimum.

So choose your lanes keeping in mind what you want to monitor.

When something is not happening on its own, make it a ritual by adding a lane.

Keep your process lean by removing unnecessary statuses from the wall as well as the process.

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

Another way of doing this is for the team to “size” user stories based on relative complexity. Here’s how it works.

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.

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.

Something Faster is better than Everything Later.
Everything Faster doesn’t exist