Agile is a group of principals which promote collaboration among self-organized and cross-functional teams, close customer involvement, iterative and adaptive implementation methods, and the frequent delivery of incremental software releases.
Agile methods are built on the empirical process which embraces the three pillars of transparency, inspection, and adaptation. This foundation gives agile the unique ability to manage unclear or fluid requirements, and quickly respond to changing requirements. Agile is a powerful tool for companies seeking methods to respond to the increasing pace of market and industry change.
Scrum is the most popular agile framework. This framework is intended for developing and sustaining complex products and consists of Scrum teams along with their roles, events, artifacts and rules.
When CRM software deployments follow these rules, the agile process shifts project planning from software requirements to well-defined business outcomes, and brings more visibility and predictability to the project.
Agile CRM software implementations also offer several advantages over waterfall deployments, including increased user engagement, increased application ownership by the business and outcomes that align with business objectives.
But as recognized by agile adopters and cited in the Definitive Guide to Scrum, Scrum is simple to understand but difficult to master. As a certified Scrum Master I can attest this statement and as somebody who has leveraged agile methods for many large CRM software deployments I’m going to share some experiences and several learned agile best practices.
Agile & CRM Best Practices
Some of the most critical Agile best practices include the following:
- Adopt the Scrum framework in its entirety. My experience with clients’ is that many believe they use agile or Scrum methods but over time they have degraded or disregarded certain Scrum events, artifacts or other requirements. Sometimes companies use terms like “Scrum-like” or “Scrum light.” These are made up terms which may cause a false sense of security. I’ve found these variations are often driven by resources who are untrained or unwilling to fulfil their roles’ responsibilities. For example, if the Product Owner is unable or unwilling to maximize the quality of the Dev team, or the Dev Team really doesn’t have all the multi-disciplinary skills, the Scrum process breaks down. As shared by two of the founders of Scrum and published in the Scrum Guide, “Scrum’s roles, artifacts, events, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety …” Remember, you’re all in or you’re not agile.
- Assess agile skills and perform training where necessary. A survey by Version One found respondents cited insufficient training as the most significant cause for failed agile projects. Agile methods apply rules and processes to achieve predicted results. If team members are unclear with the rules, or are only familiar with waterfall deployments, deliver the needed training and help them understand the differences between agile and waterfall.
- Ensure each Scrum role fully understands their responsibilities. The Scrum team roles include the Scrum Master, Product Owner and Dev Team – and don’t include a Project Manager. Does the Scrum Master recognize his two primary responsibilities are to ensure the team understands and uses Scrum correctly and to be a servant leader to the Scrum team? Does the Scrum Master really understand he is to manage the Scrum framework, rather than the Scrum team? Too often I see Scrum Masters managing the team and assuming Product Owner responsibilities. Does the Product Owner recognize her two primary responsibilities of maximizing the value of the product and the Dev team? Does she recognize her responsibility to manage the product backlog, and to measure and report project performance and forecast to completion at least once per sprint? Again, too many times I witness performance reporting being picked up in an unofficial way by the Scrum Master. Does the Dev team recognize they are responsible to monitor and report sprint progress at every daily Scrum (preferably using a burn down chart)? The Scrum best practice here is twofold – ensure roles understand their responsibilities and replace roles that are unable or unwilling to satisfy these responsibilities.
- There is no Project Manager role in Scrum. Many times organizations transitioning from waterfall to agile methods just can’t let go of the project manager. This violates the Scrum framework and creates redundancy. Scrum doesn’t avoid project management, it simply reallocates those responsibilities among the three Scrum roles. This also contributes to the agile principal of reallocating leadership from a select few to self-directed teams.
- Begin with the outcomes and work backwards. An agile principle that often gets overshadowed or lost during CRM software deployments is to begin with clarity about the outcome, and let it guide every step along the journey. A closely related principal is that outcomes should focus on customers and business value. Too often, once the CRM project gets busy or timeframes get challenged, the team loses sight of the real outcomes and reverts to implementing software features. Once this occurs, it has a tendency to become perpetual. To prevent this common occurrence, ensure the definition of project success goes well beyond getting the CRM software operational, and includes SMART (specific, measurable, actionable, realistic and time-bound) objectives that benefit users and customers. Don’t make the mistake of believing software features and functions are your goals; they are at best the means to the goals. Design thinking is a closely related method that brings clarity to the most important project goals.
The Point is This
Agile methods promote adaptive planning, iterative development, rapid and flexible response to change, early and frequent deliveries, and continuous learning. As part of a CRM software implementation, this deployment method gives customers greater control over the final solution because they can quickly iterate and determine the direction of solution development and implementation from one sprint cycle to the next.
Agile is more than just a different deployment model, it’s a culture change whereby requirements are much more user focused than technology driven, where collaboration increases the number of contributors and owners to the solution, where communication such as daily stand-up meetings (scrums) creates a rhythm, and where retrospective meetings deliver lessons, insights and actions for continuous improvement.