Pages

jeudi 18 octobre 2012

Lessons from Agile Development with an Off-shore Team


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.

lundi 15 octobre 2012

HOWTO: Sonoma Partners Universal Search




Sonoma Partners a récemment édité un add-on pour Microsoft Dynamics CRM 2011 permettant de chercher une chaîne de caractères dans les enregistrements de plusieurs entités simultanément. 

1. Installer le moteur de recherche
1.1. Télécharger la solution.
Pour installer le moteur de recherche, il faut dans un premier temps télécharger la solution qui contient l’add-on.

Pour cela, aller sur le site de Sonoma Partners en cliquant sur le sur le lien suivant.

Cliquer sur « download and try Universal Search from our website ». 





Remplir le formulaire et cliquer sur « Submit Request ». 


Un Email avec un lien va être envoyé à l’adresse email indiquée. 

Cliquer sur le lien pour télécharger la solution « Sonoma Partners.UniversalSearch-Managed » (fichier zip de 192 ko). 

1.2. Importer la solution
Ensuite, il faut importer la solution téléchargée dans le CRM. 

Aller dans Paramètres > Solutions et cliquer sur « Importer ». 






Importer la solution téléchargée. 

Une fois que l’importation a été faite, on peut utiliser le moteur de recherche en cliquant sur le bouton « Universal Search » dans le ruban du menu général. 


Dans la colonne « record summary » se trouve l’ensemble des entités sur lesquelles la recherche peut porter. On peut choisir d’effectuer une recherche sur toutes les entités (All) ou sur certaines d’entre elles seulement, en les cochant. 

Le moteur de recherche propose par défaut les entités suivantes : Comptes - Contacts - Incidents - Opportunités - Prospects.

Il est toutefois possible de définir les entités disponibles à la recherche en utilisant le configurateur. 

2. Configurer le moteur de recherche
Pour configurer le moteur de recherche, aller dans Paramètres > Solutions.






Ouvrir la solution « UniversalSearch ». 



Dans la colonne de gauche, intitulée « Available Entities », se trouve la liste des entités disponibles pour la recherche. Dans la colonne de droite se trouvent les entités sélectionnées. 
Il est possible de supprimer et d’ajouter des entités pour la recherche à l’aide des deux boutons situés entre les colonnes. 

Dans ce cas, je n’ai pas besoin des entités sélectionnées par défaut. Je les supprime donc toutes en faisant une multisélection et en cliquant sur le deuxième bouton. 






Inversement, je sélectionne dans la colonne de gauche les entités qui m’intéressent et les rends disponibles à la recherche en cliquant sur le premier bouton. 






Une fois que ma sélection est faite, je l’enregistre en cliquant sur « Save ». A tout moment, je pourrai restaurer les entités sélectionnées par défaut en cliquant sur « Restore Defaults ». 

Je peux également modifier le nombre de colonnes apparaissant dans le résultat en modifiant la valeur dans le champ « Columns to display ». Par défaut, la valeur est 4, ce qui signifie que les quatre premières colonnes de la vue « Recherche » seront affichées dans le résultat. 

Le champ suivant, « Max. records returned », sert à définir le nombre maximum de résultats à afficher par entité. 

3. Lancer une recherche
Après avoir configuré le moteur de recherche, je l’ouvre à nouveau. 



Les entités disponibles à la recherche sont bien celles que j’ai choisies. 
Pour rechercher un enregistrement, je saisis une chaîne de caractères dans le champ de recherche.

Je vais, par exemple, effectuer une recherche sur tous les enregistrements contenant la chaîne « Kery James » en tapant « *kery james ».






Le moteur de recherche m’indique le nombre d’enregistrements trouvés par entités. Dans ce cas, j’obtiens un artiste, 6 disques et plus de 50 titres. 
Je peux ouvrir l’enregistrement qui m’intéresse en cliquant sur le lien. 

Remarque : les champs disponibles à la recherche sont les champs définis comme critères de recherche. Lorsqu’on modifie les critères de recherche d’une entité, il faut supprimer puis rajouter l’entité en question dans la solution « UniversalSearch » pour que le moteur de recherche prenne en compte cette modification. 





It is now possible, in Microsoft Dynamics CRM 2011, to look for a character string in various entities simultaneously thanks to Sonoma Partner’s new add-on. 


1. Installing the search engine 

1.1. Downloading the solution 

To install the search engine in the CRM, you should first download the solution which contains the add-on. 



Go on Sonoma Partners’ website by clicking on the following link.








Click on « download and try Universal Search from our website ».



Fill in the form and click on « Submit Request ». 

You will receive an Email with a link. Click on the link to download the « Sonoma Partners.UniversalSearch-Managed » solution (zip file, 192 ko). 


1.2. Import the solution 

Once you have downloaded the solution, you need to import it in the CRM. 

Go to Settings > Solutions and click on « Import ». 

Import the downloaded solution. 

You can now use the search engine by clicking on the « Universal Search » button on the main menu’s ribbon. 

In the « record summary » column, you can find the entities available for search. You can either search in all entities or only in the checked entities. 
The following entities are available by default : Accounts - Contacts - Cases - Opportunities - Leads. 
You can nevertheless choose which entities are available by configuring the search engine. 

2. Configuring the search engine 
Go to Settings > Solutions. 





Open the « UniversalSearch » solution. 

You can see two columns, one with the available entities, one with the selected entities. 
You can add and withdraw selected entities with the two button between the columns. 

Note: the search engine can only be configured in the CRM’s native language. This is why the entities appear in French on this example. 

In this case, I don’t need the default entities. To withdraw these entities, I select them and click on the second button. 




Then I choose the entities I need in the « Available Entities column » and add them by clicking on the first button. 




Once I have chosen my entities, I can click on « Save ». I always have the possibility to restore the default entities by clicking on “Restore Defaults”. 

I can also change the number of columns displayed in the result by modifying the value of the “Columns to display” field. The default value is 4, which means the first four columns of the “Research” view will be displayed. 

In the same way, I can change the maximum number of records returned by entity in the following field “Max. records returned”.

3. Launching a search 
After configurating the search engine, open it. 

The available entities are the entities I chose while configuring the search engine. 
To look for a record, I enter a character string in the search field. 

For instance, I click “kery james” to look for all the records with the “Kery James” string. 

The search engine tells me how many records were found in each entity. In this case, I found one artist, 6 discs and more than 50 tracks. 

I can open the record I want by clicking on the link. 

Note: the available fields for search in the search engine are the fields you made available for search in the CRM. Each time you change the available fields for search in an entity, you need to withdraw this entity and add it again in the “UniversalSearch” solution to make the fields available for search in the search engine. 


jeudi 11 octobre 2012

13 CRM Best Practices for 2013



With less than 12 weeks to Christmas, now might be a good time to start planning for 2013. Too early? With these 13 CRM best practices there is no time like the present. Whilst individually each of these will help get your CRM system ready for the New Year, the more you can do, the better the results.

The pundits are in agreement - 2013 will continue the austerity we have seen in 2012. Making sure that your CRM system is delivering in the essential tasks of Acquiring, Retaining and Developing customers need not cost the earth. With careful planning, getting the best out of your system is a team effort that will cement CRM as “the way we do things”.

1. Perfect data is a myth.
Or perfect data is an expensive illusion. Either way, focus on the 20% of your data that yields 80% of your revenue. Don’t ignore the rest – but don’t throw money at trying to achieve perfection in every piece of data.

2. If it is important enough to record, it’s important enough to back-up.
You probably haven’t thought about your back-ups for a while. Sure those nice people in IT are backing everything up – but how long would it take to restore? How up to date is the last backup? A quick email may just save you a time and money in the event of a server crash.

3. Don't assume that it's safe in the cloud.
Feeling smug because your data is in the cloud? So, there should be no problem with checking how easy it is to get a backup, just in case you need to move systems in 2013. Some of the leaders in cloud-based CRM are going to disappear in 2013 – you don’t want to be caught out.

4. Set your users free.
The CRM market has been screaming mobile for the last 5 years. 2013 is the year it becomes reality. Windows RT devices will be appearing near you soon. Does your current CRM platform deliver?

5. Manage your access points. 
With more connected users comes the need to manage more access points. Bring your own device (BYOD) and home working necessitates a review of your security settings. How easy would it be for someone to steal your data?

6. Share the burden of data cleaning.
Not just internally by getting everyone to keep their slice of the data up to date. 2013 is the year that social and other data cleaning services will enter the mainstream. Often thought of as only relevant to larger organisations, plunging prices and easy availability will help to automate data cleaning for everyone.

7. Invite your customers in – and ask them to help with the clean-up.
Sounds bizarre? Customer portals are set to take off in 2013. Make sure that there is a compelling reason for your customers to come to your site and update their details and preferences. No compelling reason? What about linking access to content in LinkedIn, Facebook, or other social media? These are all great sources of extra data.

8. Review how you're using your CRM system.
Your relationships are multi-faceted – use the right part of your CRM system to reduce the effort in recording and storing data. Try implementing those bits of the software you never bothered with. No need for Customer Services? Try thinking of it as post-sale customer care. Don’t track opportunities? Think of it as a way of developing a playbook filled with tips that work!

9. Direct mail is making a comeback.
Perhaps in the recent past it was sufficient to just hold email and phone contact details – but as direct mail proves its value, get ready to hold postal address data. Now would be a great time to look at integrating access to the Post Office Address File (PAF).

10. Delete Data!
Yes, you read that right. In your CRM system there is data that needs to be deleted. The Data Protection Act (DPA) sets out guidelines on data retention. Use these to develop a data strategy and implement it. Do it quickly before your data embarrasses you.

11. Save money.
When was the last time you audited the usage of your system? If 20% of the users do 80% of the work, do you really need all of those licences? Do you really need people who can’t or don’t use CRM? If that sounds harsh, just think about the long term value of a customer you don’t know. Impossible to calculate.

12. Spend money. 
The flip side to point 11 is to spend money. Invest now for the future in things that can deliver a return. Invest in people, education and tools to make CRM work for your business. Invest in expertise to accelerate those returns.

13. Back your instincts with solid proof.
As a Sales or Marketing professional, believe in superstition. Nothing about the number 13 – or the effect of black cats. If your gut instinct tells you something then go straight to your CRM system for the hard proof.

There they are - 13 things that you can do in 2013 to make your CRM system even better. Of course, you could always get ahead of the crowd and start now!

Did I miss anything? What are your plans for 2013?