Interview with Nari Kannan on Distributed Agile development

This week I had the pleasure of chatting with Nari Kannan, the CEO of Ajira Technologies, about distributed agile development. Nari has a global R&D team, located in Silicon Valley and India, and has written extensively on Agile, global development, process improvement, and business intelligence. Nari's team uses Agile methods as a way of ensuring frequent, quality communication, and building usable, useful products that are successful in v1.0.

Tell us about Ajira.
Ajira is dedicated to innovating software solutions for Continuous Business Process Improvement. The Toyota Production System and Lean Six Sigma have traditionally concentrated on bringing Efficiency (Doing things right) and Effectiveness (Doing the Right Things) to Manufacturing. They concentrate in eliminating non-value adding steps in the manufacturing process and speeding up other value adding steps. For example, painting a car door is a value adding step. Filling out the paperwork after fitting a door to a car does not add any value to the buyer of the car. So why not eliminate it? Ajira wants to bring the same kinds of approaches to Business Processes through software products. So if the Passport Office says that it takes 6 weeks to process your application, can you ask the question, how can they do it in 3 weeks? How about 1 week? How about same day service? All of these are possible with relentless continuous process improvement!

Business Process Improvement starts with being able to collect and analyze process Key Performance Indicators (KPIs). These can be efficiency related like Claims Processed Per Hour or Effectiveness related like Value of Policies underwritten in a day. Ajira products help collect business process KPI information, store them in n-dimensional cubes, and slice and dice them for Process Insights. These process insights will help improve business processes by highlighting bottlenecks in the process and the right things to spend time on.

I understand your R&D team is distributed between Silicon Valley and India. Tell us more about how your team is structured.
We are a very small startup that cannot afford to waste even a second. All of the Engineering Requirements and Design are done in the U.S. The development teams in India are headed by project leaders in India who are totally responsible for translating quick and dirty requirements and design documents into software versions and builds.

When people think of outsourcing development, they often think of waterfall, or big-design-up-front. When does agile make more sense?
Simple, well understood, standardized functions like Accounting, Order Management, etc are very suitable for waterfall model since requirements are clearly understood, may not change much and are easier to put down on paper. Agile makes sense when the requirements and the designs are themselves subject to frequen change. Very new functions or highly innovative software products or applications where the requirements themselves are discovered iteratively, Agile is the only way to go. If there is an existing mainframe application and you are creating a Windows or Unix version of the same, Waterfall model is appropriate since you can specify the system clearly upfront.

Innovative software products are work in progress at least until V3.0 or V4.0. It is well documented that early users of Oracle or SQL Server database management systems did not have a stable predictable product until at least the third or fourth major version of the product, suddenly creating mass adoption. For inn,ovative software products you want to get to this stable product as quickly as possible, sooner than V3.0 or V4.0, and Agile methods provide you a way of getting there that much quicker.

What are some questions a VP of R&D could ask of himself and his team to know if they are ready for distributed agile development, or whether they are better off using more waterfall processes?
Agile methods are just one more way of increasing the Frequency and Quality of Communication. If the requirements are well understood and simple, waterfall is the more efficient and effective way to go. If you know that the application or the product is going to evolve over time, Agile methods increase the Frequency and Quality of Communication. If the developer knows fully well that the person providing the requirements is only guessing at what the requirements could be and could change his/her mind about it, Agile provides a way of getting something in their hands quickly. It is easier to REFINE requirements than to specify requirements clrealy upfront, especially when you don't know what is important to your client or customer. This is what Agile methods enable; ways of frequently getting something working that the end user can see and use, and provide feedback about.

What do you think are the top three best practices for making agile successful in a distributed team?

1) Rapid and Frquent Communication - Agile does not mean no documentation. It just means that you are very effective and efficient with your requirements and design documentation. Two or three pages. This also means leveraging a communication pyramid diligently - Yahoo or other Chat methods everyday, written quick progress reports every day or week, and face to face in-person communication, even if the team is 10,000 miles away - at least a week every two months.

2) Frequent Builds and Releases - Every week or every two weeks you need to have a build released and tested fully. You can leave out features if you don't think you can finish them in time for the next build, but a build needs to be done without fail. This enforces all code developed in distributed teams work together reasonably eliminating compatibility problems early on. If you postpone a build, you are just postponing addressing problems in different developers' code from working together.

3) Flexible Project Management - Projects need to be managed somewhat flexibly within the one or two week build timeframes. If a key feature needs to be addressed soon, a one week build can become two or even three. The idea is to identify what you think may be difficult implementaion issues and address them earlier rather than later. This way you don't postpone tricky problems till the last minute.

What are a couple of pitfalls or traps you see people falling into when doing agile in a distributed team?
Not understanding the deeper reasons on what makes agile methods work. The deeper contribution of agile methods are that they enable communication - the no.1 reason development projects fail. Agile methods allow the developer to say every week or every two weeks " take a look at this - is this what you meant when you said you needed feature X?". This way misunderstandings with requirements are dealt with early and periodically.

Agile rituals followed without understanding why they are needed and how they need to be practiced for them to work is the biggest pitfall in a distributed team.

You’ve mentioned that you’re applying the Toyota Production System to your development processes. That’s somewhat unique in the software world. What aspects of the Toyota Production System do you think are well suited to building software?
The biggest contributions of the Toyota Production System are Iteration, Elimination of Non-Valued added activities and involvement of everyone in the manufacturing process in decison making when changes are made to the production floor.

Iteration is the heartbeat of Agile Methods. You develop the right software by iteration - include a few features in each build and get feedback from users. Problems are eliminated slowly but surely. You converge to what is needed perfectly, quickly. The same thing with Toyota Production System - any new Toyota factory takes two to three years to come up to full production. They address each problem thoroughly!

Elimination of Non-Value Added steps - Requirements Documents need not be 50 pages long. Requirement Documents and Design Documents are necessary evils. To the end user the time you spend putting in validation routines adds value to the user. The requirements and design documents are only for the developer. They are of no use to the end user. Doing them as short as needed without sacrificing the Frequency and Quality of communication is the trick!

Involvement of end users in the development process is earlier on in agile methods than in waterfall methods. Agile methods enable end users to see the results of their communication earlier on and validate them with actual software use.

You’ve also mentioned Lean Six Sigma, and how there are some parallels to agile development, especially how they approach continuous improvement. Tell me more.
Agile methods can become dogmatic and ritualistic, and as useless as Waterfall methods if developers don't understand where they should be applied and where they should not be. For example a simple requirement can be just a single bullet line in a document. However if what you are designing a complex workflow, borrow UML modeling or State Transition Diagrams and capture the workflow accurately.

Lean Six Sigma and Continuous Process Improvement are useful in software development since every development project has its own characteristics with respect to complexity, solidity of requirements etc. Being able to quickly assess what is working for your development and what is not and making appropriate adjustments are what Lean Six Sigma and Continuous Process Improvement teach you!

What one or two pieces of advice can you leave our readers with who are thinking about moving to a more agile approach with their global team?
Software Development is 80% communication, 20% software skills, milestones, and everything else. Get the communication right. Everything else will follow. The end goal of software development is developing software that somebody can use to do something useful. Programming Languages, Specific methods like Scrum or other Agile methods are all tools in accomplishing that end goal.

A master carpenter will use his biggest chisel to fashion a crude toy for his child. He wil use the best of his woodshop to carefully measure, and use all of his powertools to craft a fine dining table. Becoming a master carpenter is knowing when to use what tools, and how much time a task deserves.