Metrics for Assessing the Financial Health

It's a constant struggle for the managers from non-financial backgrounds to come to terms with various financial statements and measures and gaining insights from them. Needless to mention, I am one among that :). 

Recently I came across a small pocket size finance book released by the Harvard Business School (HBS). Still it was not easy for me, but one chapter that attracted me endlessly was the chapter about important financial metrics. I have given the same in the way I understood them. Hope it will be useful for you as well. Good thing about these metrics is almost all of these are collected from the 3 mandatory financial statements only (Balance Sheet, Income Statement and Cash Flow Statement)  

Profitability Ratios

Gross Profit Margin: This ratio tells you how profitable your goods/services are. Gross Profit includes only the direct costs like raw material and direct labour. It doesn't include any indirect cost like administrative costs or overhead business managers' cost. If you are doing a project, you need to include only the cost of the members who directly contribute to the project. It ignores the company overheads. Good Indian IT service companies are operating at 60~65% gross margin

Gross Profit = Total Revenue-Cost of Goods Sold(COGS)

Gross Profit Margin = Gross Profit/Total Revenue

Operating Margin: This ratio tell you how profitable your goods and services are after taking your operating overheads into account. This is an important metric that gives you an idea of the overheads the company is suffering.

Operating Margin = Operating Profit/Total Revenue

Net Profit Margin: This is a most widely followed metric by the industry. You can compare your net margin with your industry's net margin to compare your company with that of your competitors. This ratio tells you how profitable your goods and services are after considering the operating overheads, depreciation, interest, tax etc. (basically all the cost overheads either direct or indirect). Good Indian IT service companies are operating at 20~22% net margin

Net Profit Margin = Net Profit/Total Revenue

Return on Assets (ROA): This measure tells you how the company is best utilizing its current assets

RoA = Net Profit/Total Current Assets

Return on Equity(ROE): It tells you how the company is best utilizing the owner's or shareholder's equity investments in the company. Basically how much value the company is creating for the shareholders

RoE = Net Profit/Total Equity

Operating Ratios

Days Receivables: This metric tells the average number of days the company takes to receive the money it owed from the external entities like customers. It is assumed that a company that collects the receivables quickly will NOT have many operating capital shortages

Days Payables: This measure tells you the average number of days a company takes to pay its suppliers. It is assumed that a company that takes more days to pay will have that much operating capital for that duration

Days Inventory: It tells you how long it takes for the company to sell the finished goods inventory kept in the warehouses etc.

Liquidity Ratios 

Banker's Ratio/Current Ratio: This measure gives an indication to your lenders (like banks) whether the lender can give loans to your company with confidence. It's a very simple arithmetic, if you have more assets (properties  or collaterals), then lenders will easily give you loans because loan recovery is not a problem

Banker's Ratio = Total Current Assets/Total Current Liabilities

Quick Ratio: It's is something similar to the Banker's ratio, but discounts the assets that cannot be easily liquidated. Here the assets mainly discounted are your unsold inventory because it is assumed that the unsold inventory cannot be liquidated quickly

Quick Ratio = (Total Current Assets - Total Inventory) /Total Current Liabilities

Leverage Ratios

Here leveraging means how you are leveraging your loans to create value for the company

Interest Coverage (IC): This measure tells you how much your company makes (your operating profit) more than the interest payables.  Operating profits are called 'Earnings Before Interest and Tax (EBIT)' also

IC = Operating Profit/Interest Expenses

Debt-to-Equity Ratio (DE): This measure gives you an idea about how the company uses loans against owner's equity. I believe this ratio should be as small as possible which means you are funding your operations mostly from owner's equity and not leading the company to big debt trap

DE = Total Current Liabilities/Owner's Equity

Others

Earning Per Share (EPS): This measure gives you an indication of how much value the company has generated for the stakeholders for each unit of the shares held by them

EPS= Net Profit/Total Number of Outstanding Shares

P/E Ratio: This measure is very popular in the stock markets. It tells whether the share price of a company is high or low against the company's operating performance.

P/E = Current Price of the Share/Total EPS in the Last 12 Months

.NET Memory Management Primer

I thought of compiling all that we learned regarding the .NET memory management while working in one of those smart client applications that we were developing for sometime - a suspected memory leak/performance issue. The post is a result of a combination of discussions, study of web resources including MSDN and running profilers like the Red Gate Ants Memory Profiler. You might be knowing some or all of the concepts, but my idea is to keep it as a simple primer where you go and refresh your knowledge and if possible learn something new

3 .NET App Memory Problems

With a managed environment like .NET, you have very little to do, good or bad, in terms of memory management because the lion's share of responsibility is taken by the Garbage Collector (GC), a component of the Common Language Runtime (CLR). Initial goal while designing GC is to completely abstract memory management from the developers. We must congratulate the GC team @ Microsoft in that they almost did that, but for some issues. I think they have done already what's humanly possible and further optimization of GC may not be possible

 It looks like there are only 3 memory related problems you may encounter in your .NET application

1. Large object heap memory fragmentation

2. Memory leak in the managed code

3. Memory leak in the unmanaged code

Before going deeply into the problems, we need to know how .NET framework abstracts memory management from your application

How memory management works in .NET?

Before allocating objects onto the memory, CLR does one important determination- if the object is a large object or a small object. Any objects that is more than 85KB is a large object. If it's a large object then it's allocated in the large object heap. If it's a small object, then it's allocated in the generations based small object heap. The generations in the small object heap are

• Generation 0 (holds the youngest objects)

• Generation 1 (holds the older objects)

• Generation 2 (holds the oldest objects)

The most ideal scenario is your app allocates objects to Gen 0 and de-references (abandoning) it as soon the app is done with using that object.

Large Object Heap

As already told, large objects are allocated in the large object heap by the CLR. Important differences between the large and small object heaps are

• Unlike the small object heap, there are no generations here
• Unlike the small object heap, 'compacting' doesn't occur during the garbage collection because it's a very costly process with large objects

What is compacting?

You can imagine a heap as something like a container in which objects are allocated one-on-the-top of the other. If a in-between object is collected by the GC, then the space held by the object is not compacted. For example assume obj A, B and C are allocated (A at the bottom, B in-between and C at the top). Assume there is some unused space on top of C. If B is de-allocated when the GC occurs, then the space held by B will remain as unused, so there will be a gap between A and C. Similar gaps between objects is called large object heap fragmentation and it's the most severe .NET memory problem. Since there is no compacting, next allocation of memory cannot be done effectively and efficiently. Some limited fragmentation may be acceptable, but if there is more fragmentation then there could be out-of-memory exceptions even when there is space in the heap, because they cannot be used due to excessive fragmentation

How to avoid large object heap fragmentation?

• Better architecture

• Avoiding large objects as far as possible

• A kind of LIFO (Last-in-first-out) strategy while allocating/de-referencing objects

• Forceful app or sub-app closure (not a good one though)

Small Object Heap

Small objects are allocated in the small object heap generations. An object is first allocated to Gen 0 by default. When Gen 0 is full, then GC is triggered. When the GC process is triggered the following happens

• Objects that have no references are salvaged (means collected) and the memory is freed.
• Objects that have app references are considered 'live' by the GC and promoted to Gen 1

Hence Gen 0 will be totally free, ready for fresh allocation at the end of the GC process. Same way GC process occurs for Gen 1 and Gen 2 also. Here is what the memory leak occurs

How memory leak occurs?

If an object really not needed by the app has some reference to it, then the object will be considered 'live' by the GC and promoted to Gen 1 (or for that matter Gen 2 as well) by mistake. This is called memory leak

GC Root

GC roots are special areas in memory that are always accessible by the application (like a reference to a static variable). CLR determines if an object is live or not by finding out if any of GC root has direct or indirect reference to the objects allocated by the application. If an object is not referred by any of the GC roots then that memory is identified as 'not reachable' by the application and is a garbage. Hence the GC can collect those objects when the GC process happens the next time

What a .NET developer is supposed to do to avoid memory leak?

The answer is Nothing. CLR is intelligent enough to identify if an object is live or not. But a developer may do blunders like allocating memory in a event handler like 'Timer_Elapsed' events in which case, the object will always be considered 'live' by the CLR and will be collected only when the application is closed.

But you can make your code 'GC friendly' by assigning the objects to null when you know for certain that you are done with using the object. That way GC will be efficient and hence your app too.

Other Learnings

• Avoid finalizers

• Avoid forceful GC process by calling GC.Collect(). It should be used only under extra-ordinary situations. Also GC.Collect() without any parameter will trigger the complete GC process from all the generations and large object heap too

• Avoid large objects

• Never allocate memory in the event handlers
• Make your code GC friendly by assigning objects to null when you are done with using the object. This is not a must, but improves the efficiency of the whole system

Lack of quality DevOps: Reason for software product failures?

If you do analyze spectacular software product failures, you will find one thing in common: Lack of better handshake between the app development and the operations (this handshake is fondly called 'DevOps', that personifies the communication, collaboration and integration between the app developers and IT people responsible for the operations)

• As the developer of the application, do you know what features in the app are valued by your customers most?
• As the tester of the application, do you know how closely your test plan and test scenarios align with the way your users approach the app? Are your test cases mimicking the exact user actions?
• As the app admin, do you know the details of the exception even before your user raises a 'SOS' ticket?

• As the user of an app, do you know what features are forthcoming in the next release?

All these things are possible when the DevOps is working at its best. But the question is how many times we have seen it's working perfectly? In many customer meetings we would have heard they speak about different applications or environments in which the app we develop is going to integrate or operate and we would have no clue whatsoever about those unique apps or environments.

Agile processes to some extent address the DevOps with the insistence that the Product Owner must work with the dev team to bridge the communication between the two worlds. Product Owners guard the product backlog and the feature priorities and thereby representing or protecting the interests of the customers. But quality DevOps is much more that and that's where you need  Application Analytics

Application analytics integrates the development and operations by sharing the operations data with application development and vice versa. For a well thought out DevOps, the development needs to 'instrument' their code consciously with the available APIs or their own mechanisms. Currently tools are available that inject instrumentation code post build right into the compiled assemblies.

Once the right instrumentation bits are available in the assemblies, all that you need to do is to receive the usage data from the applications, ETL the data (if required), analyze and publish in dashboards and reports. Published data will provide you with a lot of insights into what's happening to the application that's gone to the production. There are even cloud based analytics systems available now that accept your data, validate and analyze your data and provides static and dynamic reporting like cubes.

 Some of the usual data collected as part of the application analytics strategy are

• Application usage data
• Feature usage data (what features are used most, what features are dumped after initial attempt to use the feature)
• Session data
• System data (client system configuration details)
• Exceptions data (both handled and unhandled exceptions)
• Performance, app responsiveness data etc.

With such obvious benefits, still most apps don't help quality DevOps. Reasons could be many, but the most important ones are

• Lack of knowledge
• Security and privacy concerns
• Political reasons
• App sponsor not strong enough to unite the app development and operation streams
• Etc. etc.

Having a forceful application analytics strategy is part and parcel of your agile intentions. Let's hope we will have this in mind when we go for the next big app development

Indian IT Companies - Are they just '10 Dollar Shops'?

Mr. NR Narayana Murthy, Infosys co-founder has lamented in a convocation function for Engineering students that Indian IT had missed the innovation bus, didn't come up with great inventions- every gadget on your pocket or every book you read has a foreign hand. For this situation, he mostly blames the academia, students and the educational eco system that is prevailing in India

http://articles.timesofindia.indiatimes.com/2012-11-05/software-services/34926208_1_indian-software-infosys-founder-narayana-murthy

Is this a problem with our educational system only? What about the industry (mainly the top 5 or 10 cash-rich Indian IT companies) and industry bodies like NASSCOM?

• I believe  being on the lower end of the IT value chain is a conscious decision taken by the Indian IT industry. In fact, India is referred as the 'back office of the world' (Is that a praise or curse?)
• While the overseas players were busy inventing new and disruptive technologies , we were busy 'managing efficiently' the head count and the extra large benches
• When you are campus recruiting in 1000's how can you ensure quality?
• When you are running projects with 70% freshers how can you ensure great deliveries?
• Why most companies are taking people with their academic scores and not innovating a methodology that would determine the true quality of a candidate?
• What's the percentage of our R & D spend over the total revenue? Where is the culture of "giving it back to the industry"?
• Why we are too much apprehensive of inorganic growth? The risk appetite is very low even when we have big corpuses at our disposal. Best example,  Infosys shareholders' diktat to the company- "either spend the big 4 billion dollar kitty on strategic buy-outs or share the money with us"
• Absolutely no innovations/low skills in the change management practices
• There is enough emphasize over quarter-on-quarter growth and shareholder value addition. Is there same insistence on customer value enhancement q-on-q?
• Growth doesn't come without pain. But whose pain it should be? Customer's??
• How many are having a strong technology consulting practices/skills?

When so many Indians are working in technology majors like Microsoft, Google and Apple in the leadership positions, why there is no Amazon or Facebook or Oracle from India? It's a clear industry leadership failure, no point in blaming the students or our educational system

Can leadership be simulated?

Have you ever run a company virtually? Have you stepped into the shoes of other functional managers and tried to think like them? Have you ever made decisions that will have big financial impact and seen the chaos your decisions are creating in a cool manner- by sitting in the comforts of the ballroom of a star hotel?

I had one such experience when I attended the Leadership Simulation Workshop conducted by the enParadigm Knowledge Solutions @ Mumbai last week. It was definitely  a more innovative way of teaching, in which you wear different hats for the virtual company (like CEO, CFO, HR Head, Operations Head etc.) created by a web based software.

The software allows you to assume different roles, forecast the market demand, manufacture or out source the production, sell the finished goods against competition and get the financial results quarter after quarter and re-strategize/execute based on the quarterly financial reports. You get a host of research reports as well, but you pay for them. You get bonus when you meet your targets and you get memos when you make horrendous decisions :). You take loans from banks or loan sharks, negotiate the interest rate, postpone loan re-payment, re-negotiate payment terms with customers and vendors - the software supports all.

Personally it's a great deal of learning for me on how to interpret the financial reports, get insights from the reports and more basically how balance sheet, P/L account statement and cash flow statements are linked with each other.

I would recommend the workshop for all the 10+ years people who have started stepping out of their comfort territories and making their presence felt in other functional areas as well. For more details visit http://enparadigm.com/offerings/lsw/

Mobile First; Desktop Next

I was recently in a conference conducted by PMI. The organizers were tech savvy  and they had strictly instructed that no one should exchange the cards, instead QR code is printed on the delegate ID cards and you MUST only scan the QR code with your smart phone's QR code scanner to exchange the contact details. It was repeatedly announced and it seemed like they were pretty serious about the so called 'green' initiative.

I was talking to a delegate who was sitting next to me, he is from a very popular mid-size IT company and he was explaining me what they were onto, how successfully they created a niche for cloud and mobility. When we were about to exchange cards, I promptly reminded him of the conference diktat that we are not supposed to. I had the QR code scanner on my 'SMART :)' Nokia C6, I scanned his contact details. His company web site URL was part of the contact details, I clicked the URL spontaneously.

It was a disaster because their web site was not mobile friendly. After shock, he gathered himself to say their marketing team must be working on it. He conceded that he never tried their web site in  the mobile and I could sense his level of embarrassment as he was talking passionately about mobility a while before.

In the late 90's people used to say 'you should not start your marketing campaigns until your web site is done'

10 years later we must be reminding ourselves 'we shouldn't be starting our marketing activities until our web site for mobile is done'

It was confirmed by one of my 'sales' friends too. His story was more horrifying and had material damages as well. Their sales team was trying hard to have a crack into the IT of a prestigious MNC and they were struggling to get an appointment with the CIO of the MNC. They were not able to get beyond the board and the personal secretary of the CIO.

His Manager got a lucky break when he caught the CIO when they were waiting for the same flight. The CIO was relaxed, the sales manager was telling him how long they were chasing him and was trying to sell his company. The CIO acknowledged that he received a few of their general campaign mails and a few specific ones too. Obviously he didn't delete those mails, he was in a good mood that he took one of the recent mails in his mobile only to click the company URL link. The site was not designed for mobile and all that he got to see was a scrambled look and feel. The game was over, a lucky break was done in by their lame duck marketing who had more important things than getting a mobile friendly web site.

This is very important point for the ISVs (Independent Software Vendors) too, if they are starting a new venture they are better off by getting the mobile version first before getting done with the desktop peers. One big benefit is- when you focus on mobile, you always get the 'basic minimum' right first

Don't Love Your Code; Bombard it through 'Refactoring'

Refactoring is a simple engineering technique that our illustrious developers used quite successfully for decades and agile frameworks like xP adopted it to make it an unavoidable tool in the kit of agile developers. But of late, I have a doubt running over my mind whether the new entrants to development accord the same importance to refactoring like their seniors did. I wouldn't put the blame immediately on them though some people may be guilty of not doing it despite understanding the value it brings to the product. Poor education could be one  reason for that.

Impact of Software Frameworks

Apart from 'people and cultural' reasons, there may be others as well. Emphasize on higher productivity and lower cost  by the customers and managers resulted in the evolution of 'near turn-key' solution frameworks and software factories. The obvious result was too much production of auto-generated code that comply itself to a pre-determined architecture, foreseeable structure  and familiar design patterns. Example - ASP.NET MVC project templates.

The moment you choose the project template, your IDE creates the entire solution blue print even with minute configuration details and a hell lot of code. This is great in more than one way- like high productivity, low cost, rapid GTM and even a young development team can scale up to a standard. Down side is nobody thinks it's their code, 'It's my code' pride is gone. Developer's role is limited to mere fillers of code snippets (worse, most of the times even that was googled out) inside the method boundaries. Method signatures too designed by the IDE in most cases.

But this shouldn't be an excuse for NOT refactoring. Refactoring by definition means 'making small changes to internals of the code without changing the externals as and when more clarity on requirements becoming available'. And you do refactoring for engineering reasons rather than functional reasons.

That means you don't need to make revolutionary changes to your code or design, but subtle and simple changes that eliminate duplication, improve readability and maintainability, make the code more tidy and handle logics more efficiently. It's a much more effective practice than the peer-to-peer code reviews, because nobody understands your code better than yourself. To refactor, you need to live with your code for sometime at least just like a poet does with her poetries.

One emotional factor that prevents people from refactoring their code is why should I touch a running code and 'I cannot see my working code being changed for some frivolous reasons'. That's where we need to become less emotional and stop loving our code. We should not hesitate to break a long running code, be bold enough to make it better while seeing that it continues to support the same features as before refactoring.

Have the following in mind while attempting to refactor

• Do refactoring only for enhancing engineering aspects and NOT to add any features
• Check after refactoring if the number of lines of code reduces.
• Check after refactoring if the code becomes simpler. While the last 2 ones are not a must, you generally expect it out of refactoring. Of course simple design/code is difficult to achieve
• You MUST have a set of solid unit tests before plunging into refactoring. Unit tests are such an important cog in your engineering plan
• Most obvious, do not attempt refactoring if you are near to a release schedule
• Don’t try this immediately after coding a feature; it should be done over a period as the requirements and code evolve. You will have a better clarity and new ideas by then

Leadership and Strategy are inseparable…

I was reading the popular new arrival 'The Strategist' by Cynthia Montgomery of Harvard Business School. It was quite an interesting reading, particularly the concepts that tightly link Leadership and Strategy.

• If you are a leader (or commander in military terms), then you must strategize. You must be the central point of your company's purpose and strategy [Purpose is the reason why your business exists and strategy is the means to achieve the purpose]
• The leader can always take the help of functional or industry experts or even consulting firms while incubating the strategy. But at the end of the day, the leader takes responsibility for the strategy.
• The leader (or CEO practically) is the guardian of the purpose of the organization. That tells Chief Executive Officer is Chief Strategy Officer too.
• Owning the strategy means owning the responsibility. The leader gets the credit or curse because she owns the strategy
• Strategy is never been a finished product, it's a journey that the leader and the organization must live through. If a company thinks the strategy as a product or job (that is, it has a 'finished state' or 'end date') , then the organization will lose its purpose and become irrelevant
• The leader is mindful of the strategy all the time, maps each and every activity in her organization to the strategy, makes subtle (sometimes drastic too) refinements to the strategy continuously.
• The main thing that differentiates a leader and a manager is strategy
• The main thing that differentiates a CEO and a COO is strategy
• Though the leader consults his top team while carving out the strategy, still the leader has a blue print of the strategy on her mind even before calling the team for discussion
• If you are not a strategist, you cannot be the leader
• Concept of 'Super Manager' is a myth. Jack Welch of GE was touted as the 'manager of the century'. He did great things because he was a great strategist too. After he took over he sold close to 100 of GE's businesses because they were not making great margins for GE. He invested the money got through the selling on cutting edge businesses where GE had a definite differentiator.
• Even Steve Jobs is basically a strategist. Though he was celebrated for his technical brilliance and small but refreshing ideas, he was a strategist. As a strategist, he got a few failures and a few successes. Only thing, his successes are really game changing  and path breaking  that took the focus out of his failures.

Nobody likes to work in an organization which doesn't have or doesn't know the purpose. When there is no purpose, there is no strategy too, isn't it? 

NASSCOM session on Enterprise Mobility

Last week, I had an opportunity to listen and interact with 2 genial entrepreneurs, Umesh Sachdev- CEO of Uniphore Software Systems and Venkat Rangan- CEO of INXS Technologies in the NASSCOM organized 'Enterprise Mobility' session. Both the companies are striving in the mobile space, with their very much unique and niche offerings and I hope they are reasonably successful. Here there are some highlights...

For many people, enterprise mobility means checking their emails in the BlackBerry, even now. Better not to talk about India where the smart phone penetration is still at 10~15%. Those smart phones are mostly in the hands of Gen-Y, who have nothing to do with enterprise mobility at least as of now. So if you are a smart phone enterprise app developer who operates in the Indian markets, then Dude, your time is yet to come. But if you are ready to write apps for those devices that are not that 'smart' then you have huge potential in India.

 It's not that foreign enterprises are bullish on mobility in this economy, there exists a few road blocks that need to be effectively addressed by the mobile technical community so that enterprise IT departments confidently venture into mobility

• Lack of awareness: which is the biggest barrier in terms of security, mobile device management etc.

• Security: There are some valid concerns like unencrypted GPRS, corporate data out of the network and falling into the hands of competitors, remote wiping of enterprise data
• Compliance and Regulatory stuff: Most regulatory bodies are not exactly happy with classified data available out of the corporate networks
• Mobile Device Management (MDM): At least there are 100+ companies claiming they have sophisticated components to manage the device life cycle and security, but MDM domain itself needs more maturity
• Mobile Apps Management (MAM): Native apps distribution is still a nightmare with enterprises need to have their apps in the app store or market place and supporting different versions of the apps in the different devices

• Adoption & Training: Training is virtually impossible, this problem domain will have to be addressed by the 'No training only intuitive design' philosophy 

Other than the road blocks, there were some other interesting points discussed.

• In their opinion, mobile web apps are no match for intuitive native apps despite the HTML5 excitement.  But some people couldn't agree to that, they have seen mobile web apps even manipulating local devices like camera

•  'Write once, run anywhere' strategy never worked for them. They tried to target all the platforms at once using popular translation tools and every time they were not able to meet a critical business requirement

• There are 2300+ form factors and countless devices. So think and choose clearly before you start your development- what platforms, devices and form factors that you are going to support

• Choose the right candidate apps for mobile. Selecting a wrong app would push your mobile strategy back to years. Heavy apps should be avoided, even with a strong middleware.  Mobiles have data caps and low download speeds

• Write 'good citizen' apps that take less memory, consume lower bandwidths, clear the isolated storage space as and when not needed, utilize low battery power etc. etc.
• BYOD may look like reducing the cost initially, but will backfire when you need to support different devices and versions and you need to struggle with a score of rogue apps that don't care your corporate policies

The 'Rock Star' Agile Team

People might say there is no point in 'day dreaming', but sometimes that may help you define what's the kind of ideal world that you want to build for you and the organization. A recent survey stated that most organizations are not deriving the benefits out of their agile adoption and the people who claimed reaping benefits didn't actually follow agile practices (http://adtmag.com/articles/2012/07/13/report-says-agile-a-scam.aspx)

If you think why such reports are surfacing, most organizations are far from the idealistic agile practices while still maintaining that they are agile. So it's good to remind ourselves then and there how an idealistic agile team will look like

Product Owner (PO)

• Ideally   the PO should be the customer herself. If that's not possible, the PO should truly represent the customer interests and should be a clone of the customer in realistic terms

• PO should be a thought leader and  a product strategist. She must be aligning the product features, customer/market needs and the sponsor (or top management) interests continuously. It's actually a triangle that one side cannot be altered without affecting the other side

• PO should NOT shy away from decision making. But still applies self-control because though changes are encouraged in agile, in and out changes will drain the budget while creating frustrations down the line
• PO should be agile @ heart. If she is not agile, then the team cannot be one

Scrum Master (SM)

• Ideally SM doesn't have other responsibilities like coding or testing. I have noticed dilution of original responsibilities when SM is pinned with dev/testing activities
• SM has an intellectual understanding of agile.
• SM tries all the time to upgrade herself into an agile coach.
• SM just facilitates the team members to innovate , execute and improve.
• Resolves disputes, protects the team from external influences
• Makes the team responsible for its output and help them take pride in whatever they accomplished

Developer (Dev)

• Dev interacts with the PO, stakeholders, testers and other cross functional experts to better understand the requirements
• Dev is very transparent, announces the correct status always, openly discusses the difficulties faced either to get help or to educate others
• Dev understands the bigger picture though she works on the current iteration
• Dev mercilessly refactors her code as and when requirements and the design matures.
• Dev writes simple, dull, non-surprising code. She understands simple design or simple code is the most difficult job
• Dev doesn't do any magic, just writes readable, maintainable and very well documented code
• Dev uses re-usable components and frameworks. Doesn't write any code that's already available.
• Dev simulates the real life objects and problem domains in her code
• Dev minimizes the risks by identifying and using design patterns, uses tried and tested solutions
• Dev doesn't say 'DONE' unless and until the unit tests are done
• Dev releases on time to enable the testers to complete their job.
• Dev demonstrates the working application to the PO and gets her feedback directly, doesn't allow anyone to demonstrate her code

Tester (TR)

• TR stands-by for the PO in her absence. Team consults her on the requirements when the PO is inaccessible
• TR is the guardian of requirements and customer needs. She understands the customer's business domain
• TR takes care of the builds and releases. Advises the PO and SM on the real quality level of the software
• TR writes test cases, automates them and more importantly uses them
• TR shares the test cases with the devs. Ensures that the test cases are covered by the dev before accepting the code for testing 
• TR knows that catching the bugs in the dev's work station or very near to the place where the code is produced,  is the most efficient and cost effective testing
•  TR refuses to test if unit testing is not done or not properly done
• TR knows that her job is not only to catch bugs/entering in the bug tracker, but to improve the quality of the software and increase the returns to the customer
• TR, apart from testing, uses the software just like a customer does. Evaluates if she would pay for the software if she were to be the real user
• TR sits with the customer, sees how the customer perceives and uses the software

• TR is more technical than the devs. Doesn't shy away from writing a tool that just tests the software.

Is BYOD good or bad?

One of the important fall-outs of the so called disruptive technologies like mobility and cloud is the strong under current 'BYOD' (Bring Your Own Device) trend. Why I am saying it as an 'under current' is most of the IT orgs  don't even know that employees are using their own devices for official work. This trend is predominant in the last few years or so particularly after the Apple devices started commanding religious following (iPhone is called 'Jesus Phone' by some people).

If you talk to an IT guy about the BYOD trend he must be fuming, may even say 'it's a man-made disaster unleashed by the Enterprise nemesis  a.k.a Apple'. I hope nobody from the IT org likes this and in that sense these technologies are really 'disruptive'.  So what are the IT people doing about it? In most companies, I think they try their best to control BYOD. I guess they may not be very effective because most of the times this is being started by the top management and strong business leaders in the company.

The business leaders usually start by checking their emails in their personal devices, slowly would try to take more control over the enterprise information by demanding access to business critical information like executive dash boards and metrics that they control. They ask this for a purpose, to have a virtual 24X7 control over the business and in most of the cases IT cannot refuse this request. Once the top executives start this, employees will follow the suit. Social trends like 'work from home' fuelled by the high cost of real estate and overheads support the BYOD movement

Leaving aside why it's happening, let's think about whether it's good or bad. From corporate and information security perspective, it's very bad no doubt. Most of the Wi-Fi networks are not as secured as the LAN or WAN. IT organizations are yet to catch-up and implement best practices in the MDM (Mobile Device Management) and MDP (Mobile Data Protection).  Hence an employee losing the mobile or a disgruntled employee spoofing the data could turn into a disaster for the IT. Our sympathies are with the IT guys.

Other complaint that could emanate from managers  is that people are spending their time unproductively with their own devices. There is some substance in this blame, researches show that smart phones are being used more than 50% for sheer entertainment

Good thing about BYOD is that people have used them innovatively improving their effectiveness and efficiency and have come up with some startling but simple solutions for some of the vexing problems in their day-to-day work. Also many people use it to have a 'virtual' control over what it matters to them while on the move. It's a virtual office for them. To summarize, I could list out the following benefits

• Employee productivity and efficiency

• Innovative solutions (a recruiter gets great candidate through her FB connections or a stock broking agent downloads a free or low priced cheeky app that reduces his work load and provides more bandwidth for understanding  her customers)

• Virtual office and continued control over the business
• For IT service companies it may create a lot of opportunities. Business will need a lot of tiny applications that integrate with the monster, on-premises or cloud enterprise apps and deliver only a fraction of the functionality, a mobile employee may need. So they can bet on mobile app development and maintenance

So it's good or bad???

Whatever it may be, the movement cannot be stopped. Best thing would be to embrace the change and leverage benefits out of it while keeping the people and network under constant monitoring. We will require high tech security technologies to put your wireless network under control. So the industry in general and IT in particular must take the BYOD as an opportunity rather than cursing it as a barrier

6 Sigma: Is that just about project management?

I had a good opportunity to learn the basics of 6 sigma in a conference conducted by the Confederation of Indian Industry (CII) last week in Chennai. It was scheduled to cover the basics like what's 6 sigma, what different methodologies used etc. (in the morning session). In the afternoon session, Caterpillar and one more company (Wabco) were scheduled to present their 6 sigma case studies.

I had a natural curiosity how the 6 sigma is applied in the software industry because my earlier perception was 6 sigma is completely a statistical technique through which you measure the number of defects and then rectify the problems and reduce your defects. It's very much suitable for manufacturing but unsure of how the techniques can be used in the IT. The course, for sure,  corrected some of my wrong perceptions

In my own definition, I would say '6 sigma is a structured project management approach to bring about breakthrough improvements or to solve critical problems'. The words 'project management'  in my definition may cause some discomfort to the 6 sigma community, but I could see a lot of similarities between PMI recommended project management approach and the 6 sigma methodologies like DMAIC.

Of course there are a few differences

• PMI is for all the projects, while 6 sigma is looking for projects that seek breakthrough results or solutions to highly critical problems
• 6 sigma emphasizes on measuring the existing process capability to know where we stand while I don't see that much emphasis in the PMI (I may be bit out of place here)
• PMI treats projects as a temporary endeavor and it doesn't speak much about post project closure. But 6 sigma gives equal importance how to retain the benefits you achieved through the 6 sigma project in the post-closure phase

But for the 3 points, it's mostly project management best practices.  I would say a it's an extension to the PM practices prescribed by the PMI. I know most people will have objections to this way of looking at 6 sigma, but then that's how I felt.

In the afternoon session, Caterpillar was talking about their 6 sigma culture, was giving unbelievable numbers like they had completed about 50000+ 6 sigma projects. I was not convinced.  I asked a question 'can you give some examples of 6 sigma projects in Caterpillar?' The speaker was giving examples like 'improving the food quality in the company cafeteria' and some other 'projects' for which the solutions were obvious. It was very clear that they are 'misusing' 6 sigma for even low hanging fruits. Instead 6 sigma should be used for plucking the sweetest fruits that are hanging in the most difficult region to climb and reach.

If there is a problem, then there will be a root cause and there will be a solution. You will typically go for 6 sigma only when you don't know the root cause as well as the solution. If they are known then you don't need 6 sigma, you can apply simple techniques like KAIZEN (small, incremental, continual improvements) or 7 SPC quality tools.

The other company, Wabco presented an impressive case study in which they had solved a critical engineering problem in one of their complex products and the cost savings were around 8 million INR. Their problem domain looked like a legitimate 6 sigma candidate

I would definitely recommend 6 sigma for companies who are looking for improving their profitability, resource utilization or operational excellence. 6 sigma is not a daily routine, rather a highly important strategic project initiative that's expected to bring radical changes.