Some time has passed since my Industry Insight, Time to get savvy, where I examined the challenges of implementing BI solutions using agile methodologies.
So, I believe it's now appropriate to take a step back, revisit the concept, and review the current state of disciplined agile in the BI industry. Some of the points raised are certainly a meal in their own right, and I may need to write more Industry Insights that dive into further detail on some of these points, at a later stage. But let's get stuck into some of the key areas for now.
Increasing awareness
There has certainly been a rise in interest in utilising disciplined agile techniques in BI. More and more clients are engaging with this methodology in terms of training and implementation.
Some structure is required
I refer to the term disciplined agile, and not simply agile. There have been several vanilla agile implementations, which have achieved mixed success. The importance of achieving a balance between agility and a reasonable level of lean governance and standards cannot be over-emphasised. BI is ultimately an enterprise solution and capability, and as such, a certain level of enterprise awareness and governance is required.
To obtain the best of both worlds, a substantial number of hybrid implementations of agile are coming through, which has led to the rapid growth and adoption of disciplined agile techniques.
Potential harmful impact of micro services
Of growing concern in recent years is the advent and growth of the micro services methodology. This can sometimes be seen "bleeding" over into the BI space.
In BI, practitioners have spent a lot of time moving towards a vision that comprises a centralised platform where all data can be consolidated. This environment would be built on a common set of standards and guidelines, and even if the BI environments comprise federated teams, they would still work from a common set of principles, standards, tools and software. Micro services can be the very antithesis of this concept, and the principles can directly clash.
Adopting this methodology is an all-or-nothing affair.
Some examples of this "principle clash" are a) the requirement for autonomous service teams that operate independently, focusing only on the needs of the relevant service; b) the fact that services are defined by functional capabilities; and c) the emphasis on decentralised control of languages and data.
Micro services in the app-dev world are part of a great architecture and will have enormous success in the future. However, it is important for BI teams to remember their original principles. BI teams need to represent the needs of data and BI, to ensure the principles of centralised and standardised enterprise data management are not lost along the way.
Increasing business demand
The pace that business needs to operate at is a significant inhibitor to BI teams, one that only agile methodologies can really overcome. In the past few years, this has become even more challenging. In many companies, the amount of work BI teams are facing is so perversely large, it is leaving teams feeling desperate and slightly on edge. Companies can almost feel the pressure. There is a sense of desperation and, dare I say it, hysteria, in the air.
This can be a good thing, as it justifies BI's reason for existing. However, it is having significant consequences on staff retention, and the BI-customer relationship.
Surface-level implementation and adherence
Unfortunately, clients often adopt certain surface-level characteristics of the methodology only, and drop elements they feel are not suited to them.
Adopting this methodology is an all-or-nothing affair. It is true that BI practitioners emphasise the importance of being flexible, and finding the balance in all things. But, this applies to how the methodology is fine-tuned to get the right fit. When it comes to the core principles of the methodology, it must all be accepted and implemented. Selectively implementing certain aspects of the methodology will lead to a skewed, unbalanced methodology that will not yield the expected benefits.
Who's the boss?
Often, the implementation of agile is driven as an IT project, without much (if any) participation from business. It must be clearly stated that implementing disciplined agile techniques effectively will fundamentally change the entire SDLC process, from end to end within the company. It is physically impossible to do this without changing the nature of engagement with the business.
It's about people
One of the critical requirements for disciplined agile is a multi-skilled, self-motivating team. A lot of disciplined agile initiatives become stuck due to critical dependencies on a handful of scarce, highly skilled resources.
Business must remember that having the requisite multi-skilled team is a critical element of success in this methodology. As a result, resource training and acquisition needs to feature as an essential element of the strategy for implementing this methodology going forward.
The awareness and adoption of disciplined agile in BI has grown significantly. The majority have moved away from being convinced it is not possible, to accepting it can be done. While this is a very good thing, the potential pitfalls lie in companies not accepting that this will have a real impact on the business.
If business is not screaming for increased throughput of delivery, if there is not a mountainous backlog the team is struggling to deliver on, and if business is not prepared to partner with BI in changing the existing process, then careful thought needs to take place before proceeding. On the other hand, if these things are happening, then, in the immortal words of Douglas Adams, "Don't panic!" The solution is at hand... and its name is disciplined agile.
Share