It seems like more and more of our customers are interested in exploring and adopting an “Agile approach” to developing and delivering Business Analytics, and we could not be more enthusiastic about it. From the beginning Quantified Mechanix has been an agile shop, in many ways out of necessity. We have relied on this approach to quickly understand our clients business objectives, investigate, test and confirm our work and deliver value as fast as possible, while limiting the risks of bad assumptions and missing capabilities that are so often fatal to business analytics projects. In particular, we love that agile development is an effective framework for

1. Communicating requirements and objectives;
2. Testing and uncovering assumptions, strategies and tactics;
3. Organizing work according to business priorities and
4. Adapting to changing requirements, environments and capabilities.

In our world, agile projects are organized around short iterations with focused objectives, that are critical pieces of a larger project. Each iteration has key accomplishments and tests to confirm success. It is common that each iteration can stand on its own as a project deliverable, with business value to the project stakeholders. Because the work being delivered is continuously being tested by the business, errors, faulty assumptions and bad design are exposed and corrected early. This reduces the time and cost impact of these issues, improves quality, and provides transparency and visibility to the business because the business is a critical part of the execution. Higher quality, and transparency reduces the time and cost to manage and deliver projects, which leads to faster and higher return on investment.

In our experience, the organizations and teams that are the most successful at using agile to deliver business analytics have a few critical characteristics:

1. The teams are smaller, team members are more experienced, and capable and are focused on the project. This reduces the communication gap, minimizes distractions and maintains the momentum needed to keep everyone engaged and operating efficiently.
2. The project has an engaged and motivated business owner who has a clear vision of what they want to accomplish, even if some of the finer details are still to be determined. This provides critical clarity to the project team as it works to deliver.
3. There is strong leadership commitment not only to the success of the project, but to the approach and to the team. This means that the team has the resources it needs, but also the trust they need to make design decisions as they encounter them and manage the delivery of the project, even as it encounters unforeseen challenges. Even when they make mistakes.

When these characteristics are present, and when the project is on the right path, we notice that it becomes more difficult to distinguish between the business and IT, that both sides have taken ownership of the project to the extent that traditional roles and responsibilities matter far less than usual. Everyone contributes, while developing new skills. There is more doing and less talking about it. There is less project management and more project leadership. Innovation and creativity flourish, tactical problems are solved quickly and elegantly and strategic possibilities and directions open up. With the right mix of talent and people, the project really starts to gain momentum – communication, understanding and the work flow fluidly, fast and efficient.

Sounds great, doesn’t it?

So what are the obstacles preventing this from happening more often?

Well, Agile is not just something you practice. You are either agile or you are not. Imagine assembling a team of crack developers and solution designers and then asking them to produce detailed design documentation, including defined assumptions, discussion of key decisions and detailed project and resource plans. First, it is challenging to design, deliver and document solutions at the same time. There are only so many hours in the day and being agile means to embrace change and innovation, and it is hard to document either of those before it happens. Second, the skills and characteristics of a high performing agile development team are not, let’s just say “well suited” to deliver comprehensive documentation. Even adding people with those skills to the team adds overhead and bureaucracy that stifles projects. Agile documentation is lean and effective – just¬†good enough for the job at hand. By doing this, you can focus more of your energy on building working solutions. The desire to document should be transformed into a effort to collaborate with and trust your stakeholders and team. Your goal is to implement solutions, not document them.

Who’s ready?