This is the first in a Clarity Blog series to help you make Agile work for your organization’s Data & Analytics Program:
Over the course of the last decade, the concepts of Agile software development have resulted in successful business outcomes for organizations of all sizes. However, these same organizations that see a tremendous uplift in software quality and team productivity often struggle to realize these efficiencies for data and analytics projects. This blog series is geared towards helping you make Agile work for your organization’s data & analytics initiatives.
Part 1: Building an Organization Ready for Agile
Before you embark on your Agile journey, be sure you have created an environment where Agile can thrive.
Ok, you have decided that it is time to apply Agile to your organization’s toughest data and analytics (D&A) challenges. You have your Kanban board ready. Your team is prepared to start your first 2-week sprint. But are you truly ready for Agile? Before you start debating the merits of “burn-up” versus “burn-down” charts, we implore you to step off the starting block for a moment.
When the innovators of software development responsible for Agile sat down to draft the Manifesto, they were not looking to simply tweak the conventional approach. Agile requires a fundamental change in how we think about organizing our projects for success and a willingness to think about problem solving in a new way. This is arguably more challenging for data and analytics teams whose core business may not be software development.
Preparing your Team to Go Agile
Your organization needs to prepare to go Agile. This prep is more than sending a handful of lucky individuals to Scrum Master training. You need to rethink the roles involved in your initiative and ensure you have the right people in the right places. No two organizations are alike. However, every successful Agile D&A team should keep the following precepts in mind:
- Agile is stakeholder-intensive: Values #1 (“Individuals and interactions over processes and tools”) and #3 (“Customer collaboration over contract negotiation”) in the manifesto concentrate on collaboration. It is impossible to achieve this if you are engaging with your business stakeholders only during requirements and acceptance testing. Your users must be represented and actively participating in every aspect of the process including design, development, and even early testing. The key is continuous feedback and course correction throughout the release. This added involvement is not optional.
- The product owner role should not be taken for granted: Getting the product owner (PO) role right is as critical to Agile as proper diet is for being a runner. The PO is responsible for, among other things, setting the vision for the program and ensuring business/user stakeholder involvement. Thus, this individual needs to be from the business. Even the most well-intentioned and well-informed IT stakeholder is unlikely to have the background and the influence necessary to set the tone for the aforementioned “stakeholder intensive” atmosphere. Further, the PO must remain dedicated to the effort throughout its life. Though this is a time-intensive role for a business stakeholder to undertake, it is required to make Agile work.
- Empower the team: Further, it is necessary to foster an environment of efficient collaboration. Agile teams are naturally cross-functional. The fewer barriers and “hand-offs” that you have between your analyst, development, and testing capabilities the better. The more that these three capabilities are working together to develop a minimum viable product for a given sprint, the quicker your iterations will be and the more productivity you will get from each sprint.
- Agile requires full organizational buy-in: The Agile approach can be a radical shift for many organizations. Your entire stakeholder community (IT, business, and executives) needs to be behind the shift towards Agile and understand the trade-offs. Most critically, they need to be fully invested in the “fail-fast, fail-cheap, and learn quickly” mindset. Your users must be prepared to evaluate early iterations of analytical capabilities where the data is not perfect. Your team must be prepared to adapt quickly to feedback which is provided continuously. These are major changes in the way a typical analytics organization functions and, frankly, takes some getting used to.
- Planning for Flexibility: One of the clearest benefits to transitioning to an Agile D&A program is Value #4 - responding to change. Teams that deliver using long iterations with infrequent stakeholder touchpoints (the “traditional” way) often are met with the fact that the requirements, fuzzy to begin with, changed over time. When they get to Acceptance Testing, the rules have changed. By leveraging Agile processes (e.g. frequent backlog grooming and re-prioritization), the program can rapidly respond to what the user community is really asking for. However, there is a trade-off: your delivery schedule will need to be more flexible. What you promised to deliver in 3 months will bend and flex to the realities of what your team can deliver and what the data and tools will support. Your executive stakeholders must not only understand this fact, but also be supportive of it.
Getting Back on the Starting Block
Getting your organization ready for Agile does take a fair amount of preparation and requires an intentional commitment to Agile value and processes. This shift will not happen overnight. However, teams that make these investments will find themselves much better prepared, not only for the first sprint, but for the entire race.
Part 2: Getting Strategic About Your Agile D&A Program