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 […]
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.
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:
How well your organization currently handles collaboration and change:
In addition, review the following specific BI and DW project considerations:
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.
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.
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.
Getting Agile requirements right can be a challenge but it’s essential as they can make...
Scaling, like Agile itself, can become a target objective rather than the means to an...