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

What are we doing?? - Part Three

This is what got me thinking about "What (the %*&$) are we really doing?". Are gazillions of dollars being invested in IT, by organizations just trying to maintain their status quo? As the study shows, this is partly true.

1. Businesses require to grow for survival.
2. Growth requires accommodating more and more people and systems into your business.
3. It is very natural (and useful) to be paranoid of these new people / systems.
4. As businesses grow they have to become more or less bureaucratic.
5. Bureaucracy requires additional processing power.
6. This power can either be man OR machine
7. If the business chooses to invest in machines, we, the IT guys, make some money.

So that is what we do.

We help businesses grow...
...grow by overcoming their paranoia by automating bureaucracy...
...bureaucracy which is only bound by the stakes...
...stakes which are ever growing.

To be honest, I am still not totally convinced that this is all what software is about. What do you think?

What are we doing?? - Part Two

Any system is inherently trust based but always tends towards being distrustful. Consider a prisoners' dilemma example.

(A) = A crook with a bag of jewels
(B) = Another with $100

(A) needs the money and (B) needs the jewels. Now they are both "if you see my face, I'll have to kill you" kind of guys. So they develop a simple system. (A) leaves the money a designated place in the forest and (B) leaves the bag of jewels at another designated place.

If they both co-operate, they leave happy. But life is not so simple, is it?

Once they start losing trust in each other. They will employ various methods, making the system more sophisticated in the process, so as to make sure that they are not tricked. Here's what they could do (this list is not exhaustive ;-) )

1. (A) decides to send a friend to the place where (B) is supposed to leave the bag to see that (B) does leave the bag
2. (A) realizes that even if (B) leaves the bag, how will (A) know? So he decides to send two friends, one of whom shall come back and inform (A)
3. (A) grows suspicious of his two friends, coz they might run away with the jewels, so he has to keep their children as collateral. He appoints a person to guard the children and has to feed them as well.
4. The friends say that if (B) leaves an empty bag, it's not their fault. Which is fair, so they end up carrying mobile video cameras that transmit back to (A) on his mobile receiver...

... and so on.

Well actually at step 4 (A) goes "All this for $100?? Not worth it at all". Wise decision but if the stakes go higher, (A) will end up investing in the hi-tech solution which only improves his chance of not getting cheated by a fraction. By the way all this while (B) is also employing similar tactics.

So here we have two parties willing to invest in more and more complex systems as long as the stakes seem high enough for them. And here are we, the IT people, who will help them do it.

To be continued...

What are we doing?? - Part One

I am doing what we call an Inception for a new project. The situation is not at all unusual.

The Constraints

• An Organization with a bunch of generic e-commerce platforms
• Live customer sites on each of these platforms
• One of these platforms particularly painful
• Integration with proprietary back-office operations software

The Requirements
Build a custom platform that will replace all the existing ones, support all the customer sites and have a bunch of unique features. And BTW we need to go live in 2 months.

How?
The only way to do this is build a bare bones application that can take a couple of simple customer sites live in 2 months. We can then keep adding to the application and making it richer and better and migrating more customer sites as and when possible.

Now whenever you try to skin an application the first ones to suffer (and rightly so) are the administrators of the system. I say "rightly so" because normal users can potentially be dumb, careless, in a hurry, etc. and the application has to make sure they are doing the right thing.

Administrators on the other hand are trained to maintain the application. They can do without a jazzy UI and help and pointers all over the place. They know how to do their job. We, as designers of the system, take the liberty of trusting them. And in that trust lies the topic of this series.

To be continued...