Profile

I am an IT principal at ThoughtWorks. Helping clients with IT organization design at present because it is one of the key bottlenecks for digital transformation and continuous delivery. I have previously served as leadership coach, director-innovation and founding member of ThoughtWorks Technology Advisory Board. Recently helped with product innovation and advocacy for Go. Hat collection includes developer, manager, architect and agile coach. Occasional blogger and speaker at conferences.

Upcoming Book (ETA: Q1-2015)

Agile IT Org Design

Talks and Writings

Product Management

Product Advocacy

Agile Software Delivery, devops

Innovation

Communication

Knowledge Management

IT Org Design

Tech

Creative writing etc

Product Management

Deriving Product Intelligence, BAConf, Aug 2013

slides

For any product that has users and a future, input for product direction come in from different quarters. - product marketing and sales guys, product manager's vision, existing and prospective customers and so on. Here's a way to structure the input so as to derive product intelligence.

Product Advocacy

A blog on how to make the best of Go

Agile Software Delivery

Administer the devops pill across the enterprise, devopsdays Berlin, May 2013

slides

devops addresses the last mile of continuous delivery. It advocates the tearing down of development and operations silos. It kind of assumes that silos don't exist elsewhere. This is often not true in enterprise IT where the number of silos correlates well with the number of vice presidents.

This anti-pattern of org design takes two forms. One is when you have a VP sw-dev, VP Data, VP configuration management, VP Testing, VP UX, VP Deployment. The other is when you have a product manager along with a VP Sales, VP Marketing, VP Support and VP Training. On the other hand, an org design based on true cross-functional teams has teams accountable for business outcomes and puts one person in clear charge of each team. This part of getting things right can be classifed as CD for execs and basically involves applying the devops pattern to general org design. There is also a part two.

Tooling can also hinder cross functional behaviour. Especially when access to tools are granted on a strict need-to-use basis. So for example, only sales guys get salesforce access. Or when marketing disallows self-service publishing from the product teams. Or when the devs use one tool for continuous integration and the deployment teams uses a completely different disconnected tool for release automation. Sometimes commercial considerations (licensing costs) encourage this behaviour but it doesn't serve the cause of tearing down silos. So we need a new kind of culture that restricts access to tools only where unavoidable but is open otherwise.

Why continuous delivery needs devops, and why devops needs infrastructure-as-code, ThoughtWorks Studios webinar, Oct 2012

slides

Continuous delivery and devops have gone mainstream, at least in terms of mindshare. As a result, a lot of vendors have jumped onto the bandwagon. Most products that have anything to do with deployment now try to associate themselves with devops and continuous delivery. In this webinar, I try to clear the air in a product independent manner. I also cover common devops anti-patterns and explain the idea of infrastructure as code.
As it turns out, this is as much a talk on the design of an effective Agile IT Organization design as it is a talk on the stated topic. Things are inter-related.
A few good development metrics, Agile India 2012, Bangalore

slides

The problem with metrics is that there are so many to choose from. Lines of code, rule violations, dependency matrices, cyclomatic/npath complexity, code coverage, duplication - the list goes on. Tracking all of these results in too much data and too little insight. In this talk, we will see how to narrow down to a small set of useful metrics. We'll also see how aggregate metrics like toxicity help reduce the tracking footprint. Finally, we'll look at the difference between a measurement and a target and see why measurements should not be simply converted into targets.
Some 'Agile' anti-patterns, Agile NCR, July 2010
Brings out some anti patterns across the specturm of Agile software delivery. The issues covered include misuse of velocity, points based estimation, iterative versus incremental development and pair programming. Here is a podcast on similar lines.
What they didn't tell you about architecture in agile development, ThoughtWorks Studios Agile Webinar Series, June 2010
Introduces new ways of looking at the overall philosophy of Agile. How this influences architecture. Some anti-patterns of enterprise architecture.pdf
Agile Goes Mainstream, NASSCOM Quality Forum, Hyderabad, Nov 2006
Agile methods are no longer confined to a select band of Extreme Programmers. Agile adoption is increasing being driven by clients seeking lightweight processes and working software over comphrehensive documentation.
Demystifying Agile, NASSCOM Quality Summit, Bangalore, Sep 2006
What better place to demystify Agile than the hallowed haunt of CMM enthusiasts? This talk focussed on metrics and documentation.
Some ideas behind Agile, Agile India, Mar 2005
Code is Design, No ivory towers, Documentation is an intermediate product, A knowledge organization has to be people dependent in the collective sense.

Communication

How we annoy colleagues with lazy communication, Jan 2012, xConf Pune

We tend to use stock phrases when discussing work with colleagues. For instance, haven't you heard these phrases used inappropriately, "It's not rocket science", "Let's not overengineer it", "I know the situation is less than ideal" etc. These phrases may annoy the receiver, she may take it as an insult to her intelligence. Using such stock phrases without delving into the matter at hand is an example of lazy communication. This talk will try to sensitise us to lazy communications and its detrimental effect on work relationships.

Innovation

Understanding Innovation, K-Community meetup, Bangalore, June 2009
This talk is based on my tenure as Director of Innovation for ThoughtWorks India. It covers different aspects of nurturing innovation: Understanding organization specific motivators for innovation, Techniques of fostering innovation within a knowledge organization, Exploring if there are predictable outcomes, People factors, How much does it cost?

Knowledge Management

A series on post on some common anti-patterns of knowledge management

IT Org Design

Mere uniformity does not make for consistency
tl;dr and visualization abuse
How email shapes us... and how to get back into shape
Measurements and targets: The use and abuse of metrics
Tools aren't value neutral
How to do XYZ in Agile?

Tech

Choreography over orchestration, July 2011, xConf Chennai

The ThoughtWorks tech radar once talked about choosing Choreography over Orchestration. I explain this using real world examples and touch upon some other points of service orientation along the way.
The new rules of technology, ThoughtWorks BizTech Series, Gurgaon, June 2010
All industries go through periods where a critical mass of players start playing according to new rules. The software industry is undergoing one such period. Those who understand and equip themselves to play by the new rules will thrive. This does not just apply to software companies. It applies to software professionals as well. The talk calls out new rules in diverse areas such as software innovation, structure of software teams and software architecture.
ThoughtWorks IT Matters Podcasts, Feb 2008

REST part 1, part 2
In this two-part series, Martin Fowler, Chris Stevenson, Jim Webber, and I discuss REST (Representational State Transfer). We touch on the history of REST, a detailed explanation, and examples. Additionally, we discuss programming with the Web today, modeling your resources, types, RESTful enterprise development, and reuse.

A demo of the browser security model for XHR, devCamp Chennai, July 2010
A basic demo of the same origin policy, jsonp and the new CORS (cross origin resource sharing) spec.