Introduction

There has recently been a great deal of attention on agile development methodologies. CRM capabilities in particular are ideal candidates for reaping the benefits of an agile culture because they have so much user and customer interaction, and are generally already deployed. However, the real value is released when organisations think about agility as an overall paradigm shift, rather than just an IT development methodology.  Despite the benefits, many large organisations still struggle with adopting agile principles because of the perceived lack of control and uncertainty associated with it. 

So how do we translate these agile principles[1] into something that our CRM teams can action?  The rest of this paper explains The Customer Experience Company’s point of view on where to start.  Our view is that moving towards an agile environment does not happen overnight.  In the long run, it leads to a change in the culture and the way the organisation thinks, making it more customer centric and more flexible.  Rather than trying to immediately implement everything you read about being agile across all your projects; start instead with three basic techniques on one or two projects, and then grow it.  The three techniques are:

1. Collaborate with an outside-in perspective
2. Be flexible and plan to deal with change
3. End to End Integration – your biggest challenge

Collaborate with an outside-in perspective

The single most important point about being agile is the emphasis on collaboration with the business users of the application, with a customer centric, outside-in perspective.  Before exploring what “collaboration” means, let’s first discuss what it is not.  Many organisations start their CRM development process by performing a requirements gathering process where the business has to say “what they want”.  The process then moves into functional design where the business is asked to sign-off a specification for “what they want”.  The work then moves into a development shop, typically for months, and software is produced that may or may not do what the business really needed.  There are many potential shortcomings to this process.  The business often has difficulty coming up with a complete list of requirements and is understandably reluctant to sign off something that they have not seen before.  This is not “collaboration with the business”.

So what does collaboration mean and what do we need to do specifically?  It means that people from both IT as well as the business work together to iteratively build a CRM capability that will enable us to best service our customer’s needs (we need to think outside-in).  We are unlikely to develop a perfect solution in the first iteration, and we will probably think of ways to improve the solution as we progress.  So, we assume that the software will evolve over time and hence, we plan to iteratively build our CRM capability, gradually improving it after each iteration.

To achieve this, there are some key steps to follow.

1. We no longer need a signed off requirements specification.  Instead, its more important to find a leader who can understand both the business as well as the IT application, and can effectively communicate with both groups (eg a Lead Business Analyst).  Ideally, they should have some previous experience with iterative methods. 
2. Meet with key business representatives and discuss what capabilities need to be supported from a customer perspective.  Look at it from the “outside-in” and ask what a customer would expect from your organisation.  This becomes a guide to your team on what they will build in the first iteration. 
3. Create a plan on what capabilities you will build in the first iteration.  More likely than not, your CRM system is packaged software like Siebel, so it probably already does some of what you need and only minor configuration is needed.
4. Build the code (configure) and test it.  In a packaged environment like Siebel, this should only take a few weeks, assuming you have the infrastructure in place.
5. When the first iteration is ready, arrange a full day workshop to show the application to the business users.  Let them put their hands on the keyboard and “play” with the application in a testing environment.  Be sure to tell them that the application is still work in progress, that it has bugs, and that it is not complete, but that you want their feedback.  Listen carefully to what they say, and discuss (or challenge) it where needed – remember to think about the customer’s “outside-in” perspective at all times.  Write down the suggested changes in a log and get the business to prioritise the log.  Explain to the business that there will be some items of feedback that you can action, and others that you can’t.  The developers should be in the room too, paired off with a business user.  Their job is to help the business use the system (tell them what button to press, what screen to navigate to etc) and listen to the business.  Good facilitation is crucial for these sessions to be successful and productive.
6. You will now have a prioritised log of things to change in the application.  Go back to Step 3 and create a plan on which items you are going to address for the next iteration.  Work on the items that have a high business priority and low effort to change first.  Ignore the low priority and high effort items.  The next iteration should be no more than a few weeks away.
7. Talk to the business when applying the changes.  You probably only have one or two sentences captured in your change log for each item, so your developers will need clarification or more detail.  Keep the collaboration and communication channels open.
8. When the second iteration is done, again put the application in front of the business and get their feedback.  Repeat this process until you have software that you decide (together with the business) that you want to deploy. 

Following the above process (or something similar) will typically lead to some interesting results:

• Business users will see a dramatic improvement in the overall usability of the application because users can “fine tune” the application’s behaviour through their continuous testing and feedback.
• Business users will become the application’s “champions”.  They will feel like they own it, and they will help to champion its acceptance and rollout across the organisation.  They will also have a much better understanding of the organisational and business process impacts that the application will have.
• IT developers will gain a far better understanding of the day to day challenges that the business faces. 
• IT developers will introduce processes and tools that help them cope with the constant change in the application.  For example, they will introduce automated testing tools to assist with regression testing after a change is made; they will start using other Agile Development techniques like code refactoring, pair programming and so forth. 

Be flexible and plan to deal with change

The second most important thing about being agile is that you have to plan to be flexible.  Today, most project managers will develop a detailed project plan that lists out all the tasks that need to be done, the inter-dependencies, the budget, the schedule etc.  As the project proceeds, the manager will track variance against the baseline plan – which is seldom accurate.  If there is a need to change business requirements, it will be managed through a change request process.  It often takes many weeks to push something through a change request process, and that will almost certainly lead to deadlines being missed or the change request being deferred.  This is not ideal.

In an agile environment, change is part of the norm and is baked into the original baseline.  Here are some important things that project managers need to track – and how they translate in an agile world.

• Budget.  This is usually calculated by feeding a variety of factors into an estimating model to determine the effort / cost of a project.  In an agile world, such models are simply not applicable.  If you must have a budget estimate, calculate it by taking the expected size of the team multiplied by the duration of the project.
• Schedule.  A waterfall project has due dates for all tasks, plus key milestones.  An agile project only has one fixed date – the date that you intend to deploy to production.  The teams are generally driven by a short term plan for the next iteration of work.  The dates are fluid and will be expected to change depending on the feedback received. 
• Resources.  Agile methodologies work best with small teams of people that are co-located.  If you have a particularly large or complex project, you might have multiple teams working in parallel on different parts of the application.
• Quality.  This usually gets measured as a function of the number of testing defects raised, where they came from, how long they take to fix and so forth.  In an agile world, the business knows, at any given point in time, what the application looks like and how it behaves.  Hence, functional “defects” become irrelevant.
• Change Requests.  There are no change requests, because there is no requirements baseline that has been “signed off”.  Changes are simply captured as feedback items within the iterations.
• Communication.  Being agile requires orders of magnitude more communication than other methods.  Your plan will be shifting almost every day and in order to keep people abreast of what’s going on, you need to use techniques like daily stand-up meetings. 

Note that planning is just as important, if not more important, in an agile world as it is in a traditional waterfall environment.  A plan tells people what to work on next and when they have to get it done by – so a plan is critical no matter what methodology you are following.  The main difference is that the plan changes frequently so teams find themselves under constant pressure to deliver to the next iteration.  Good planning and good communication therefore become key factors in enabling the team to develop the best possible software in the shortest time. 

End to End Integration – your biggest challenge

Finally, we have to address what is probably going to be your biggest challenge - end to end integration.  By this we mean that while your CRM application might follow agile techniques, it will still need to integrate with the rest of your organisation, which may not follow the same techniques.  For example:

• Integration with external systems (that operate in a waterfall environment)
• Technical testing such as performance testing, operational testing, disaster recovery

Each organisation and each project will have a different set of integration points.  One way of dealing with integration is to view it as just another channel for change to your CRM application.  For example:

• Your CRM application may need an interface to a back end system.  But the other system follows a waterfall methodology and is unable to “iteratively” build and test the interface.  To accommodate this, the CRM team would plan to complete their iterations on that interface prior to the time when they need to “sign off” on an interface design specification.  This may mean modifying your agile plan to pull that particular interface to one of the earlier iterations.
• Your CRM application may need to participate in a variety of technical tests such as Systems Integration Testing, Performance Testing, Operational Readiness Testing, Disaster Recovery Testing etc.  These types of tests are usually unavoidable and necessary.  To accommodate this, you would plan to complete your last functional iteration prior to these technical test phases. 

The key to success is to know what your integration points are and to plan for them accordingly. 

Conclusion

Most organisations want to become more agile and flexible.  But at the same time, most organisations are fearful on embarking on such a change and do not understand the immediate next steps to take.  At The Customer Experience Company, we have successfully run agile projects and our experience suggests that CRM applications (eg Siebel) are prime candidates for moving to an agile methodology because of their high degree of interaction with business users and customers.  We suggest that you start small by implementing a few key practices across one or two projects and then progressively grow.  The key practices are:

1. Collaborate with an outside-in perspective
2. Be flexible and plan to deal with change
3. End to End Integration – your biggest challenge

Finally, remember that being agile is as much a way of thinking as it is a development methodology.  It’s about working together in a collaborative manner, taking an outside-in perspective to find the best solution to service our customer’s needs, and embracing change rather than being fearful of it.