Agile FAQs
  About   Slides   Home  

 
Managed Chaos
Naresh Jain's Random Thoughts on Software Development and Adventure Sports
     
`
 
RSS Feed
Recent Thoughts
Tags
Recent Comments

Archive for the ‘Distributed Development’ Category

Agile India 2012 Conference – Call for Stage Proposals

Monday, August 8th, 2011

Update: Stage Proposals are closed.

Sessions proposals are open now; visit: http://submit2012india.agilealliance.org/proposals

Transcending Cultures, Timezones and Countries

Saturday, July 3rd, 2010

At the Agile Mumbai 2010, Mahesh Baxi takes you through an exciting journey of key lessons learned from one of the largest agile projects executed at ThoughtWorks which will cover:

  • Key agile principles
  • What challenges comes along with the scale of up to 200+ people with added complexity of distributed location
  • How is it different from other agile projects in terms of planning ahead, release plans, scope management, infrastructure
  • Communication – The most important ingredient for large scale agile projects to be successful
  • What kind of team structure would work best?
  • How to stay focused? How to identify bottlenecks and work through them

Remote Pair Programming

Tuesday, April 13th, 2010

Since I’ve started working for Industrial Logic, I’ve spent a decent amount of time pair programming with folks in the US. Yes, we do Remote Pair Programming.

Quite a few people have asked me:

  • What special editor or tool we use for remote pairing?
  • How effective is the pairing?
  • How much time is spent in setup each time?
  • How long does it take for one to get used to remote pairing?

Here is my answer:

The most important part of pairing is free flow of ideas between the 2 individuals. Its about the brains of the 2 individuals being at the same wavelength so communication can truly take place. Tools can certainly disrupt or get in the way of this flow. But IMHO the individuals contribute 80% towards the success of the pairing experience, tools contribute 20%. Skype with Video Sharing lets us achieve 80%. Better tools might improve that. We’ve experimented with some Eclipse based plugins, all of them have their trade-offs. There is no clear winner. Also on our team since we’re all used to Skype for conference calls, the threshold to get started is very low. So my recommendation is to get started with simple tools, something that you are already familiar with. When starting anything new, focus on the crux and not on the peripheral stuff.

For a more introductory material on pair programming refer to Pairing FAQs.

I’m not Attacking the Agile Manifesto Principles, I’m begging for Improvement

Friday, March 19th, 2010

In 2001, following were a great set of principles for a Software Development team.

  • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  • Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  • Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  • Business people and developers must work together daily throughout the project.
  • Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  • The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  • Working software is the primary measure of progress.
  • Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  • Continuous attention to technical excellence and good design enhances agility.
  • Simplicity–the art of maximizing the amount of work not done–is essential.
  • The best architectures, requirements, and designs emerge from self-organizing teams.
  • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Today I think some of them needs to be re-looked at for the following reasons:

  • Nature of Business: Internet has changed the face of businesses across the world. E-Commerce is an integral part of every business model today. Most businesses are going global, driven by the global demand and open economies.
  • Distributed Development: The world is more connected but at the same time more distributed than ever. Distributed Development is no longer a cost-saving scheme. Its become a necessity to take advantage of the global economy and un-even distribution of talent.
  • To think about it, Software Delivery is no longer the biggest bottleneck
  • Tools and Technologies have come a long way in the last decade. Esp. if you look at one aspect about Software development, .i.e. ability to quickly build and deploy software, its extremely simple and fast today. Tools like Google App Engine; Content Management System like Drupal, Django, CMS Made Simple; Light Web Frameworks like Rails, Grails, Cake, Seaside, Lift + Services like Heroku, Amazon EC2, Engine Yard Cloud. These clubbed with Social Networking Platforms, makes it trivial to get, if not thousands, at least hunders of impressions everyday.
  • In the Web 2.0 and Mobile space, companies are investing a lot of effort to building platforms over building apps. Building platforms and exposing APIs for others to build Applications is a quite a different ballgame.
  • There has been an explosion of the programming language and frameworks in the last decade.
  • And so on

Personally I would like to change/update the following principles:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

To think about it, Software is just a means, not an end in itself. Enabling and empowering the users and businesses is more important. Quite often we find development teams building a lot of wonderful software, which might even seem useful, but rarely does it truly enable the users. So I would rather have a principle which states very clearly that enabling and empowering the users & business is more important than building software. In fact, lot of times, I believe the best way to enable users and businesses is to provide them with little or no software.

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

The whole notion of requirements seems so 20th century-ish. Requirements have a “mandatory” connotation. Agile is about collaboration and co-evolution of users needs. Also this principle feels more geared towards services or in-house IT shops. For product companies this is given. IMHO the spirit of this principle is that we should acknowledge and work towards letting the software evolve. Better the collaboration and feedback, better will the software evolve to being more meaningful.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

With the technology we have today, companies are deploying software multiple times a day. People are talking about Continuous Deployment, Perpetual Betas and so on. Yet, there are companies in the embedded software space (consider chips being embedded in your brain or software controlling your car) where deploying has a very different meaning and risk.  I like the spirit of this principle, but I see way too many companies delivering working software which does not result in any feedback. Which does not result in any inspect and adapt. I feel they are missing the point and the principle needs to explicitly state that its the feedback and inspect-n-adapt that is important, not the dumb delivering part.

Business people and developers must work together daily throughout the project.

As I understand the objetive of this principle is that business people and the developers collaborate, they understand each other’s point of view, they have more visibility into the decision making process, to help build the trust and respect, and so on. Personally I feel drawing a line and saying these are the business people and those are the developers rather creates the anti-collaboration pattern (at least sometimes). It also leads to “not-my-problem” attitude. I feel eating your own dog food, in some cases, is a very powerful technique. I guess these days I’m more and more leaning towards not differentiating between business and development. Those are 2 perpectives, that everyone on the team needs to have. Some will have more of  one and less of the other.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

I completely agree with this. However, IMHO a lot of companies just pay lip-service to this. Even if they manage to hire motivated individuals, within no time they converte them into Zombies. Companies fail to understand what motivates individuals. Motivation is not a “thing” that can be achieved by claiming we are going Agile or declaring the team is self-organized. Different things motivate different individuals at different points in time. IMHO, one of the most important things for individuals is to have a sense of growth & learning. Having a sense of ownership and control. This really is about organizational cultural change. Quite a few start-up companies have the hunger and passion for success, to achieve something. You’ll find real motivation in these places.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

While I believe in face-to-face communication, I would not say its the most efficient and effective method to convey information in all contexts. There have been many cases when I could have chosen f-2-f discussions, but I choose to collaborate over the wiki. Sometimes discussions can be too fast for me to catch up or too slow to be patient. Sometimes one needs the space to think and research. Sometimes language can be a barrier to communicate. Open source projects don’t do f-2-f communication, they still seem to collaborate on extremely complex projects. There are times when f-2-f is extremely important and times when its not. There is simply no “the best”.

Working software is the primary measure of progress.

I would say enabling and empowering customers is the primary measure of progress. Sometimes we can make progress without creating any software. And sometimes getting rid of software helps us going faster. For ex: Lot of teams get zapped with Agile Project Management tools. You replace it with index cards on a wall and they progress much faster.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

To maintain a constant pace indefinitely is not sustainable. Let it be running, exercise or software development. Software development is a creative, problem solving, highly collaborative activity. Its not clear to me how to maintain a constant pace. As humans, esp. Software artists, we are not productive linearly. There are times when we are ultra productive and there are times when we have no idea what we are doing. I’m not questioning the need for Sustainable Pace. The interpretation of sustainable pace is very questionable. People dumb it down to a very mundane, clocking x hrs per week makes something sustainable. I think there is lot more to sustainable pace. I’ve worked on lots of projects were we have clocked more than x hrs every day and were able to sustain it for at least a few months. Looking back, I’m very happy I did. I would argue that if you enjoy doing something and truly believe in it, sustainable pace automatically falls in place.

Continuous attention to technical excellence and good design enhances agility.

As much I would love to agree with this, when I look around that the software that I happily use, they force me to disagree. Certainly technical excellence and good design is important, but there is a trade-off and its important to learn where to draw the line. Alas this is not easy. However these days building software is very cheap and one can afford to throw away working software more rapidly. In some context its cheaper to throw away software and rewrite it than to slowly, carefully, refactor it.

On a slightly different, but related note, a lot of people say Technical Debt is evil and one should stive to have Zero debt. This dogmatic statement clearly shows lack of business accumen. Short-term, low interest debts can be very effectively used to one’s advantage.

Simplicity–the art of maximizing the amount of work not done–is essential.

This is indisputable. Simplicity, simplicity, simplicity. I’m all for simplicity. If we can solve a problem without writing any software, that’s true simplicity. These days I have a habit of asking, “Do we really need any software? Can’t we do without? If we really need software, can we reuse something that’s already out there?”.

The best architectures, requirements, and designs emerge from self-organizing teams.

Software development is a co-evolutionary process, so there is no doubt that good architecture and design will evolve and exhibit an emergent behavior. Certainly a team who owns the software, cares about it and is passionate about it, will really help in the evolution.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

I love the spirit of this. Inspect and adapt is important. But be aware of retrospective coherence & premature convergence. Also its important to understand my regular is not your regular. For teams which are doing iterations and sprints, may be end of the time-box is a regular interval. For some its too late. And for some who don’t do time-boxes, what is regular? What we certainly don’t want is more episodic ceremony. When something important happens, why wait? Why not tackle things as and when they occur. Even if we don’t resolve the issue, it’s worth at least a quick discussion. May be we practice “5 Whys”.

Conclusion: These principles were a great starting point. Today, one needs to evaluate them in their current context and see how this maps to them based  on the points I’ve highlighted.

Agile and Developing Nations

Thursday, January 7th, 2010

Developing nations, which are trying to establish themselves as a IT Destination have to fight against the giants in the out-sourcing world. For many years companies used CMM as a way to get some attention. But CMM is

  • heavy weight,
  • expensive to get assessed
  • does not really fit small companies’ (20-50 people’s) needs.
  • Also in the last few years CMM has got a pretty bad reputation and hence its not necessarily a great marketing advantage.

Considering all this, what do companies do? What is the new shinny thing they should all run after. ..ta..da… Agile & Lean.

  • More suitable for their needs,
  • Some Customers are asking for it
  • Is also trendy and gives the marketing advantage over the big outsourcing companies.

Distributed Agile Presentation from Agiles 2009, Brazil

Monday, October 19th, 2009

State of Agile Adoption in India

Tuesday, July 7th, 2009

Lot of organizations in India are considering Agile.

  • Agile Adoption in Services Companies is mostly driven by customers and competition.
  • For product companies its all about
    • Improving productivity,
    • Reducing time to market and
    • Better quality.

While these companies are adopting agile, they have lots of concerns and questions. One recurring theme I’ve seen, is all these companies are really really afraid of failure. IMHO, this fear leads to a very dysfunctional agile adoption. Teams pick what is easy to do and what fits into their existing model, in the name of reducing risk, call it fail-safe 😉 . With this approach individuals and companies fail to see the real benefit of Agile.

This issue is compounded by the fact that a lot of companies are selling substandard certification, tools and consulting.

Also most Indian companies work in a distributed model. Distributed development is another challenge teams are facing and they don’t really see how to fit Agile in their distributed context.

All these points put together makes it very difficult for team to succeed.

These are my biggest concerns today with Agile adoption in India. Does this ring a bell? Can you share your thoughts?

I would be really happy if you want to share your agile adoption story with the agile software community of India. If you can address some/all of the following questions it would be great:

  • Why did your company decide to consider Agile?
  • How did you build a business case for going Agile? Can you share some artifacts from this original business case?
  • Who all was driving this change?
  • What measures were taken to set realistic expectations with both Management and Development teams?
  • Did you start with a Pilot project? If yes,
    • What were the criteria for picking a pilot project?
    • What was required to get the pilot project up and running?
    • Was the pilot project a success? What were your success criteria?
    • Post the pilot project what did your organization do?
    • How did you roll out Agile to rest of your organization based on your learning from the Pilot project?
  • From when you started to now, can you give us important milestones and some artifacts with regards to the same?
  • Was there a key turning point in this journey? If yes, what was it?
  • Looking back, what mistakes you think could/should have been avoided? And what mistakes you think were worth committing?
  • Where is your journey with Agile heading? What are your future plans?
  • What does a typical day in life of each team member (developer, tester, manager, etc) look? Any pictures/artifacts you can share?
  • What impact did Agile have on your organization structure?
  • What mechanisms did you use to guide your teams if they were going down the right direction?
  • After having gone through it, do you think it was worth it?
  • Any thing else you would like to share?

If you can’t get Distributed Development working, your company is doomed!

Tuesday, June 10th, 2008

Today Distributed Development is unavoidable and is the need of the hour.

My belief is that if you have the “right” set of people, motivated and happy on your team, it will be a huge contribution to the success of the project. But the problem is most often “right” people are distributed all over the world and not located in the same city. A lot of organizations have tried to move people to the same city so that they can be collocated. While this might work to some extent, this model cannot scale and is not sustainable. All of us would like to settle down in the location of our choice. We don’t want our work to dictate where we live and what lifestyle we choose. For example, I like to live in India close to friends and family. So far I have traveled quite a bit, but once my daughter starts going to school it would be very difficult for me to relocate to another city.

Also if you consider a lot of leading companies they are loosing a huge amount of people, because most of those employees don’t want to travel/commute any more and want to settle down in one place. While tele-porting is a few centuries away, employees have to live with stressful commute everyday. Not only this is a huge wastage of time, it also affects your productivity and makes your family life very stressful. Currently most of the successful companies have offices in multiple cities. One of the main drivers for having multiple office in different cities is to attract local talent. If your company does not plan to have a office in location X, guess what, your competitors will open an office and you’ll loose some of the smartest folks you could have other wise hired. And when you have multiple office, guess what, people in different offices have to work together. This is another reason why distributed development is becoming more and more important.

In Agile we talk about having development and business teams together. It is very critical to have constant business involvement. But what do you do when your Business is distributed? Because of the global economy most businesses have global presence.  Also each region might have slightly different business rules or market. Hence it is very important to have development teams close to local businesses and distributed. This again leads to distributed development.

Another point to be aware of is, if we consider what industrialization has done by building power centers in industrial cities leaving the rest of the country really backward. We don’t really want IT to do the same thing to the country’s economy.

If you consider these practical issue, collocated team model turns out to be unrealistic in the long run. The chances are you will have to compromise on the quality of people or have the team members travel a lot if you want all of them to be collocated. The alternative is to build a model where the team members can be distributed across space and time.

Unfortunately so far, we’ve not had great results with distributed development. A lot of people have published their experiences trying to effectively work in distributed teams. For some it has worked or some it has not. But for most of them its not as effective as collocated teams.

What has worked best of me so far is to start off a team by having them collocated for a couple of week to a month. Then created cross-functional self sufficient teams in each distributed location. Once this model seems to work, then try to fully distribute your team with team members spread all the world. This turns out to be a long and painful process. But this is the best I know of today. Check out my presentation on Distributed Agile which I gave at the IV Agile Gathering in Ukraine.

Next year I plan to kick off a few experimental distributed projects to try out different techniques to get Distributed Development work as effectively or may be even better than collocated teams.

    Licensed under
Creative Commons License