Slow xRM Pinterest

We have collected a first set of nice infographics into 3 main Pinterest boards :

• CRM & Social CRM
• Agile Project Management
• Social Media

Weekly News #43: Agile & CRM Project Management

Best read articles about Agile & CRM Project Management this week:
- Lessons from Agile Development with an Off-shore Team by Andrew Schultz (17/10/2012)
- Can SCRUM be applied to CRM? by Agile Scout (26/05/2011)
- Using an Agile approach to CRM by Customer Dynamics (09/01/2012)
- How to use Agile methods to deploy a CRM system by Computerworld UK (19/01/2010)
- Better Together - Agile with Dynamics CRM by The Blog Train (09/12/2011)

Lessons from Agile Development with an Off-shore Team

Lessons from Agile Development with an Off-shore Team by Andrew Schultz (17/10/12)

My main role at my company is to deliver subject-matter expertise on Dynamics CRM (which includes solution design for companies building products on top of CRM) and to manage the delivery of the resulting product by our development team in Kiev, Ukraine. I enjoy both of these roles, but the actual project management piece, which is a part of the “managing delivery” role, I could honestly do without.

So when I saw how our team worked as I started my employment here, I was concerned. As might be expected from an off-shored professional services organization, the approach to work was a bit scattered at first. Projects would come in, the least-busy people were assigned to those projects, we tried to maximize the time each person spent working on billable work, etc. This meant that the team never had time to gel (as there was no consistency in the makeup of the teams from project to project). It also meant that each person was typically working on several projects at once. Projects were difficult to close out, and I don’t think it was a great environment for developers who want a more planned approach to their careers, the competencies they build, and the type of work they do.

So I was really happy when we had 2 projects start that were both multi-month development projects. The larger one has been going for 8.5 months and has 6 developers/testers working on it. Most of that team has been very consistent throughout the project. So at the beginning, I decided that this would be the perfect opportunity to introduce agile to the team. I had several particular goals:

1. Avoid gantt charts [shudder]. I hate them. And to try to manage an 8-month project that started with a 230-page technical spec with waterfall and a gantt chart and a critical path … I’d die first. The technical spec was written by a 3rd-party architect, so this created a sticky business triangle, but outside of that, we tried to use this architect as our on-site customer.
2. Overcome the wall I felt between myself and the devs. It seemed like they were afraid to speak their minds to me, to contribute their ideas to our projects, to tell me when they had a better idea than I did … I assumed this was cultural. I know they didn’t agree with me all the time, because previously, from time to time, they had followed my way of doing things until they kind of exploded with frustration at doing it my way when they had a better idea. I wanted a more open dev environment where we could work together as equal contributors, even if I am technically above them in the chain of reporting.
3. Instill agile skills in the team. This was for their own benefit as much as it was for mine. I consider agile experience a plus for any developer’s resume. This is especially true if he has truly experienced agile (not just adopted a few mechanisms like sprints and scrums).

So … how did it go? The culture gradually changed. I was gratified to see the technical lead on our team start to take over my role as the person who led the planning meetings, started writing the stories, etc. His confidence in this role grew as the project went on. We faced some challenges, such as going way over budget, but as I investigated the causes (and asked the direct question multiple times about whether this was a result of using the unfamiliar agile approach), we honestly determined that the project had just been poorly estimated at the beginning. Estimated at the beginning, you might ask? Yes … we couldn’t do everything the right way according to agile. I’ll discuss this below.

What Went Well

1. We finally got the art of agile estimation down. We started by looking directly at the spec and trying to group the sections from there into our iterations. This worked marginally well until the sections got too big to do in one iteration. We started re-writing sections from the spec as user stories that the developers could understand more readily and give the gut-feeling estimates we needed to generate our story-points. As the weeks went on, the estimates began to coalesce. At the beginning, there would generally be one cluster of estimates with 2-4 days difference between the highest and the lowest, and then one outlier from the “pessimistic guy” that was usually 5 days higher than everyone else. We averaged the estimates together to get our story points. While we were fairly consistent in the number of story points we accomplished from iteration to iteration, it could have been better. At the end, the estimates were much closer together, usually all within 1 to 1.5 days of each other.
2. Planning improved. The major challenge with this project was the complexity of the technical spec. Did I say it was 230 pages long? And completely unreadable by normal humans. After starting with 2-week iterations and really struggling to consistently deliver the planned functionality due to problems that arose mid-iteration, we pared the iterations down to 1-week. We had our demo and planning every Tuesday, so the developers really had only 4 development days plus a few hours in an iteration. This dramatically improved our consistency. Keeping the planning cycles short left much less room for us to get bogged down in complexity we didn’t understand when we planned.
3. Code quality was great. We re-factored constantly, we tested the functionality for each iteration diligently so we could release it at the end of the iteration (even though the customer never took the product out of the demo into production). I honestly think the code quality in this project was the best I’ve seen from our team.
4. Cooperation was awesome. Since this project had most of our team working on it, I feel like it’s actually transformed our team. Our leader (who was appointed the technical development lead shortly after the project started) has been able to develop a great collaborative atmosphere with the other team members, and that’s not something that would have happened had they all just been working on 3 projects at once like they were before. They spoke to each other, walked to each-others workstations, and generally had a much higher level of interaction than on other projects.

What didn’t go well

There’s only so much you can do in your first attempt to implement agile. The core of agile is the cooperation between business people and developers, and this is where we fell short, unfortunately. So, while I’m hesitant to say we were fully practicing agile with these shortcomings, I think we made great strides, and we’ll learn from these things moving forward.

1. Collaborative workspace – while our developers have this among themselves, there was simply no way for us to put our “onsite customer” (the 3rd-party architect who wrote the spec) in the same room as the developers in Kiev for more than 3 days at the beginning of the project. At first, he was present via Skype at our daily standup meetings. Then, he was only present at our demos. He was always available for questions, and was very helpful, but it wasn’t the same as having him in the room. When could you ever have the customer in the room all the time for a professional services project, especially an off-shored one? I would say never. Unfortunately, this is a challenge that may not have a perfect solution. The best thing to do is to try to keep the customer as involved as possible, especially at the points where input is needed and decisions are made. Demand his availability, and, if possible, insist that he not require questions to be scheduled.
2. Full implementation of my favorite concepts- there were some XP concepts that I just couldn’t get the team to try – including test-driven development and pair programming. I’ve spoken to developers who have successfully used these practices and will attest to their effectiveness, but my developers in Kiev were not ready for them. Well, we change gradually, right? Maybe sometime in the near future. But it’s important to have the right financial configuration on a project to introduce radically different development practices, and this probably wasn’t it.
3. Welcoming change – this is another pillar of agile, and unfortunately, we fell short here. Why? We were working on a fixed-fee project. At first this was good for our adoption of agile, because instead of being accountable for every hour we spent, we could focus more on the result. However, as it became apparent the estimates we had used to price the project were way off, the financial burdens of the project required us (me, mostly) to start really challenging any input our onsite customer gave us that changed the scope of the project. Enter the business triangle I mentioned earlier. We had to document any changes as change requests to the paying customer, who then had to go back to the onsite customer (the third-party architect), who then came back to us, and the politics would commence.

The third item here is especially telling. One of the biggest challenges I see in a professional services team doing agile is the project’s financial arrangement. A fixed-fee project seemed like a good arrangement at first, and it probably would have been somewhat OK had we done a better job up front estimating. But the best arrangement would be for the customer to understand agile and the value it can create in his own go to market strategy. He should understand the advantage of not spending his full development budget before his product ever lands at an end-customer. There is a huge benefit financially and strategically in understanding the core functionality an end-customer needs in order to give your customer money (minimum releasable functionality). If your customer understands this principle, he can pay you to develop 10% of his product’s planned functionality and then have paying end-customers funding all or part of the other 90%. The alternative is paying for all 100% himself, and then realizing that 80% of it is irrelevant, and that he’s missing another 60% of things his end-customers want (I’m making all of these numbers up, but you get the point).

If everything were perfect, I would see a fixed-seat project, where the customer simply pays for x number of full-time developers and testers, and then commits the resources from his own company to work with that dev team daily. There’s no scope, no milestones, and no fixed fee. The customer knows what he’s going to pay for development each week or month, but he doesn’t know what the product is going to look like. Most people will be uncomfortable with this. However, if they’re smart, they’ll gladly accept that uncertainty for the increased agility that will allow them to get early feedback from customers and develop the solution that makes money the fastest.

Dynamics CRM 2011 - The Agile Approach

Dynamics CRM 2011 - The Agile Approach by Jaime Smith at Magnestism (10/06/12)

There is plenty of information all over the net about AGILE, its origins, methodology, tool etc, so as I have said previously I am looking at it from within CRM and SureStep practice. Within SureStep it is somewhat of a hybrid and definitely veers away from a strict Agile approach.

What it maintains from Agile

1. Solution Backlog

A list of the requirements that have been defined during the analysis phase. The compilation of this backlog signifies the end of the Agile Preparation Phase.

2. Sprint formation

Within the Agile Execution Phase, sprints will be defined with durations of between 5 days and 30 days. A sprint cycle should never longer than a month.

3. Sprint Backlog

This defines the development activities for each sprint cycle (pulled from the Solution Backlog) – these are reviewed on a daily basis (We hold SCRUM every morning) and tasks are shared out amongst the project team.

It is essential to note that included within each sprint and on the sprint backlog are all project tasks/phases including, analysis, planning, design, development and testing. This differs from the waterfall approaches where each phase is completed before the commencement of the next one.

After the sprint is finished there is collaboration between the customer and the supplier – the development is reviewed and anything that is rejected or requires additional work is added to the Solution Backlog to be scheduled as part of a later sprint.

Where it deviates from Agile

Agile SureStep approach adopts the two final phases from its waterfall siblings – Deployment and Operation. It is here that User Acceptance testing occurs.

Best fit for this project type

- Anyone who wants to use CRM as a platform and requires integration to other third party solutions

- If you are not entirely sure of your needs this provides greater flexibility throughout the project lifecycle. Warning: This approach can be more costly as it is hard to define at the outset what the project costs are going to be, however it can result in much greater accuracy within your end product.

- Requires relative fit to the OOTB CRM (50 %– 75%)

- Those who have data to migrate from existing systems

- Single site implementation

- Can incorporate organisation change management activities if required

This approach can be highly disciplined and assist in keeping your project within scope and creates a great sense of manageability but it does come with the recommendation that those in significant project roles have significant experience with IT implementations (both the customer and the supplier) and that super users form part of the project team.

Can SCRUM be applied to CRM?

Can SCRUM be applied to CRM? by Tommy Ball (27/05/11)

I find it difficult to work in an Agile way with the typical teams involved in a CRM deployment. However… I have developed a highly effective way of making it work.

One challenge is wasting time treating each little sequential task (e.g. in Salesforce setting up validation rules, roles, field level security) as a separate story, requiring more time documenting things in a tool like Pivotal Tracker, then actually performing the tasks themselves. Because there are many sequential tasks with CRM. So many that documenting as individual stories takes an excessive amount of time, thus hindering rather than helping progress. What happens is when you apply true Agile, I’m finding, is that organizations still get hung up in too much process and documentation especially with new Agile teams, which almost all Salesforce CRM teams are. And what does the Manifesto say about a little concept about less documenting, more deliverables, less process, more collaboration, don’t get hung up on tools? Right? It’s important to stick to the principles we all live by, but with CRM, allow for flexibility in order to keep things moving effectively.

I’ve been addressing this on-going issue of applying Agile to CRM for years now. Running a Salesforce project is drastically different from a Rails project. And both need its own approach. Alistair Cockburn and people in his realm have many Agile offshoot methodologies specific to software dev, but no one has tackled using Agile for CRM. Ironically, Salesforce themselves use Agile and have a very successful internal adoption model.

Basically, all the sequential tasks (aka theme or mega-story) that need to occur in order to establish a key piece of functionality, often a with group of sequential tasks that other parts are codependent on, it’s important that all the tasks for that major function (e.g. establishing field level security for all CRM users, which involves several tasks) be grouped together in order to complete the function or “theme” if you will.

So, in this case combining sequential tasks into mega-stories, or themes, and still assigning points and tracking velocity, but group tasks within a large process or function (theme), all together, with story points assigned to the entire theme, incorporated into a sprint (analyze, configure and setup, test, release, demo), still have daily standtoups like usually works.

The key for me is the ability to be flexible, sticking to a 1 week sprint, mainly because Salesforce can be setup that quickly if the team approaches from a theme level, often working in parallel with other teams (aka paired teams or XT-extreme teams). However the database migration team may take a different approach although working on the sale project together.

Often times 2 teams work in parallel, one focusing on process analysis, defining business rules, workflow, building use cases, setting up 3rd party integration, and often, even developing custom Salesforce aps. The other team focuses on the data – cleansing, scrubbing, duping, field source mapping, etc.). It’s good to align each group so team 1 working on business logic, can test each function (aka theme) against the data being brought over. I call this paired teams, or XT, similar to pair programming or XP, but on a larger scale. A situation involving data migration with bad data may lend itself a waterfall, depending on the integrity of the data you are migrating.

“CRMSCRUM”

As long as you group stories that must follow a sequence into themes, treat as mega-stories, and finish each after every step of the sequence has been completed, then test, and release, and demo every 2 weeks, this version of Agile I’ve developed, called CRMSCRUM, is highly effective, sometimes to the point where you sometimes can move with unlimited velocity. It just takes the right combination of team commitment, solid well-skilled Salesforce SME’s serving multiple roles, and a flexible mind set, but not to the point where you break key Agile principles, This technique I call CRMSCRUM used to deploy systems such as Salesforce with has proven to deliver with exceptional speed, efficiency, and perfect alignment with stakeholder vision.

Agile CRM Implementation

Agile CRM Implementation by Luneos (12/11/10)

Because our last article about cheap and rapid CRM implementation raised several questions from our readers (saving both time and money is grateful idea) we decided to come back to this topic again.

Instead of purchasing new information system for the whole company, paying license fees for all employees and spending months with demanding implementation it is often much more beneficial to start with agile CRM implementation in much smaller scale.

Agile CRM implementation principles

At first think about three most serious issues in your company that new CRM system can avoid (e.g. missing sales opportunity overview, not unified pricing conditions or lack of reporting).

Afterwards perform a brief CRM analysis focused only on departments, where these three issues happen and try to find out, how to remove them fast and efficient.

As soon as this analysis is finished, you can start with deployment of new CRM system. Don’t implement the whole set of features, but only those that will help your company in solving its three major issues.

Also avoid continuous changes in specification and adding new requirements, because they would only slow you down and you’ll have enough time and more experience to cope with them later.

Once the CRM is live for at least two weeks, you have tested and adjust its settings it’s time for its extension. Write down your next three business problems, make small analysis and start with the deployment again.

Benefits of Agile CRM deployment

Unlike the usual CRM implementation that lasts months or even years, you’ll get the first results just in few weeks after signing the contract. Breaking the project down into short and fast steps also simplifies end user training and reduces overall costs. Instead of paying for licenses for all users immediately after the contract is signed, you can gradually re-buy them in accordance with speed of your implementation.

Mistakes to avoid

The most common mistake during agile CRM implementation is lack of communication and cooperation with the vendor. That’s why you should develop an implementation framework right after signing the contract and make your provider familiar with your long-term CRM plans and strategy. Such approach allows him to better estimate the duration of whole project and help you prepare next steps.

Your company doesn’t need a complex information system with thousands of exceptions, difficult maintenance and limited upgrade options. By choosing an agile approach you simply avoid such scenario and can benefit from the CRM since the very beginning.

As one of our clients told us: Our company can’t wait two years for a luxurious Rolls Royce. We need a compact SUV right now. And what about you?

Using an Agile approach to CRM

Using an Agile approach to CRM by Customer Dynamics (10/01/12)

Our approach to managing and running CRM implementation for multiple clients at the same time involve some very basic “Agile” principles of doing first things first, keeping iterations small, and running sprints.  An overview of CRM philosophy can be found on our CRM Success page.

Our approach with our support and maintenance customers uses a simple backlog type approach as shown below:

This diagram shows the overall flow of work items (user stories and tasks) from initial inception, onto the Backlog, then onto the appropriate Sprint.

The Backlog is a queue of business functionality waiting for refinement, budget, scheduling and approval. A Backlog Item is a piece of business functionality that is well defined and can be budgeted and scheduled into an upcoming Sprint. Each Sprint is a 4 week period of time where approved Backlog items worked on and completed. A simple Backlog item example would be - “Sales user needs the Opportunity screen to display a weighted revenue amount calculated from the estimated revenue * sales stage probability, and allow that user to query the results in an advanced find.”

The Executive Sponsor, System Architect, System Consultant, and Business Process Expert(s) submit items to the backlog for consideration. The System Architect periodically reviews the backlog and ensures that each Backlog item is well documented and conforms to the overall system design.

The Executive Sponsor and Project Manager (and other team members as needed) have a monthly Sprint Planning session to review Backlog items and schedule them into the upcoming Sprints. The Sprint Planning session should be completed 2 weeks prior to the end of the current Sprint.

This approach helps capture new potential CRM items (business logic, custom workflow, plugins, ect) and allows the CRM team to prioritize and manage these items in typical Agile sprints.  This “Agile CRM” approach keeps your users engaged, provides on-going value and ROI from your system, and keeps the Executive Sponsors involved.

How to use Agile methods to deploy a CRM system

How to use Agile methods to deploy a CRM system by David Taber (20/01/10)

Despite the user community's urgent calls for this or that functionality, customer relationship management (CRM) is still enterprise software that needs to be done with an architecture and a plan.

Deployments of unstable new functionality (or pushing existing functionality to unprepared users) can diminish the credibility of the CRM system. This can mean serious backsliding of user adoption, unwinding the virtuous cycle that is at the core of CRM success.

How to manage this issue? You won't be surprised that I advocate incremental deployments and Agile project methodologies, as they are the fastest (and cheapest) way to get functionality safely deployed. That said, iterative delivery is necessary but not sufficient. To establish sensible CRM priorities, you need to add the following principles:

Data First, Functionality Second

There's no point in building (or even switching on) new functionality if the underlying data is incomplete, dirty, or riddled with duplicates. While nobody can afford perfectionism, getting relevant system tables cleaned up is a precursor to progress. In nearly every table, the error rate needs to be below five percent, and even one percent for critical fields and pointers. Pretty much the only area where you can tolerate as much as a 20 percent error rate is in leads, as its speed of "information rot" makes higher standards uneconomical.

Accounts and Contacts are the Most Important "Static" Data

In most CRM data structures, the accounts table is the top of an information pyramid, with a dozen or more child tables pointing to it. If your customers are large multinational corporations, the account records themselves may be part of a hierarchy. So making sure that your account records are right (and agreeing with the data in other systems) is a key milestone. Fortunately, the account records themselves shouldn't change all that often.

Relating to the accounts are the contact and contact role records, which need to be accurate and free of duplicates to make sure that calls, emails, and action items are properly tracked. Unfortunately, in 80 percent of the CRM databases we see, the contact role record (it's just a pointer, really) is empty, rendering almost any marketing effectiveness or serious pipeline analysis impossible. As this field can only be filled in by humans (either sales or telesales), the only solutions are incentives or other behaviour modification techniques.

Opportunities and Cases are the Most Critical "Transactional" Data

All too often, sales reps manage their boss by managing information. Ok, hiding it. Real deals are not in the system, but fake ones are. This means executive management cannot see what's going on with the pipeline until it's too late to fix it. Watch for symptoms like "submarine deals" that pop up unpredictably during the quarter close, or pie-in-the-sky pipeline that shrivels up all too predictably as the quarter progresses.

While it's easy to come down hard on these practices, it's important not to push behavior modification too fast. The sales reps will engage in passive-aggressive resistance, and may end up gaming the system in an even more misleading way. Expect progress on this front to take six months or more, and measure success by gradual improvements in forecasting accuracy.

On the customer service side of the house, cases (aka incidents or service calls) are the most pivotal data. The problem with cases is not that they aren't in the system - the issue is incompleteness, as they don't reflect reality.

Every CSR or service tech needs to be on the system all day, updating the case records with status changes they might previously have kept in Excel or on paper. Every "truck roll" or customer call needs to be recorded as a task so you can see the sequence and the real accumulated time required to resolve issues.

Integration is the Hard Nut, but Enables the Most Value

The more serious your CRM system, the more other systems it will need to integrate with. When a sales or service rep can see the big picture (that may be stored in a half-dozen outside systems) of the customer situation, they can get the customer happy and paying sooner. When executives get closer to a 360° view, they make better business decisions.

But every point of integration is an invitation to data quality and duplication issues. While off-the-shelf, point-to-point adaptors are widely available for CRM systems, you'll almost certainly want to use a real integration server to handle transformation workflows, network timeouts, two-phase commits, and compensating transactions to unravel error conditions. Beware: integrations tend to be highly susceptible to subtle new bugs whenever any of the systems does a patch or upgrade. Watch out particularly for duplicate record creation or foreign-character set incompatibilities.

Until Reports are Clean, Your Data Isn't

CRM users, particularly executives, tend to ask for reports and dashboards first. Unfortunately, these are highly visible ways to expose every one of your data quality problems. Some of these will be digital noise -- misspellings, transposed dates, bad pointers -- that can be quickly found and corrected using pivot tables and other digests. Some of the problems will be more insidious, caused by business processes that cause "semantic smear" or by integration problems that can take weeks to troubleshoot and correct.

Our advice here is to keep users away from reports until you're really sure about data quality. The easier the CRM system's report wizards are, the bigger an issue this is. Early on, reports should be produced only by an analyst who really knows the data model and the things to filter out.

Users Must Believe the CRM System is For Them

Finally, the features you invest in should be the ones that help the users do their job better. Although they know management will be using the system to measure things, they must not believe that the CRM system is principally a spying machine for micro-managers. So spend money on things that save users a few mouse-clicks on every transaction, or features that will make their job just a little bit easier all day long.

We even encourage eye-candy features that don't actually add a lot of value, but make the system a little bit more fun for the users or the customer.

Better Together - Agile with Dynamics CRM

Better Together - Agile with Dynamics CRM by Shikhar (10/12/11)

I had the good fortune to attend a presentation on Friday by Derek Johnson (IT leader at Nalco/Ecolab) who is responsible for leading the CRM initiatives at Nalco. The forum was a CRM user group – so a focused community of CRM users, partners and third-party solution providers to foster community sharing.

The presentation was well done and impressively laid out. It provided a historical perspective of the business, the challenges facing the business and finally, how they were using CRM at Nalco. The presentation, in my viewpoint, was not about technology. It was a story about sales transformation being pursued by business with the help of agile processes (like SCRUM) and tools (like Dynamics CRM). At a human level, it was also a story of organizational change management by creating highly functional, multi-disciplined and empowered teams to achieve the business goals.

Nalco is not alone in discovering the level of change that “agile approach” invariably brings forward to IT delivery. IT and business has long been conditioned to work in the world of “scope management” and “they & us”. Agile demands a 180 degree turn to this attitude. You are part of a team where by design “all” are co-located to the extent possible. The business uncertainty and change is constant.The scope creep is expected and even, welcomed. Paraphrasing the speaker, “Agile is not about knowing the entire route or even the final destination”. As long as there is a general sense of direction and the next milestone defined, the team can “sprint” along.

The shift to agile complements the growth of agile platforms like Dynamics CRM. In the world of custom applications, it was important to know all the fields and UI designs well in advance as each extra field could impact the budget and yes, the scope. The declarative programming model of Dynamics CRM makes it much easier to keep aligned with the constant changes typically demanded by agile processes.

Agile is not something that will work in all CRM implementations. As must have ingredients, you need: executive support, deep involvement from business, motivated teams & organizational willingness to embrace change in order to be successful. I am glad the recipe worked for Nalco.