I am an IT principal at ThoughtWorks. Currently helping with IT organization design - one of the key bottlenecks for continuous delivery. Previously served as leadership coach, director-innovation, founding member of ThoughtWorks Technology Advisory Board and agile coach. Recently helped with product innovation and advocacy for Go. Hat collection includes developer, manager, architect and trainer. Irregular blogger and speaker at conferences.
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.
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
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
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.
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.
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.
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?
A series on post on some common anti-patterns of knowledge management
End-to-end automated build and deployment pipeline with Maven, Chef and Go, Studios webinar, March 2013
Maven based build pipelines are fairly common. Chef based deployment pipelines are also gaining traction. In this demo, I demonstrate how to design and connect the two using Go. Along the way I explain why not to use maven-snaphosts, how to make Chef talk to Nexus and provide several tips on Go usage. The resulting end-to-end automated build and deployment pipeline provides overarching visibility, traceability, orchestration and access control for the entire continuous delivery value stream.
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.