The Agile Analytics book aims to provide an adaptation of the Agile development approach to the specific characteristics of Datawarehouse (DW) and Business Intelligence (BI) systems development. The book is divided into two parts.
The first part focuses on Agile project management techniques and delivery team coordination. The book includes chapters on Agile project management, customers and collaboration, user stories for BI systems and self-organizing teams. The second part of the book focuses on the technical methods that are necessary to enable continuous delivery of value at production-quality levels. This part contains material on evolutionary design, TDD Warehouse development, version control or project automation.
The book is well written and well-structured. The concepts are illustrated with many anecdotes and examples. An important list of references and further reading material is available at the end of the book. My favorite part is the chapter 6 that deals with evolving design, a key factor for successful agile projects.
I will naturally recommend this book to every developer or manager involved DW and BI projects, but this book has also a much broader appeal. The issues specific DW or BI are not far for every large project, where databases play a major role, as it might be for instance in a mainframe environment. There you usually have to balance the architecture, performance and stability needs expressed on the database and operation sides of your organization with the goal of delivering frequently new working software.
With his process of adapting Agile to data analytics, Ken Collier provides also a interesting framework for people that are involved in the transition from a traditional project management structure to an Agile approach.
Reference: Agile Analytics : a value-driven approach to business intelligence and data warehousing, Ken Collier, Addison-Wesley
Quotes
You should now understand that Agile Analytics isn’t simply a matter of chunking tasks into two-week iterations, holding a 15-minute daily team meeting, or retitling the project manager a “scrum master.” Although these may be Agile traits, new Agile teams often limit their agility to these simpler concepts and lose sight of the things that truly define agility. True agility is reflected by traits like early and frequent delivery of production-quality, working BI features, delivering the highest valued features first, tackling risk and uncertainty early, and continuous stakeholder and developer interaction and collaboration.
Effective Agile communities frequently resynchronize and revalidate their project visions, assumptions, and expectations. As the customer community adds or revises user stories and reprioritizes the backlog, these changes must be shared across the entire project community. As the technical team uncovers technical risks and issues, the impacts of these on the project plan must be communicated to the entire community. As business strategies change stakeholders’ project visions and goals, these new visions must be communicated across the entire community.
It is my contention that teams that do not practice integrated, automated testing cannot be Agile.
Storytests are specific examples of user stories. While unit tests are typically written by the programmer to test low-level components or units, storytests can be written by users or business analysts because they describe examples of business stories. […] No work begins on a user story until at least some storytests have been written for that story. Customers, product owners, and testers can continue adding storytests, but there must be at least one before developers can start building.