Making Your Business Intelligence Team Agile

So, you think you can’t make Agile work within your business intelligence team?  Think again.

Agile business intelligence isn’t new; many people have written about it.  It’s mature enough now to have a smattering of books lining the shelves. What are these books based on? Experience. People are executing it and have been for some time.

At Daugherty Business Solutions, we have a group of those experienced professionals on our team. In fact, we have worked with a large telecommunications client for fourteen years using parallel Agile sprints to support enterprise financial performance reporting. The group in place has evolved from large teams to manageable teams of eight, and members have cross trained between ETL and data visualization tools.

The evolution of these teams was not an accident, but instead an orchestration of the Agile methodology. Some people may think of the term Agile and wonder if that applies to business intelligence in the same way that it does application development, and there is no doubt that there is a difference between the two. But, the specific factors differentiating these doesn’t need to be standing in the way of organizations realizing the benefits of using Agile principles to bring more value to their customers, more quickly, and with less overhead.

So, how do you do it?  Before making that determination, there are two key things that need to be identified.

First, data projects are different. You have to acknowledge it.  Sing it from the rooftops! Just like we cannot use exactly the same team and methods to successfully execute a Waterfall application development project and a Waterfall data project, we certainly can’t use the same team and methods to execute an Agile application development project and an Agile data project.

For example, Team Daugherty is working with a cable company’s business intelligence group to build Agile capabilities into their current teams. As we launch projects with them, we’re working through our planning sprints and introducing an additional sprint to allow for some of the coordination and planning required when implementing projects. This is important when using full enterprise data stacks and fully mature data warehouses. By planning more up front, we’re able to fully implement Agile practices, and we are seeing an extremely positive response from our business partners.

Second, because information management projects are different and have different players, characteristics and challenges, we’re going to have to let go of some of our purist notions of Agile.  Think for a minute about this question: what is Agile at its core?  Is it ceremonies?  Is it a product backlog? Is it cadence? Agile is not one of these things. These are all things we do within specific Agile methodologies. To be Agile is to generate value for the business in a consistent, timely manner. The rest are just rules.

Does this mean that we want to throw all of these guidelines out the window? No! What it does mean is if a particular rule is preventing us from achieving our goal of realizing the benefits of Agile, we should evaluate it for validity within the information management discipline and weigh that against how that particular rule helps teams realize specific Agile benefits.

This is true for a number of the projects we are working on right now. One that is top of mind is a project that has Daugherty working with the business intelligence group at a retail client to define how Agile principles will be applied on their teams. As we know, one size does not fit all. In this IM project example, unlike application development projects, it does have some stories that must be executed in a specific order. Working together with the client’s teams and product owners, we’re redefining how the stakeholders prioritize features and the value produced in each sprint, knowing that some of our work items must be executed in a specific order. It may be a specific Agile rule that work items are designed to be interchangeable and can be re-ordered at any time, but we know that, in this situation, that is not what is going to lead us to be the most successful.

Just remember, we’re going to have to let go of “purist” rules and methods, weighing them carefully against the value they bring. Through our work we know that it has to be okay to sequence some work items in a specific order to deliver value to the business.

When working as a part of an Agile team at Daugherty Business Solutions, I have learned that we value “value” more than rules.

Yes – You Can Embrace Bi-Modal IT and Be Better for It

As the Digital Business Revolution rages on, we’re continuing to see businesses struggle to keep up. This blurring of the digital and physical world doesn’t show any signs of stopping, either. With the continued creation of new business designs, how does one balance the tried and true method with the exciting opportunities of innovation?

The problem that we see quite often is a misalignment between the dollars spent and the value returned. Gartner’s Pace Layered Application model shows us that IT is spending the preponderance of their budget on systems of record, even though it is the systems of Innovation and Differentiation that provide the most value and alignment to the business strategy.

This is where Bi-Modal IT comes into play, which is a term Gartner uses to describe the dual set of capabilities, activities and deliverables. It’s one of the tactics used to try and right size this conflict by dividing IT into two distinct paradigms.


Take a look at the graphic above and think about this – New business models are arising daily, and it takes a different thought process and structure to keep up with the speed of change (Mode 2 on the right). For example at Daugherty, there is still a need to operate in Mode 1 (on the left), providing the rock solid reliable delivery necessary to ensure our customer’s customers are getting the value they expect. Our 30 year history is built on providing valuable, predictable, end-to-end project delivery. But, that does not conflict with our embracement of Mode 2 for systems of innovation.

For our clients, we have helped several of them move to a more agile, product-based way of thinking, where rapid deployment and feedback can provide a competitive advantage and deeper customer loyalty. This starts with a deeper alignment between the business and IT. When this happens, you can truly measure success and see the desired business outcomes that stem from this type of partnership.

The truth is that innovation is going to happen, and it will happen with or without IT’s knowledge and guidance. As we can all likely agree, IT should be the one providing the guidance and understanding of where and when to use cloud, PaaS, and SaaS, and providing the landscape and the ability to rapidly prototype and stand up proofs. However, the business has tools at hand to act as citizen innovators that are far more powerful than the old Shadow IT of the past.

While change can feel risky, an IT that embraces Mode 2 will be better positioned to ensure feasibility and sustainability of systems when prototypes and pilots turn into production systems. And yes, you can accomplish this without leaving behind the delivery excellence of Mode 1. With a Bi-Modal IT structure, it allows the business to be a partner with IT, not competitors.

Here are some things to keep in mind for embracing the culture of innovation, or Mode 2:

  • Failure is an option, and failing forward is a valid plan
  • Value driven decision support and alignment out weighs other factors
  • Consistent teams will have a sense of ownership and accountability
  • Focus on brand, experience, sentiment, and loyalty
  • Business driven, in many cases, exposes new tools and techniques
  • Be risk tolerant
  • Be Mobile, anywhere at any time
  • Low, organizational governance
  • Continuous learning



Agile in the Real World – Is It Right for Your Organization?

At Daugherty, we probably hear about Agile Development more than any other topic. Common detailed questions such as: How do I get started? Should I use scrum? Can my PM be the scrum master? Then, there’s also the other big picture questions about the nature of migrating from a waterfall or an iterative approach to full agile.

Daugherty believes that there is no one answer that fits perfectly into every environment. The truth that everyone must understand is:

  • Agile is not a magic bullet that is going to solve all of your IT dysfunctions
  • Agile is not a set of ceremonies and artifacts, but is a cultural discipline that demands a change in thinking as well as process

Let me start off this conversation with the question we should be getting asked. Why Agile?

Agile Construction provides key benefits that will align IT closer to the business outcomes it provides, reduce rework, and provide tangible value quicker to the business. No matter how you design your Agile program, it must have:

  • Rapid Feedback from all parties that leads to less rework, highest value construction, and better definition of the deliverables
  • Embedded Q/A and continuous testing (we are going to be ruthlessly refactoring; we need to make sure we aren’t breaking the things that used to work)
  • Tight, well-defined relationship between the business and IT, dedicated product owner(s) that is willing to guide the teams through all decision and feedback stages
  • Empowered teams that are allowed to self-select, self-drive, and self-commit to the work being done (along with empowerment comes responsibility and accountability)
  • Faster release cycles, getting the high value, completed items in the users hand as quickly as is feasible
  • Prioritized risk evaluation, making sure that architectural or technical risk is addressed before functionality is fully developed

An Agile program can leverage Scrum, XP, Adaptive Software Development, or any of the other Agile frameworks, as long as first and foremost you keep the above disciplines in place.

So to address the bigger question… Should you go Agile?

Let’s look at what it takes to truly make agile work. First and foremost, you need a committed business and IT alignment, where value, funding, and outcomes are all in sync. If you do not have this, your first step should be to invest in a Business Alignment workshop, otherwise you may have Agile construction, but you will never have an Agile Enterprise.

Second, you have to understand your current staff. You wouldn’t ask a Java shop to start coding in .NET without training, continuous education, and a coaching plan. Nor should you expect your business and IT resources to be able to pick up the rigor and discipline of Agile without the same level of training and support. In addition, the way you allocate resources, to product instead of by project, may mean an organizational change is warranted, which again can be culturally difficult to accomplish.

And lastly, follow the money. Is your organization willing to make decisions without full knowledge of cost and delivery date (many would argue that we never had this and that we were just kidding ourselves in Waterfall)? Daugherty believes that some upfront work is necessary, that a level of scoping and overarching requirements should be rapidly gathered and allow for the final feedback driven scope to emerge. Emergent architecture and emergent standards should be avoided where possible. Agile works best when Architecture and Security are provided as up front guidance, followed by just-enough governance, to business and construction teams.

We, ourselves, run an agile shop in our Dev Centers and have several scrum masters and certified SAFe experts across our team. We’re helping clients through agile workshops and coaching, Rapid Process Mapping techniques (the quickest, most accurate method of getting 80% requirements), bringing Agile programs to scale, and even Bi-Modal IT and Application Pace Layering. Let us know when you’re ready to talk agile. Team Daugherty is ready to help you.