Microlending should not just be about philanthropy

Microfinance is clearly in vogue with Prof. Yunus of Grameenphone winning a noble prize this year. Here’s a link to the story

James Webster, a colleague of mine, has recently posted about Kiva, a non-profit organization that allows individuals to contribute towards microfinancing a venture in the developing regions such as Eastern Europe, Asia, Africa and South America. The thing that struck me about such microlending operations is that they all are non-profit organizations. Startup Journal’s post on microlending also speaks about the issue of associating philanthropy with such operations.

Given that the returns on these investments are not very high, it would be very hard for an aggregator of microfinance to actually run a highly profitable concern.So they often call for volunteers to help them out in their functions such as accounting, Marketing & PR, software development etc. However, these voluntary activities are very intrinsic and cater to the aggregator’s own operations.

The fact that each outlay is very small, it also stands to reason that the investors themselves cannot offer value to the entrepreneurs beyond the initial seed and occasional consulting. What is truly needed is a support network for the entrepreneurs themselves. It should be possible for the entrepreneurs to get support from volunteers within the local region. This could be a management student who can help in formulating a marketing strategy, a local accountant who can offer an hour of their time, a printer who can print a small order of leaflets etc. These kind of micro support would go a long way in boosting the overall profitability of the business.

The other interesting outcome of microlending can be innovative business models that cannot be tried directly in a developed nation. C. K. Prahalad has already propounded the theory about the “bottom of the pyramid” (World’s poorest markets) where innovative practices and ideas can be harvested and tested.

The aggregator’s role, thus, should not just be about financing the entrepreneur. It should also be about facilitating a volunteer network to support the entrepreneur and it should be about harvesting innovative ideas from around the world. Collectively, these can generate the returns for the aggregator to make them move away from being non-profit charity institutions to a lucrative business model.


Pairing and productivity

Just been through a blog reading trail starting from Kathy Sierra’s “The Asymptiotic Twitter Curve” to Jason Fried’s “How to shut up and get to work” to Joel Sposky’s “The value of alone time” which all talks about individual productivity. The gist of those blogs is that we feel compelled to repetitively keep checking our email, IMing, answering phone calls, checking our blog stats etc without realising that it breaks our concentration and prevents us from going into a “zone”.

This led me to think about how Agile addresses the productivity issue. It was interesting to see that Agile considers colacated teams to contribute towards the overall productivty of the team. On the other hand, advocates of agile defend the loss of productivity when 2 people work on the same problem by offering reasons such as continuous code review, design brainstorming, risk mitigation against siloed knowledge etc. Based on the logic in those posts, productivity is actually helped through pairing and adversely affected by colocation.

One advantage of pair programming that my ex-colleague Ivan Moore mentioned to me was that out of politeness and respect for your pair,one would be less tempted to check for their emails or answer any phone calls or browse generally. The pairs keep each other honest and focussed on the task, and can crack on faster. Thus, what is lost in terms of having 2 people working on 1 problem is compensated by the increased and sustained focus on the task.

Agile advocates co-located team sitting in proximity for free flow of communication about project matters . Under such arrangement, a team member can potentially disturb another pair to ask about a problem that they might have tackled earlier. The benefit is that one does not have to solve the problem from scratch if other had done something similar earlier.

However, Joel observes that about 15 minutes of respondent’s time is wasted when they are interrupted in their work as they will now need to spend that time to get their concentration back. Joel’s observation is based on the fact that individual programmers have to juggle a lot of small details in a short memory and one loses that thread when they are interrupted. The process of re-organizing the data takes an investment of 15 minutes.

Now when I have been explaining a concept to someone and disturbed, I too have lost my thread and have had to repeat some of the things I may have already covered. However, if someone was listening keenly, they might be able to get me back on track again quicker without the need to repeat things.

Given this, my theory is that pairing would allow for all small details about the program to be jointly understood by each half of the pair and even if they get disturbed, they can make a faster recovery to get back on track and achieve their focus again. Thus, it might take only 7.5 minutes to get back to the problem for a pair who were interrupted as opposed to 15 minutes for an individual.

Has anyone got any empirical observations to back this up ?

Technical Debt Part 2

Following PierG‘s comments, I had further discussions with my colleagues and realised that he and I may be speaking about slightly different things. Technical debt can be generated by either of these

1. Technical debt generated from having poor safeguards such as bad testing, insufficient code reviews, no refactoring etc is bad (See Thomas Looy’s post )

2. Technical debt generated from having made a conscious decision about achieving short term fix that includes things like having stuff in a configuration file, static html page, manual workarounds etc.

One is a clear compromise on principles of working whereas other is a conscious well thought out short term fix. I suspect PierG had the former in mind when he talks about taking on technical debt as wrong.

Technical debt

There is an interesting ongoing conversation I am having with Pier G around technical debt.

In one sense, “Technical debt” is a brilliant term that establishes the debtor’s(the system) obligation to repay at a future point.Until that point is reached, this debt will have to be serviced with interest payments ( harder maintenance, lesser flexibility etc).

In another sense, the word technical seems to imply that the decision is taken by technical stakeholders, which is simply not true.This is not just a technical decision. It is about features, it is about investment and it is about opportunity cost.

Pier G says ” And as a general rule I prefer to think that making a technical debt is wrong!”

It is all right to have a preference, but it certainly is not his sole decision (unless he is a 1 man army building software for himself).

To be fair, he also says “And … having someone in the team who’s able to decide when it’s time to make that mistake is a GREAT value.”

Hurrah !! We are in concurrence except that I wouldnt call it a mistake, though it might be one.

One has to judge every decision point with the business value yardstick to ensure that correct decisions are being made with available information at that point of time.

Comments ?

How to hit the ground running

I was watching “Ali” the other day with my dad. While I thoroughly enjoyed the movie, I realised that my dad was struggling to make sense of what was going on.. I realised that the movie assumed that the viewer was already aware of the 60s movement in the US to gain racial equality, Malcolm X and the politics of Nation of Islam, the Vietnam war etc. Years of watching American television, movies , documentaries and a lot of reading allowed me to get the necessary context, which my dad lacked.

Too often, consultants face the problem when they land at a new client – there are huge unknowns such as the client’s existing business process, existing systems and the business environment. At this point a good amount of jargon gets thrown about by the user base without necessarily setting the context. Some of this jargon can also be wrong such as false domain terms, using system names interchangeably with business processes, poor domain design etc. Its possible that there isnt a safe zone for the consultants to ask the dumb questions. Its difficult for the consultants to hit the ground running when faced with such barriers to information.

Kathy Sierra draws a distinction between “Jargon” and “Buzzword” in her post , the former being the lingua franca of experts and the latter being used to impress/ mislead others. In our example, the users /customers have built their own jargon over the years based on their specific work environment. The consultants, on other hand, may possess certain knowledge about domain, but is most probably not conversant with the jargon used. Without resorting to buzzwords which can be counterproductive, the consultant needs to find a way around the jargon used.

Here’s what I have done in similar situations like this earlier

  1. Read ! Read existing documents , WIKI pages, public websites, etc. Some clients also have internal induction training courses – get your hands on those, if possible.
  2. Model your understanding of the system and illustrate it visually. The users may break the model through different scenarios, which is actually a positive thing. (For more details, see Chris Matts’ article on Negative Feedback)
  3. Apprenticeship. If possible, get to be an apprentice to a customer and help them in their work. Suddenly “Damn ! We have got too many NIGOs today” starts making a bit more sense. (NIGO = Not in Good Order). There is another side benefit here – we may actually begin to have empathy for their daily jobs.
  4. Related to apprenticeship, one can volunteer to test existing systems for a short period of time. This usually provides a good context of how users actually use the system.
  5. Maintain a “Jargon” or “Glossary” page on a shared WIKI or something similar. Most users are happy to answer direct questions such as ” How is a CFD different from Swap” ? or ” Where does GLADIS fit in the whole trade cycle” ? This is of course, assuming, that you know what a SWAP is and what a trade cycle is.
  6. Get the user in a teaching mode e.g. Lets say we are building a new financial trading system. In our analysis sessions, we should ask the user to think of a situation where they have just set up an entirely new fund. The user is asked to think about a single product which they wish to trade, consciously keeping out any complexities. Once the simplest scenario is achieved, start layering it with other complexities and dimensions. The happy side effect is that you would also end up with the right set of stories to work with.
  7. Build relationships at client site at all levels. Juniormost people are sometimes also the best sources of information as they have recently been through a learning curve themselves.
  8. Finally, document your learning. It is quite possible that you may have to handover to another person and you dont want them to go through the same pains again.

Let me know how these tips work for you. Or you could just be like my dad who says “Theres no such thing as a dumb question – there are only dumb answers”.

Operational Art

From Answers.com

“Operational art translates the joint force commander’s strategy into operational design and, ultimately, tactical action, by integrating the key activities at all levels of war”

In IT parlance, this means translating the business strategies into IT organizational design and tactical project selection to maximise the organizational value. It is about IT leaders being perceptive of the business needs and spotting opportunities for improvements.

Michael Hugos provides an interesting example in his post “Turning Business Strategy into IT action”, where he provided a business solution which not only helped the business overcome an inefficient process, but also helped long term sales and revenue prospects for the company .Little surprise that he has been the recipient of CIO 100 award twice for innovative use of technology and business vision.

Here’s a set of mantras for growing and nurturing the relationship using the Operational Art terminology.

  1. Understand the synergy
    Be cognizant of the organizational drivers. Too often they get presented in a disjointed fashion like a giant jigsaw puzzle.
  2. Use Simultaneity and depth for business solutions
    Use all available resourctes to come up with creative solutions for client and their customers
  3. Anticipate the business needs
    Remain alert for the unexpected and for opportunities to exploit the situation
  4. Have a Balanced team
    Have a team of mixed capabilities that can fulfill the task
  5. Leverage existing advantage
    Maintain competitive edge by constantly seeking opportunities to improve existing situation
  6. Timing and tempo
    Act decisively and quickly
  7. Understand your operational reach
    Know what your capabilities are and the cost of your services
  8. Improve Forces and functions
    Improve existing IT capability on both technical capabilities as well as operational processes
  9. Arrange operations
    Plan a phased execution of projects to achieve the desired business outcome
  10. Develop Centers of Gravity
    Create an agile organization with a motivated workforce and enhaced technical and process capabilities
  11. Act on Decisive points
    Business critical decisions that would influence the long term organizational future.
  12. Culmination
    Fail fast without wasting huge amount of resources
  13. Termination
    Terminate the initiative when the incremental cost of delivering exceeds the benefits

It would be very hard for business to not respect and like someone who is so switched on about their needs and who finds creative ways to fulfill them.

Financing Agile Projects

Here’s a story about a major toothpaste manufacture .In a bid to improve their sales, they decided to offer 400g toothpaste for the price of 300g. A normal 300g toothpaste, if it lasts 30 days in a household, could now potentially last 10 days longer.This wasnt good. It would affect long term sales. To counteract this, the manufacturers got clever.They increased the diameter of the toothpaste tube outlet. They were counting on the customer maintaining their behaviour. Consumers would cover the length of the toothbrush irrespective of the volume of toothpaste .

The takeaway for me in this story is that consumers were not able to extract value out of the increased offer because they focussed too much on a single dimension. Business firms also run their departments using a single dimension – budgets be it in monetary terms or resource terms. Whilst this soft constraints based model worked well with the predictive methodologies which had discrete decision points, it does not sit well with the Agile methodologies.

Executives need to change the way they think about IT project financing. Agile projects are like the toothpaste with extra 100g. To extract the true value, the consumer needs to change their behaviour. Agile methodologies, done in the right way, deliver to business strong risk management, flexibility and quicker returns. The following behavioural change is required for project financing

1. Budget based financing –> Line of credit / Venture capital financing
Provide different levels of capital based on demonstrable results for IT projects.

2. Returns –> Risk vs Return
Focus on mitigating risks as much as earning returns

3 Fixed Price –> Real options
Seek more flexibility to change the direction of the program of work

4. Worrying about sunk costs –> Fail fast
A quicker feedback cycle helps prevent overcommitment