Topics

Featured in Development

As part of our core values of sharing knowledge, the InfoQ editors were keen to capture and share our book and article recommendations for 2018, so that others can benefit from this too. In this second part we are sharing the final batch of recommendations

Featured in Architecture & Design

Tanya Reilly discusses her research into how the fire code evolved in New York and draws on some of the parallels she sees in software. Along the way, she discusses what it means to be an SRE, what effective aspects of the role might look like, and her opinions on what we as an industry should be doing to prevent disasters.

Featured in Culture & Methods

Mik Kersten has published a book, Project to Product, in which he describes a framework for delivering products in the age of software. Drawing on research and experience with many organisations across a wide range of industries, he presents the Flow Framework™ as a way for organisations to adapt their product delivery to the speed of the market.

Featured in DevOps

The fact that machine learning development focuses on hyperparameter tuning and data pipelines does not mean that we need to reinvent the wheel or look for a completely new way. According to Thiago de Faria, DevOps lays a strong foundation: culture change to support experimentation, continuous evaluation, sharing, abstraction layers, observability, and working in products and services.

Naresh Jain: Crazy! Just like the Indian Traffic system - Managed Chaos! One needs to have an admirer's eye to appreciate its beauty.

Over the last 7 years, I've seen many companies gradually test the 'Agile' waters and beginning to swim. Vast majority of the organizations in India, be it large IT companies, small boutique companies or mammoth offshore R&D centers, they've all surely been influenced by Agile methods.

Just like in other parts of the world, even in Asia, the product companies are more serious and rigorous (not necessarily more successful) with their Agile implementation.

If you visit companies and actually talk to people at different layers, boy, they'll tell you about the crazy ride they've had so far. Blame the outsourcing nature of work, lack of understanding of these methods, a hierarchical society or plain incompetence in some cases. <sarcasm>Only if we had a 3-Day Scrum Master Certification course the world would be a better place to live.</sarcasm> The truth is, that the journey has just began and the real fun part of the ride is yet to come!

InfoQ: Do you think Agile is getting adopted seriously only by startups and smaller software shops or is it making its way into larger companies?

Naresh Jain: One thing about wildfire is, when it spreads, its spreads from all directions. Today I see 95% of software companies in India toying with Agile. Its trendy these days to say we do Agile right? When I see companies going for Agile, in some cases its due to desperation, in some cases due to customer or onsite pressure and in some, just a marketing gimmick. Sometimes it feels like deja-vu. Did we not see something similar with CMM a decade ago?

However I've been fortunate to have worked with a few companies who truly believe in the spirit of Agile. They understand its not about "doing" agile, its about "being" agile. A very Zen thing to say!

InfoQ: One of the biggest revenue generators in India is currently the IT Industry. Large outsourced projects often entails heavy amount of upfront work to determine scope, which is controlled very carefully throughout the project. Is there a way Agile can be used on outsourced projects?

Naresh Jain: We humans, build a mental model of "stuff" and try to fit the world around us in that model.

A few years ago, the mental model for software development was that of "an assembly line." This mental model would unfold as follows:

Step 1: Plan and Strategize (fantasize a little bit here and there)
Step 2: Document every little detail
Step 3: Define a rigorous process to let you treat people like cogs in the wheel
Step 4: Find cheap labour
Step 5: Ship the work to them by having a very strong contract of Do's and Don'ts.
Step 6: Define best practices to manage the execution
Step 7: Iterate...
Step 8: Ta-da Get fabulous results.

Unfortunately very few projects survived beyond step 7. Most were off in the wild sprinting.

Apart from having numerous other flaws, this model under-estimates the importance of trust, shared understanding, collective ownership, pride and adaptability.

Such projects are doomed to fail. Whether outsourced or not. <sarcasm>Of course, outsourcing along with offshoring gives you the best bang for one's buck.</sarcasm>

Its a proven fact (at least to me) that distributed development is hard. Offshoring is even more harder and outsourcing & offshoring is the hardest. However, as we've seen, there are valid business and management justifications for outsourced offshoring models. (Not for all projects.)

Given that's its a compromise, I've seen agile and lean thinking quite helpful in such situations. For E.g.

Its hard for us to plan too much in advance with high certainty. Agile methods give you a basic model to manage this uncertainty

I've helped organizations implement a lightweight RFP process. We've actually submitted a MVP (Minimum Viable Product) in response to a RFP and won, despite being 3 times more expensive than others

More and more customers are asking for shorter release cycles and more involvement

Better transparency on both sides and a sense of partnership is a common place in some outsourcing companies

IMHO Agile and Lean thinking have drawn attention to some very important, but often neglected aspects of the outsourced development model. And greatly reduced some of the pain in the process. We still have a long way to go.

InfoQ: What about contractual details of an outsourced project? How do you negotiate a contract with a customer executive, who wants to know what she is getting for the budget/timeline set?

Naresh Jain: Typically in cases where the trust is low (working for the first time), customers want to know what they will get and when they will get for X amount of money. And in some context, I think its fair to ask that.

The real problem though is that its hard to estimate vague things. At the beginning of the project we've the least amount of knowledge.

To address this problem, I typically encourage organizations to start with a Product Discovery workshop (PDW). Typically 1-2 weeks long. We initially sign a Master Services Agreement (MSA) with the customer. Under the MSA, the first Statement of Work (SoW) is typically for the product discovery workshop. This has a clear start time, end time and list of deliverables.

At the end of Product Discovery workshop, we have a high-level release roadmap. From this roadmap we pick the first slice, do some initial spikes and estimate (guestimate) the effort involved. Under the MSA, the second SoW is for the first slice in your roadmap. Fixed price, fixed date.

Like this we break down the large product roadmap into smaller SoW contracts and execute the project. Sometimes after the PDW, we can sign a single SoW for the entire release roadmap. All depends on how confident both sides feel.

This is agile way of planning fixed price outsourced contracts in my experience.

InfoQ: There are various methods/frameworks for being Agile like Lean, Scrum, Kanban - which ones do you think are seeing more adoption in Indian companies?

Naresh Jain: Scrum appears to be the easiest to get started. Compared to all the other methods/frameworks, Scrum seems to threaten the (Middle) Management the least. After all, they have the pockets loaded with money and the decision making authority, in most cases. Tie it with the certification racquet and you have a killer. (A real Agile killer!)

So there is no doubt that in Asia and World wide, Scrum seems to be the most widely adopted (at least tried to) Agile method.

But what does that really mean? Project Manager should be called Scrum master from now on. Teams should call requirement as User stories instead of Use Cases or whatever they used to call them if they had any. Everyday, there is a 30-45 minutes drill in the evening (to make sure onsite team member are part of the drill.) A bunch of new fancy (expensive) tools. Every team member is measured with a new metric called Burn-down chart. More frequent late-nights and weekends. A night-mare for the (traditional) testers. Every 30 days or so, the team has to show what they've tried to build in the last 60 days. And best part, the "customers" can change their mind at any time.

If you asked me which is one of the most effective method, that would be interesting.

InfoQ: Which are Agile methodologies do you think are seeing better results in India?

Naresh Jain: Null Process - Where companies stop chasing processes and methodologies, as if they were the real thing that solved hard software development problems. Null Process encourages companies to forget about process and focus on their business and the people behind the business.

At the Agile Mumbai 2010 conference, Sandeep and I ran a workshop called "Monkey See Monkey Do" to encourage companies to forget and move away from the process thinking.

InfoQ: There are courses related to Agile software development being introduced in curriculum by some Indian universities - could you shed more light on this?

Naresh Jain: Over the last 7 years, Agile Software Community of India (ASCI) has worked with many Universities in India to introduce agile concepts into the education system. We've organized several conferences at top Universities in India to get more involvement from academics. We've organized Refresher Courses for Teachers from all over India.

Similarly other Universities like PES College of Engineering, Acropolis Institute of Technology, Symbiosis Institute of Computer Studies and Research, Anna University and PSG College of Technology have introduced various eXtreme Programming practices into their programming courses.