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 :

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 :