Adopting Agile Methodologies in your Corporation

As a large globally distributed software and services company Sapient has decided to move to a more Agile focussed development methodology. In my interactions at work I have noticed that some managers and senior developers had always practiced some form of agile development without actually adopting the term XP or Scrum or what have you, but still the problem of “rolling-out” if you will, an agile approach within a large organization is not an easy one.

How do you set a date/time for the change in philosophy? Can you send a memo and put up posters all around and say - “We’re now Agile!” or do you have large planning sessions and leadership meetings to adequately word your “Agile Intent”. Well, this is not an easy problem since moving from Waterfall to Agile could be and has proven to be disastrous for many organizations - with productivity (whatever optimum level of productivity that Watefall could allow) and quality both suffering in the transition. This problem is further compounded for services companies since the learning occurs on the dime of the client - unlike product companies that can allocate resources and plan on the transition. Why do I say that? - since services companies have no projects unless they sign on with a client and “beach-projects” are never considered legitimate and hence do not get the backing that they warrant.

I think the difficulty stems from the fact that moving from waterfall like processes to Agile processes is more a philosophical shift - an attitude adjustment if you will which can be very painful on a personal level until you internalize and adopt the agile philosophy for yourself. It is not as easy (being cynical here - pardon me) as switching to the Metric measurment system which took the UK (all bright lads and all) 6 (yes six) years to complete and this was a conversion from one known, studied and fully described observation capturing mechanism to another (no big deal).

When you talk about Agile development you are talking more about interactions with people and how they could be made better by providing them with a process to collaborate effectively without added baggage. This is all very social even in the context of software engineering.

My intuition tells me that starting at ground zero is probably the best thing - ie. start with hiring the right people (Amit wrote something very interesting on hiring and I feel it could make for a good follow on read ) that have already been exposed to agile development and nurture and grow the existing talent within your company that embraces change and within that select few further identify leaders who will be able to technically lead projects. I strongly feel that architects from the old school thought process have become used to not doing any real work and that they should lead by example and own some of the code base. The days of drawing pretty pictures and only working on COTS selection process are over. From a technical perspective I also feel that the first few projects should force smaller iteration lengths - this will provide the necessary feedback loop to understand and fix potential problems before they become too serious. And finally, I think open discussions on the topic will only help in addressing concerns before they become issues.