One of the core elements of our offering is our strong experience and expertise that the Professional Services team brings to customers.  The Demand Media Professional Services team is engaged during the integration of Pluck into our customers’ websites, and we have seen a diverse set of approaches utilized by customers in these projects.  With over five years and 500+ websites of deployments, we have honed a cross-methodology practice that enables customers of all stripes to be successful in the shortest amount of time.  We call this our Pluck Delivery Framework.

In the past few years, more and more customers have asked how our approach meshes with the Agile Software Development methodology.  Our approach maps very well to the Agile methodology, and the following is a quick guide to how that mapping works.

There is one overriding assumption about the project, and that is that the (Agile) Theme of integrated community has been approved and funded.  Hopefully, there are some User Stories that have already been approved as part of this.  These stories should be at the level of, “Guest writes a review on a product”, “Guest shares photo contribution to Social Networking site(s)”, and “Moderator reviews and approves/rejects consumer-generated content.”  These are high-level stories that were part of the criteria for your organization’s selection of Pluck.

With a new set of tools for both the business stakeholder (“Product Manager” in Agile parlance) and for the technology team, it is critical to NOT overlook the need for a basic yet comprehensive knowledge of the features and technology of the Pluck solution.  This need is addressed through a process of discovery and training.  From an Agile prospective, this phase can be thought of as a Spike (an Agile term for a time boxed periods of research and development used to research a concept and/or create a simple prototype”).  This Spike can be summarized as:

• Project Executive Kick-off – project goals and objectives alignment; plan for resources to be available to meet the goals.  From an Agile perspective, this session aligns the Demand Media engagement team with your Product Manager and validates the Agile Theme (or Epic) for integrated community.  It also validates that your team(s) has the right set of skills, and helps reinforce the number of Sprints that are being planned.
• Product Functional Training – a 3-4 hour web conference deep-dive into the features and capabilities of the Pluck platform for your entire project team (community managers, marketing, developers, designers, business stakeholders).  From an Agile prospective, this meeting should bring together not just the implementation team, but also the business stakeholders that provide User Story input to the Product Manager and will be ultimate beneficiaries of the results of the project.
• Learning & Planning – a 1-2 day set of meetings
  • Discovery and Knowledge Sharing – a 3-4 hour meeting to bring your implementation team up to speed on the Agile Theme and to help solidify User Stories;  Demand Media’s engagement team learns more about customer, and you learn more about the Pluck product.
  • User Interface/Experience Planning – 3-4 hour planning session, wireframe review, etc, to plan out where best to leverage the community elements; sharing of best practices.
  • Technical Overview and Training – 3-8 hours of technical, hands-on training on how to integrate Pluck.  Our goal is to exit this with some HTML/JavaScript pages, built by your implementation team, that are a Proof of Concept for integration.
  • Project Planning Session – 1-2 hours to go through tasks and dependencies to insure your team has all of the information necessary to put together a solid project plan/timeline.  From an Agile prospective, this should be the creation/review of User Stories, and the placing of those User Stories into Sprints.

Once the training is complete, it is time to get implementing.  In Agile, this would be when most of the Sprints happen.  If you are implementing most (if not all) of one of our blueprints, I would recommend 3 or 4 Sprints of 3 weeks each.  The User Stories might be organized into the following Sprints:

Sprint 1:  Authentication integration; technical integration for stories around Persona, Reviews, Comments, Forums, Reactions; data migration POC.
Sprint 2:  Discovery, Community page, Blogs, etc…; styling of first sprint applications;  data migration trials.
Sprint 3:  Lock in on data migration tools and process; finalize styling and integration with business owners; policies and rules setup (moderation, rewards, etc…).

Remember that User Acceptance Testing (UAT) is part of each Sprint!  That means that review of the product of the Sprint is not just for the implementation team, but also the business stakeholders and the ultimate end users.  For most new customers I do not recommend deploying Pluck features to production at the end of a single Sprint.  The challenge here is the “independence” of each of the User Stories and how the functionality builds on itself.  (For example, Discovery is an important component of Pluck’s Community Value Framework, and effective Discovery may require a level of attention to content and product taxonomy that does not make sense to place before User Stories focused on the initial user interaction.)

If your organization does not allow you to pull business stakeholders in for a day or two every 2 to 3 weeks, you should plan for a “Test Sprint” after the construction Sprints.

The next step in the Pluck Delivery Framework is deployment.  This can be executed in one Sprint.  Some key activities (User Stories) in this Sprint are community management user training (the Demand Media engagement team will do this with your community management team), making the Pluck integration deployable, executing any data migrations, turning up the Pluck production environment, and Go-Live.

The last set of activities is transition activities.  Here, the engagement of the your implementation team will be dependent on how you organize and segment your development activities from your operation activities.  If your implementation team does not actively support and maintain the product that they create, then they will need to pass on their knowledge, code, documentation, and any other artifacts to your operations team.  If your implementation team will continue to be actively engaged in operations, this phase/Sprint may be very short.

We have had the opportunity to work with many great Agile teams over the past few years, and have picked up lots of learnings from teams at SapientNitro, ThoughtWorks, Meteorite, Razorfish, and General Physics Corporation.  I welcome an opportunity to speak with you in detail about how to effectively and efficiently integrate community and conversations into your digital destinations with an Agile approach.

How do you approach Agile?  What parts of Agile work for your integration projects?