Build - Measure - Learn

Written for :

I was dreading the idea of sitting thru a 2 hour keynote session. To my surprise, I quiet enjoyed the content and the delivery of speakers. I actually enjoyed listening to Amit Chatterjee, Managing Director - Microsoft R&D Pvt Ltd, talk around a flavour of scrum methodology inspired by Eric Ries's The Lean Startup. He talked about how Microsoft R&D has successfully adopted scrum and has become more agile in the last few months. I simply loved the Nordstorm Stores example he presented.

The Nordstorm example set me thinking. Does the next generation impatience and need for instant gratification and results , need a completely different model of execution? When business and operations within an enterprise ideate, they are bound to be assumptions, risks and and unwillingness to entertain any failure on a large scale. Failure is still a stigma in most enterprises despite claims of nurturing innovation and asking people to challenge their boundaries without the fear. New ideas are new, by virtue of being un-thought of before, and hence untested and not yet proven. They are either hypothesis or a bundle of initiatives designed to achieve an objective laced around a foundation of hypothesis and assumptions. These hypothesis need to be put to test without building definitively, a system or a solution around that idea. Nordstorm sent a couple of developers to he floor shop. These guys took the business hypothesis and talked to Nordstorm's customers. Got inputs from them. Coded on the spot and got customers to use and experience it. They built-in the learning by making changes to the code, in front of the customers and got them too try using the application again. By the end of the exercise there were multiple iterations involving collaborating with shoppers on ideation  -  coding a solution - getting shoppers to interact with the applications - build in the learning. By the end of the exercise, they had the true picture of what the success criteria for the application should be and the metrics they should use to measure the success criteria. Sometimes, enterprises guess these on behalf of the customers and hence possibly get it wrong sometimes.

Amit talks about making the business hypothesis a testable experiment. It makes sense to get all stake holders whose lives will be impacted by the hypothesis (employees, partners and customers) around a table for the experiment and digest their take on the hypothesis. What you then get is a Minimum Viable Product (MVP). Measurement to calibrate the results need to be included in MVP. Once MVP is coded and ready, validation against the embedded measures is done as users use the MVP. Learning is gained, which then find their way back into the MVP. Measures are re-adjusted and or re-calibrated. The cycle repeats again. The important part being, that all stake-holders traverse this cycle together.

Somewhere during this cyclic iteration, there will be enough learning based on which you could choose to persevere with the hypothesis or pivot to a new hypothesis. Before you guys jump to conclusion, let me tell you what this process is not. This is not a process to decide what a end product should be. This is a process to test the business hypothesis by studying customer behaviour.

User departments and end customers of the enterprise are very good at articulating their need at a very high level. As devil is always in the details, The  Build-Measure-Learn approach avoids the creation of a wall between IT and the rest of the organisation and between the organisation and the end customer. Just as IT is accused of not understanding it's internal customers, organisations are accused of not understanding the needs of their end customers.

Coding as a part of structured ideation process, to test hypothesis,  helps in avoiding scenarios where IT teams accuse user departments of not giving detailed requirements in entirety and IT teams do not have to deal with the frustration of changing requirements. This approach avoids the Big Bang model around conceptualisation, requirement gathering and delivery.

I have seen and experienced scrum models where requirements are broken down into small chunks, after which a traditional approach is followed where business analysts (BAs) write down requirements, effort estimation is done and development happens in isolation. This model again results in user depts accusing BAs of missing out requirements, which in reality was a result of lack of bandwidth with the business users and most of the times, the lack of will to spell out everything to the last T.  Why do IT teams ask business requirements as if they are part of a different organisations? Why do we need to carry IT on the payroll if they cant figure out business requirements as an integral part of the business? These frustrating questions and scenarios can be avoided by following scrum they way it should be. Developers get the taste of the real world and the rest of the organisation starts appreciating the value IT brings on the table. Developers help the business users see the issues with their business hypothesis. This results in all-round appreciation for each other's efforts.

What I personally like about this approach is that it gives an opportunity to take what we have and make it a little better every day. This method greatly helps drive change management where impact is needed on the behaviour of stake-holders for the innovation to deliver and be effective. Stakeholders go thru the process of experiential learning during the build phase, rather than being forced to change behaviour post build-out; during the end user training phase of the project. This approach helps in facilitating a more cordial environment during end user testing and acceptance stages of the project. The biggest outcome of this method will be reduction in rejection of ideas. Management that is unable to visualize the benefits or finds change management around the idea over whelming typically label such ideas as either bad, ambitious and unpractical. The Build-Measure-Learn model executed with scrum methodology, helps evaluate ideas based on experiential learning rather than on perceptions power point presentations create.

It's always a good approach to talk about a new idea and invite stakeholders to test the hypothesis as a collaborative exercise in the build up of the idea and subsequently on solution creation phase, instead of constructing the idea in isolation and then hard-sell it to the management. The challenge is in change management around adoption and not in ideation or executing the system build up. This approach gets people to collaborate to make change management relatively easier by virtue of collaborating in build up of the idea.

written for :

Genchi Genbutsu

Innovation is a much used term these days in enterprise meeting rooms. I have maintained for some time now, in a few past blog posts, that most of time incremental improvements get termed as innovation, which is quiet sad. As with innovations, incremental changes too cause disruption and present a change management issue that is not trivial. Innovations, unlike incremental changes, significantly alter lifestyles, make certain parts of the eco-system redundant and almost always puts someone or something definetly out of business or commission.

In the banking and financial services space I have seen very little innovation happen in the last 5 years. The last innovation was the brought in by the dot com boom, where people could bank, pay, purchase and help themselves thru self service using internet banking and on-line portals from financial services providers. This has put stress on the incumbent dis-intermediation business models to the extent that some have folded up. I wait for the day to see this happen in insurance industry, where the dot com's today are an additional step adding to the incumbent new business sourcing process for most of the insurance products, barring a miserly few. The reasons for this, is material for maybe another blog post at a different point in time. I am sure, some of my friends from insurance companies will be a bit upset for me having said this.

There are those within the enterprise who are waiting for that dream, that next big idea, something that has not been done before, something unique. Ideaologies that bridge the enterprise vision with what the customers would accept, are more likely to come up with innovations that might work. While one might fight to death on diversity of views w.r.t definition of innovation, one tends to quickly agree to the view that its not about what customer's thought they wanted and most definetly its not about telling the customers what they ought to want. While the latter happens quiet frequently when strategy consultants and IT companies engage with enterprise CIOs!

Some companies in the non-hi tech space, have innovation centres and innovation themes to motivate people to take time away from day-to-day hustle-bustle and come up with new ideas. I wonder how innovation centres, specially in the non-hitech space, measure their performance. I wonder what sort of a yardstick is used to measure their performance and how do they get rewarded at the end of the year. If the innovation centre was belting out one successfull idea a year, we would have seen some awesome stuff coming out from enterprises in the last few years, which is not the case.

In my view the one thing that an innovation department or an innovation center enriches itself with, provided they have a structured approach to the fabric of their life, is validated learning. Without a structured or a framework approach, you would have learning, not validated learning. Companies that adopt lean approach to innovation as a framework and test hypothesis as a structured methodology, gain validated learning. I feel that the innovation centres should not worry about how much stuff they are actually building, but rather measure the amount of validated learning they are accumulating. Learning gained by virtue of exploring ideas directly with the customers are invaluable.


This gives fantastic insights into customer behaviour that could be key to the current idea's success or could break the interia around junking the current idea and exploring a new one. The famous example of this approach was the manager entrusted with the design and development of the Toyota Sienna minivan. He undertook a staggering 53,000 miles roadtrip across US, Canada and Mexico, observing and talking to minivan customers and sometimes driving it himself. The outcome was validated learning! Genchi Genbutsu, as the Japenese say, is the Toyota way to do things!

Another important observation is that not all such endeavors succeed. Successful people have always credited lady luck for putting them in the right place at the right time. For every successful one in the right place at the right time, there were others too, in the right place at the right time, and did not succeed. The difference then has to be that successful people had the foresight, ability and tools to discover what works and what is misguided. Validated learning arms you with this precious treasure, so that you could decide to persevere or pivot; as Eric Ries puts it in his book, The Lean Startup.

Architectures for the new age

The next generation workforce that enters the organisations, come from a world of funky and cool mobile apps and gaming interface users. As this workforce starts interacting with the enterprise apps, comparisons will start being drawn. Two aspects will stand-out as sticky sore points:

1. The user interface and information arrangement on the screen
2. The lack of asynchronous approach to processes

Most of us know how screens of enterprise systems look like. Even though access to corporate digital assets are aligned to the needs of the role and the type of responsibilities employees carry, the screens typically display the master-detail relationship of data with very little effort spent on the GUI design to highlight focus on the few data items that would be responsible for initiating the next set of actions or have a significant role in the decisions that need to be made.

Most enterprise systems are hardwired on context definition and this comes across when we view the screens against the backdrop of changing context on the same shop-floor. The issue repeats itself with enterprise processes. The approach to architecture design around the  context - process - screen design relationship,  reflects organisational preference of operating in the manageable environment of the synchronous, and the sequential, delivering on the first time right paradigm. Having said this, there is a huge management thrust towards getting people to multi-task, be asynchronous, take risks and be flexible on sequencing events and actions in a process to stay relevant in a world of changing contexts. This is the only way organisations maximise efficiency and quality on a fixed cost base.

This is a great paradox enterprises live in. Once this paradox manifests itself on a large scale and starts affecting relevance of delivery to the end consumer, IT systems get labelled as inflexible, rigid and legacy. In the real world, the word legacy has such a positive connotation to it. We all want to leave a legacy behind that we would be remembered for long after we have gone. Legacy however is an uncharitable word when used around IT system! That however is a topic for a different blog post.

Enterprises will find personal devices increasing their sphere of influence in the domain where enterprises will see individuals in employee role, traversing down a path where enterprise data access only on enterprise devices policy will be a hinderance in delivering results. Class of devices will expand beyond smartphones and tablets as we know it today. Multiple devices that are personal, public and enterprise assets will come into play as internet of things expands to consume every thing that has a potential to store, compute, persist, connect and digitally perish. The GUI of this world will dictate the tastes and preferences of the users and will drive behaviour. GUIs of enterprise IT systems will need to align to avoid high training costs and larger learning TATs to get Gen-Next employees effective and productive.

When I take a look at the Metro framework, at a very high level, I see a lot of thought that has been put in to :

•  create a digital UI fashion trend - and an infectious one

•  chart a path forward for enterprise IT systems as they undertake a journey to manifest themselves on the list mile on personal consumer devices.

Metro stands out on the following aspects:

1)    Its a scalable framework ( tempted to say standard, qualifies in my book to evolve as a standard) that could become a standard as it gets device agnostic and OS agnostic. At this moment the framework for mobile smartphones is different from that of tablets. Metro defines, usable and unusable screen areas assuming the world needs only 16:9 surfaces and hence the different framework for smartphones.

2)    Framework has provision to represent master-detail relationships and has guidelines that drive programming behaviour around handling data that is multi row - column tables and scroll. Best practises and the right model to manage activity needed NOW to move forward a process on the timeline in a contextualized environment.

3)    Nudges developers to make asynchrony as the underlying to define behaviour that is responsive to now and always ready for the next. The  nature of next being that no one can foresee the future and hence a tight synchronous process is not the way to build on personal devices. Asynchrony is central to engage, based on decisions and choices consumer make to progress ahead on the timeline.

4)      Guidelines around content being front and central to enable readability puts the consumer instead of enterprise (process ,data and events) in the the centre.

5)    Framework to Win As One that keeps you firmly rooted in the present for you to decide on the next moment, enabling developers to stitch the data of events, relationships, communication threads, facts and status all in a grid format on one screen. Imagine your grid shows the meeting that comes up in the next 5 mins where the agenda is discussion around performance management. One square shows calendar data (just the meeting name and time). Next square shows discussion threats from email around appraisals, one that matter for this meeting. A third square shows the bell curve of your team. a couple of grids displays pictures of your top 5% of your team with rating. This picture is not complete without that one red grid that shows payroll budget over-run telling you that you cannot have a top 5% but a top 3% of your team as high performers! Its your choice if you want developers to write code, that makes this choice!!

The dilemma I have in my head is that Enterprise IT systems are stitched for rigidity and robustness. Hence the processes are sequential. Any data entering thru points of integration, will necessarily have to go thru a synchronous, end-to-end experience.  Last mile architected around asynchrony integrating into a central system architected around sequential end-to-end process thread, are like chalk and cheese. Some thought will need to be given to Enterprise IT Architecture to make this work.

 written for :

BYOD : Issue of classification & personal lifestyle

As people bring in their own devices, the cost of accommodating these devices into the enterprise could far outweigh the cost savings envisaged around not equipping the workforce with such devices. To be able to get the workforce to effectively deploy their personal devices to empower themselves in meeting their goals and objectives; enabling them to take on both the enterprise landscape and personal challenges, one will need investments in infrastructure, security and other digital assets and services apart from the investments needed in planning, governance, monitoring  and management of this way of life.

Enterprises are keen on  BYOD for completely different reasons. Most forward looking organisations today hire talent for their attitude, character and potential of promise amongst other personal attributes that HR folks look out for, as they recruit. Gen-Next India from both the employable and ready to graduate in the next 3 year category, though not digital natives, are immigrants who in the last 3 year have been responsible for the momentum that consumerization of IT has gained. Their attitude and way of life reflects in the kind of devices they carry, the kind of apps they download and the way they use them in their daily lives. It will require some serious imagination on our part to gauge and calibrate the attitude, culture and expectations the digital natives will carry to an enterprise as and when they join the employable resource-pool in the next 10-15 years. Today, every young Indian has a digital lifestyle as a result of the device proliferation and consumerization of IT.  This talent pool leaves digital footprints all over the cyberspace that is indicative of their attitude, culture and lifestyle in general. These people look up such data in the cyberspace to analyze, interpret and take decisions based on the digital footprints of others to decide the nature of relationship they would want to pursue.

As these young people enter the enterprise, they will be bringing their way of life into the enterprise. Organisations that do not change to accommodate the culture of this talent pool and make them feel at home, will be able to leverage little to nothing from this educated, smart next generation. Don't be surprised if people are searching for their bosses on facebook, twitter and four-square to form their first impressions about them. If they don't find them there, don't be surprised if their interpretations manifest as behavior that might seem bizarre to those not tuned in to this culture. Don't be surprise if in a brain-storming meeting a young one suggests a-kin to download this, put it in sky drive , open the app, modify, scrap from there, click this, put together , check with you on Skype to see what you feel and then its a go.  Having been in banking and financial service and having started my career with new age banks and financial service, I can visualize some very senior people (some of them IT leaders) reacting to such a scenario with bewilderment and irritation if this were to occur in their meeting rooms. This will occur. And when it does, and if the enterprises react with irritation and bewilderment at such approach to work-life, the talent pool will look up with little respect both towards the brand and the individuals who represent them. Gen-next will find and very little in terms of alignment between their strong-suite characteristics that makes them productive and keeps them creative, and how they see the enterprise empowering them to excel. BYOD today is seen by enterprises as a way of getting in the new age talent pool and retaining them for the strength they bring in.

There are multiple challenges in going the BYOD way. Among numerous other issues around BYOD, the issue of segmentation of data and the subsequent life-cycle management of the same is complex, one that does not have a solution. As data gets accessed using personal devices, content will be accessed not just to be consumed, but to actually action on the data that was rendered. These actions could result in the need to modify the rendered content or request for more enterprise data to add/modify/delete or create new data - all of this on the go and using personal devices. Editing and creating content will need a store-edit-review-collaborate-despatch cycle to be enabled locally on the device. This is an issue with most enterprises who hate to see their data leave the enterprise network and enterprise storage structures.

There is a need to segment data as enterprise and personal so that it can be governed by the enterprise policies to protect enterprise digital data assets and to cater to personal digital lifestyle and cultural needs of the workforce. This segmentation is a complex issue and has no clear cut solution. As long as the data comes from corporate database, this problem ceases to exist. The problem crops up as one uses word processing, spreadsheet, presentation, design creation, ideation (creation and documentation) and collaboration tools to create, edit and collaborate on content. Ability to segment such content at the time of creation, is a complex problem to solve. A heady cocktail of features in content authoring tools, digital rights management integrated with some aspects of DLP and other document life-cycle management attributes, employee life-cycle management attributes (around roles and access rights) and IT security software attributes will need to be prepared to solve this issue. As a player in both enterprise and consumer space I hope Microsoft finds within itself the right recipe for this Long Island Ice Tea! 

The next problem in accommodating BYOD scheme is to provide for a platform for workforce to go thru the iterative cycle of content creation - review - co-creation - collaboration and then submission to corporate networks in a manner that can be governed and managed effectively and efficiently. My view is that an integrated approach between MDM, cloud storage such as Skydrive / Dropbox / Google Drive and mobile apps can make this possible today. Microsoft as an organization that is a serious player in both enterprise and consumer space, is the right organization to take on this challenge and provide solutions. So, I will stick with skydrive, for articulating the enterprise need in the remainder of this post.

Some changes in skydrive will be needed. Enterprises will need to subscribe for cloud storage in a manner that aligns with enterprise IT Security policies. Microsoft's Cloud On Your Terms approach makes skydrive a good candidate for this solution, if they can pull the solution off. Each employee will need an account on skydrive with two logical partitions ( similar to C and D drive on your desktops and laptops); one where all enterprise data is stored and the other where all personal data is stored. One cloud storage account partitioned to create an enterprise cloud and  a personal cloud for an employee. If the employee leaves, the data does not go away, as the organization has administrative control on the storage cloud. When an employee leaves an organization, similar to the way employee car policies and mobile policies work where the employee pays the WDV and carries the car/mobile device with them, Microsoft will need to provide for merging the enterprise logical partition into an enterprise pool post which the enterprise could give the personal cloud back to the exiting employee in a format where the exiting employee continues to use the skydrive account, in line with Microsoft's consumer offering. To prevent the corporate data from getting downloaded to local mobile device storage, an integrated approach of accessing all data thru an enterprise app integrated with MDM implementation will need to be done. When this employee joins another organization that happens to be a microsoft cloud customer (skydrive in particular), the technology will need to accommodate for creating the employee account with the new enterprise with similar partition logic and pull the new recruits personal cloud as a partition into the corporate skydrive account. This keeps employees personal data persistent as employees transition organizations or even change roles (employee/customer/partner).

The bigger problem though is of segmentation. Pure-play consumer organizations like Google might not be willing to solve this problem. Microsoft which plays both in enterprise and consumer space should take this problem up and resolve it. Doing so, Microsoft will end empowering its customers to attract talent pool that can usher in creativity and agility into an enterprise.


written for :