Have you decided to use an Agile approach on your Business Intelligence (BI) / Data Warehousing (DW) project? You’re probably not alone. Though its roots are in software development, Agile is quickly becoming the standard approach to managing all types of projects.
Once the decision has been made to go Agile, it can be tough to know where to start. In this post, I will break down the first two major steps your team should take to implement Agile on your BI project and get set up for success.
Step One: Assess the Current State
Before you implement Agile, take some time to assess your current state. Think about the following considerations applicable to any project trying to go Agile.
What you know about the work you need to do:
- Do you have established goals for the project? If so, what are the goals? If not, establish them!
- What is the expected end-result?
- Who are your customers? Who will use your project and who cares most about the project’s success?
How well your organization currently handles collaboration and change:
- What is the typical level of effort to get input and feedback from your end users and their leadership?
- How do you find out about changes to requirements? What do you do when you get those requests for a change?
- How do you currently prioritize work? What are the outcomes and lessons learned from past projects?
- Where does your leadership stand on taking an Agile approach?
In addition, review the following specific BI and DW project considerations:
- How well is your team set up for collaboration and change? Who is on your team? What are their skills, and are they able to perform work cross-functionally? For example, can your data architects also write ETL code? Can your ETL programmers also design database tables?
- What is your current technical architecture? What aspects are hardest to change? For example, is it so hard to get access to data that when you do, you pull it all in regardless of end user need?
- Do you follow technical practices that can enable agility? (configuration management, automated builds, and deployments, automated testing, etc.)
Understanding where you are now will help you determine if you need training or coaching in order to adopt Agile successfully. There are numerous Agile training options for the Washington D.C. area. There are great courses for all levels of experience, such as Agile and Scrum in a Day, Certified Scrum Master (CSM), and Certified Scrum Product Owner (CSPO). Readers of this post may be especially interested in Agile training tailored to BI issues.
Ideally, the whole team should participate in whatever training you select to ensure that everyone is starting with the same knowledge base. In addition to training, having a Scrum or Agile BI Coach who can work with your team one on one to help you establish Agile methods can be very beneficial.
Step Two: Select an Agile Methodology
Once you’ve established your current state, it’s then time to select an Agile methodology best suited to your team. I recommend trying Scrum as the base method and, to paraphrase one of the key principles of the Agile manifesto, reflect as a team at regular intervals on how to become more effective, then tune and adjust behavior accordingly. That may mean you end up trying other Agile methods such as Lean or Kanban or adapting your team and Scrum to better suit each other.
Since I recommend Scrum, I’ll go ahead and assume that as a starting point. There are two key roles identified in Scrum that enable the rest of the team to focus on getting work done, Scrum Master and Product Owner. It is essential to identify a Scrum Master who will guide the team through using the Scrum methodology and will work to remove impediments so that the team can remain focused on getting work done.
It is also critical to identify a Product Owner who understands the systems you use, the data you are collecting, and who can provide leadership on key business decisions. The Product Owner must have the authority to prioritize the team’s work. The Product Owner is typically someone outside of the development team (possibly someone from the product development or marketing units within your organization) and should be a primary user of the data. An analyst on your team can serve as a proxy for the Product Owner if necessary, but someone who is a business user of your data should be your first choice.
Don’t Give Up!
It might take some time to assess your current state and structure your team, but doing these first two steps the right way will make all the difference for kicking your project off on the right foot. Perhaps you’re already wondering what’s the best way to have that project kick off? Or maybe what your team should do to finish the project strong if you’ve already started?
I’ll revisit those topics soon in a follow-up post, so be sure to subscribe to our blog at the right, and follow us on Twitter to find out when it’s published! In the meantime, share any thoughts about these first two steps in the comments below, and ask any questions we can help you with.