Although 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 kanbandev yahoo group. It's a great resource for thoughts and questions on lean and kanban software engineering.
David Joyce, a group member, posted about a presentation he gave and I found it really good. So here's the presentation for anyone else interested.
It's definitely a long one but take some time to go through it.
Good stuff David.
Tuesday, April 28, 2009
Monday, March 16, 2009
Story Dependencies
As I mentioned in this 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.
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
There are different situations where one story is dependent on another. Each situation needs to be dealt with in a different manner.
Types and Approaches
Situation 1 - The wrong split
This is the classic vertical split. Many have advised against it but many more fall into the same trap again and again. Myself included :)
Look out for the vertical split problem.
Remember,
If your body is horizontally split in half as in you have no legs, you can still do something with yourself.
If your body is vertically split in half as in your left is separate from your right...
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.
Situation 2 - The application flow
This is where we just plainly don't think.
Example:
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.
Email notification is a nicety. Showing the message on Yammer client DOES NOT depend on sending an email notification to the user.
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.
Situation 3 - Data dependence
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.
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.
NO!!
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.
Practically you should be doing the absolute minimum "item setup" before you build the functionality to sell it.
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.
Musings-at-the-end
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.
Another thought that keeps popping in my head is the idea of Programming by Convention. Like RoR.
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.
What do you think?
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
There are different situations where one story is dependent on another. Each situation needs to be dealt with in a different manner.
Types and Approaches
Situation 1 - The wrong split
This is the classic vertical split. Many have advised against it but many more fall into the same trap again and again. Myself included :)
Look out for the vertical split problem.
Remember,
If your body is horizontally split in half as in you have no legs, you can still do something with yourself.
If your body is vertically split in half as in your left is separate from your right...
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.
Situation 2 - The application flow
This is where we just plainly don't think.
Example:
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.
Email notification is a nicety. Showing the message on Yammer client DOES NOT depend on sending an email notification to the user.
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.
Situation 3 - Data dependence
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.
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.
NO!!
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.
Practically you should be doing the absolute minimum "item setup" before you build the functionality to sell it.
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.
Musings-at-the-end
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.
Another thought that keeps popping in my head is the idea of Programming by Convention. Like RoR.
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.
What do you think?
Friday, March 6, 2009
Credit Cards, PCards and Level 3 data
Here's a post that talks about business more than business analysis.
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.
Basics
Credit Card processing is simple. I am assuming e-commerce here.
1. Customer enters credit card information (Number, expiry date, billing address, CVV)
2. Site (Merchant) sends the information to a CC processor.
3. CC processor talks to the issuing bank and authorizes the card
4. Site (Merchant) gets paid by issuing bank
5. Customer pays the issuing bank later
Not So Basics - PCards
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).
Level 3
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.
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.
Benefit
The basic benefit of Level 3 data is that LCGAs can reconcile the purchases made by their employees easily. They can also keep a check on what the employees are buying.
Conclusion
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.
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.
Basics
Credit Card processing is simple. I am assuming e-commerce here.
1. Customer enters credit card information (Number, expiry date, billing address, CVV)
2. Site (Merchant) sends the information to a CC processor.
3. CC processor talks to the issuing bank and authorizes the card
4. Site (Merchant) gets paid by issuing bank
5. Customer pays the issuing bank later
Not So Basics - PCards
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).
Level 3
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.
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.
Benefit
The basic benefit of Level 3 data is that LCGAs can reconcile the purchases made by their employees easily. They can also keep a check on what the employees are buying.
Conclusion
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.
Wednesday, February 25, 2009
Can you shuffle your stories?
No? Neither can I and I am not happy about it.
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.
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.
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.
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.
Dependant stories are not always avoidable. But it is ideal to have a lot of stories that can be shuffled.
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.
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.
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.
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.
Dependant stories are not always avoidable. But it is ideal to have a lot of stories that can be shuffled.
Friday, January 2, 2009
A Bunker Buster coming!!!
Get Down!!! Take Cover!!!
A bunker buster on it's way here guys...
...been a long time since I wrote one of those :D
But then again, as Nassim Taleb says in The Black Swan
And by the way, have a wonderful New Year guys.
A bunker buster on it's way here guys...
...been a long time since I wrote one of those :D
But then again, as Nassim Taleb says in The Black Swan
What you know can't hurt you (much)More on the book later. I still got to finish it.
And by the way, have a wonderful New Year guys.
Friday, December 19, 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)
Features
I think the marginal utility of adding more "features" to the software diminishes at a much higher rate.
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 :-)
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 :-)
Tuesday, December 16, 2008
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.
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.
Subscribe to:
Posts (Atom)