By Ronald Pasko,
Vice President, Delivery Excellence at Clarity Insights. Ronald leads the Delivery Excellence practice at Clarity Insights which is focused on continuously evolving and improving the way our team approaches projects from planning through implementation to ensure positive outcomes for our clients, our firm, and our consultants. Ronald has over 15 years of experience in data and analytics having delivered numerous complex strategy and implementation engagements across a variety of industries.

The agile method of software development has helped organizations improve software quality and team productivity. This blog series is geared towards helping you make agile work for your data and analytics initiatives.

Part 2: Getting Strategic About Your Agile Data & Analytics Program

Agile for Data & Analytics requires thoughtful planning and organization as it relates to overall business goals and architectural foundation.

The Crew Is Ready, Boss
In Part 1 of this series, we concentrated on ensuring that your team was ready for agile. Once you have established the need for a data and analytics (D&A) program, you likely also have a line of sight on the first set of business capabilities that you want to enable.

The temptation for many organizations is, therefore, to jump immediately to the tactical aspect of agile planning and start building the backlog for the first release. However, jumping in without a more strategic plan can result in a lack of clear vision and the creation of enormous amounts of technical debt.

So send the crew out for a coffee break. We have some planning to do.

Even an Agile Program Needs a Roadmap

As we remarked in Part 1, the product owner (PO) is the steward of your D&A program’s vision. They both prioritize deliverables for the different business capabilities within each release, as well as ensure the team is staying on track and delivering value. But where does this vision for the overall program come from? How detailed does it need to be? The vision needs to be more detailed than a loose coupling of use cases and broader than just the immediate priorities for the PO to manage effectively. You need a roadmap.

The primary difference between a roadmap for a traditionally executed project and an agile one is that an agile roadmap does not necessarily proscribe estimates of when certain business capabilities will be delivered. Rather, it leaves room for new capabilities to be added, some to be taken away, and others to be re-prioritized. Ultimately, it identifies the overall desired direction of the organization over a term longer than several sprints. The critical elements of your roadmap should be:

  • Business Goals: What are the key, strategic objectives that the D&A program should deliver? These will usually be organized by business function. The scope of these goals should be somewhat expansive - do not narrow your focus to a single business unit. Consider needs from any business function you are likely to serve with the end solution within the next 2 to 3 years.
    Having too narrow a focus may constrain your vision too tightly, resulting in tactical requirements and functional limitations that ultimately leave underserved constituencies over the long term. A good example of a business goal would be: “We seek to use data to optimize our marketing channel mix.”
  • Goal Prioritization: Of the goals we know today, how do they stack rank in terms of priority? You are encouraged to rank these goals across the enterprise rather than within each business function to avoid perpetuating underserved needs.
    Although this prioritization may not be static, it should change less frequently than other areas of your plan and should serve as a moderating influence to keep your delivery capabilities stable. Further, it should also help support a coordinated build process where teams can leverage earlier releases, avoiding siloed solutions.
  • Initial Business Capabilities: For each business goal, what are the new analytical capabilities you need to enable to achieve that goal?
    Good examples include: “Enable descriptive measurements of effectiveness of existing marketing channels”; “Enable analytics to predict the effectiveness of new campaigns on existing marketing channels”
  • Initial Capability Prioritization: Of the capabilities we know today, how do they stack rank in terms of priority? Whereas goal prioritization tends to be straightforward, you should use more specific, quantitative measures such as business value/impact and technical readiness when prioritizing capabilities. Capability priority will be periodically revisited as the solution and environment evolves.
Flexible Planning with a Clear Vision

During steady state operations, the PO will use the roadmap as the ultimate arbiter of priorities during release planning, epic/story definition, and backlog grooming. Every item that reaches the top of the backlog should be addressing the most important capabilities aligned with the most important goals. This structure permits the PO to properly direct attention to the most business critical priorities without needing to defer to the individual stakeholders each time the backlog needs to be groomed.

Although flexibility is the hallmark of an effective agile environment, the roadmap serves as a moderating influence to what otherwise might be defined as chronically shifting priorities. If goal priority is changing every release, it becomes extremely difficult for a D&A program to deliver concrete business value. Clear communication between the PO and the key stakeholders is crucial to strike the balance between two forces of “flexibility” and “stability.”

To help facilitate this communication, be sure to have an effective change management structure in place. Goal reprioritization (including adds and deletes) should not be taken lightly, but should be discussed with all stakeholders and impacts clearly communicated in an open and transparent manner. Ensure the team is also party to the outcomes of these discussions that they may understand when and why the vision may be changing.

The PO and the Scrum Master will play critical roles in this communication process. Nothing de-motivates a team more than not understanding the value they are delivering. The key message here is that it is acceptable to change program focus if needed, but it must be approached intentionally and with care.

Finally, remember to keep both the capability backlog and the goals themselves “fresh.” Whether you are intentionally updating them or not, regular reviews of your goals and capabilities is critical to ensure your program remains in step with the business and the needs of the organization, as well as the practical realities of a changing project environment (evolving people, processes, and technology). This helps in preventing “tunnel vision” with respect to the original roadmap.

We’ve Got the Team, We’ve Got the Plan

Whether you spend 2-weeks or 2-months preparing your roadmap, it is critical to ensure you are capturing your business goals with sufficient breadth and depth, prioritizing them, and linking them to your business capabilities. The value of the moderating influence that a roadmap provides cannot be overstated. If you do not use the roadmap to constrain prioritization during the agile process, you risk fragmentation of your efforts and will get many things only partly accomplished with potentially wasted effort and reduced business value. Once you have this clear vision in place, however, you are finally ready to break ground.

Next Time

Part 3: The Architectural Minimum Viable Product

You may also like:

Data Visualization Big Data

How Graph Analytics Drive Innovation in the Financial Sector

Graph analytics, a set of analytical techniques that look at relationships between different kinds of data, has the pote...

Big Data

Integrating Data on a Shared Hadoop Platform for the Financial Sector

Financial services firms are notorious record-keepers. They have to be—the financial/banking industry is among the most ...

Big Data Customer Analytics

Hey, Advertising Agencies: You Need to Embrace Big Data

At first, it may have seemed big data wasn't much more than a tech buzzword. It's understandable if your agency was skep...