Most data analytics teams are pretty chaotic. You have request coming in from business units and they’re 70-80 percent ad hoc. Everyone needs their data yesterday and the mountain of request keeps piling up. You can’t see past next week, and the thought of planning for next quarter seems like a daunting task to complete. Between the hours spent on requirements documents, code reviews and the business not understanding what they truly want, your time to finish a request is weeks and sometimes months.

Because of the laundry list of issues we were encountering, it was an easy decision to move my team to a more agile approach.

So what did I do?

I took the framework of traditional agile methodology within the SDLC realm and applied to our team and adopted the principles of the continuous cycle of Building, Measuring, and Learning. Having this structure in place allowed us to take back the power and ownership of what we were working on within a given time period. We set the expectation and developed an operational approach to deliver a set number of predetermined projects within a two-week sprint. One of the most critical components with this change was communicating with our stakeholders. This wasn’tasking for permission but a declaration that things are changing and you can get onboard with us or get left behind. Now…of course I was much more cordial, but you get the idea. I got rid of code reviews and requirements documentation. We were no longer interested in the data you needed. We wanted to understand the problem you’re looking to solve. This paradigm shift allowed for our analyst to truly be analyst and not just SQL coding robots. We also put the ownership of feedback and validation on the business unit. They were responsible for getting us feedback in a timely manner. If they opted to drag their feet on getting back to us, that project would be moved to the back of the line in terms of importance because if it’s not a priority for you it’s definitely not a priority for us.

“At a very base level, you don’t have to work in chaos. There’s a better way”

The execution of a sprint

After communicating to my team and various departments for about two months, we started our two-week sprint. The projects were assigned based on a Project Prioritization Matrix within the Six Sigma framework. It’s basically a weighted scoring methodology to allow those projects deemed most critical to the enterprise to be focused in the order of most impactful. Additionally, we held a pre-sprint call to ask questions and get clarification on projects. The expectation for the team was to work on their sprint items from inception to completion within that two week time period. We met daily during the sprint to address any roadblocks they were encountering and also as a means to collaborate on SQL logic, dashboard development or anything else were knowledge could be shared to overcome hurdles. After the sprint was over we held a Review & Retrospective with all stakeholders. It was basically a show-n-tell and allowed the analyst to showcase what they’ve created and get feedback. This meeting is an extremely critical aspect of the sprint process. For a new department like ours, it shows them the things we’re capable of and the breath of our technical knowledge and how they can leverage our expertise to their benefit. We received rave reviews from many of our stakeholders on both the quality and speed of our deliverables.

What did I learn?

1. Empower your team. Allow your team the freedom to utilize their knowledge of the business and the objective that was trying to be achieved to come up with a solution without the restrictions of useless documentation.

2. As a VP or an executive, your value is the planning and the preparation. You should be planning months ahead, managing the backlog of request and ensuring the balance and focus of the projects are aligned with the enterprise goals of the institution. Let your managers execute by putting them in a position to be successful.

3. Make sure you have excellent managers.

4. Moving to an agile framework has allowed us to get proactive vs reactive. We now spend a good amount of time on projects dealing with Machine Learning and building Predictive Models that will have extreme benefit across the institution.

5. We are more productive, more flexible and deliberate in our approach. We deliver reporting more strategically because of our ability to combine a long term strategic vision with the current needs of the departments. This reduces redundant work and allows the vision of the enterprise to remain paramount, while supplying the data needs of the institution.

At a very base level, you don’t have to work in chaos. There’s a better way.