Archive for the ‘Agile Business Intelligence’ Category
by Ken Collier and Lynn Winterboer
This article was first published in TDWI BI This Week on July 9, 2013
When quality and testing is moved up front on a project, everyone enjoys a higher quality project. Here’s how your team can be happier with an agile approach to testing, even before implementing key automation tools.
Rather than explain the well-understood theory and benefits of agile, let’s examine how agile testing works in the real world and see how agile business and delivery teams reap the benefits of the methodology and have more fun in the process.
By Lynn Winterboer and Ken Collier (first published in TDWI BI This Week on July 30, 2013)
Agile leaders focus more on the continuous delivery of high-priority value to business stakeholders and less on making sure each worker is always busy. We explain how your BI program will benefit by limiting developer multi-tasking.
Ben and Susan are each a DW/BI director at their respective companies; each leads a department of roughly the same size. Both have the staffing necessary to organize three dedicated, cross-functional teams. Ben’s department is organized into dedicated teams while Susan has functional skills “pools” from which project teams are staffed. Both directors are planning for the coming year and have a similar set of 12 projects to schedule.
Through collaboration with business stakeholders, product owners, project managers, and the program management office (PMO), Ben has a prioritized backlog of funded project requests to schedule into the calendar. With help from technical leaders, he has completed some high-level project sizing and assigned durations of two, three, or four months per project. Projects longer than four months are divided into multiple phases, each designed to fit into one of these smaller time periods. This ensures that long-running projects do not block other projects by dominating the department’s capacity.
Ben assigns a dedicated team to each of the first three projects in the backlog. He then estimates when each team might be free to start its next project, continuing in this manner until he has a reasonable program plan for the coming year:
Startups know that what customers say they want isn’t necessarily what they want. The same principle is critical to the success of your BI project.
As a proponent of agile data warehousing and business intelligence, I am constantly looking for new techniques for delivering value to customers faster, adapting to their feedback, and evolving toward the right business solutions (regardless of initial requirements). The recent book, Lean Startup by Eric Ries (Ries, 2011) and it has rocked my world. In the short time since this book hit the shelves in September, 2011, it has exploded in popularity. Be forewarned, this book is about entrepreneurship and high-tech startups. It isn’t about data warehousing, BI, or analytics … or is it?
It’s been said that agile BI is simple but not easy. That is, the concept of working in short iterations, delivering your BI system in small increments, and evolving the solution based on feedback is easy enough for most people to understand. However, as with many things, the devil is in the details.
At its core, agile BI requires a fundamental shift in attitude, mindset, and culture—motivated by the core values and guiding principles outlined in the Agile Manifesto. This mindset shift is supported by a set of concrete practices and disciplines tailored to make up the agile BI methodology that best fits your organization. In my work with dozens of BI teams attempting to “go agile,” I’ve seen lots of mistakes. This Ten Mistakes to Avoid outlines the most common and recurring errors to help you avoid repeating the mistakes of others.
- Believing agile is just a project management thing.
- Thinking agile is just a developer thing.
- Confusing agile with Scrum.
- Failing to cultivate agile mindsets and attitudes.
- Using wish-based planning.
- Over-relying on specialized roles.
- Limiting customer collaboration.
- Not embracing adaptive scoping.
- Measuring the wrong things.
- Cherry picking agile practices.
It has been far too long since my last post, and frankly I’ve been up to my ears in alligators in my new role as director of Agile Analytics at ThoughtWorks and haven’t had enough time to write. So, if you’re still out there following this blog, I appreciate your patience. I have a lot of topics in the queue to write about and I’ll be making that a higher priority in the coming months.
Meanwhile, I’d like to tell you about a wonderful experience I had in June in Melbourne, Victoria, Australia. Over the months prior to my trip I had virtually met Em Campbell-Pretty (@prettyagile) on the Agile Data Warehousing LinkedIn forum. Em leads the data warehousing group at Telstra, one of Australia’s largest telecommunications and media companies. I can’t quite figure out whether to refer to Em as the DW director or manager. You see she is the epitome of a servant leader, and titles don’t seem to matter much to her. I know this because I got to meet Em in person when she invited me to visit Telstra’s data warehousing group when I was in Melbourne. I got to see what they were doing and participate in a discussion about what is working well and where challenges lie. The following week Em and I were both speaking at the Agile Australia 2013 conference where we became even better friends.
I was very impressed by what I saw and learned while I was there. This is probably the most well-scaled Agile Data Warehousing group I’ve ever observed, and they are still getting better. Em’s group is composed of 6 DBT (design, build, test) teams working across approximately 24 separate projects as well as an offshore product support & maintenance team – all working on a shared code base. That’s a lot of moving parts that need to be in sync. They are using aspects of Scrum, XP, Kanban, and Lean development, and they have been very successful at adapting these methods to data warehousing and business intelligence and it is working very well.
One of the most notable techniques Em’s group has adopted is the Scaled Agile Framework (SAFe) developed by Dean Leffingwell and described in Dean’s book, Scaling Software Agility. Now Dean is not a data warehousing guy but, like many great agile techniques, his SAFe adapts very nicely to the complexities of data warehousing programs that consist of multiple teams sharing the same code-base. I urge you to read Em’s recent blog post, A Perspective on the Scaled Agile Framework, which summarizes her teams’ journey toward the effective scaling of agile data warehousing and BI. It’s working extremely well at Telstra, and it might just work for you.
And while you’re on Em’s blog site, read her other posts about her teams’ agile DW journey. It’s a good story. I look forward to my next trip to Melbourne.
Check out this TDWI BI This Week interview of Michael Whitehead by Linda Briggs. Michael is a friend of mine and the very astute CEO of Wherescape, a company that produces tools that enable agile data warehousing. Michael’s comments reflect much of what I mean when I talk about “being agile” rather than “doing agile”. Here is the opening teaser…
“Current data warehouse projects simply take too long to produce value, says CEO Michael Whitehead. All too often projects are built on the assumption that they won’t need to change. Instead, Whitehead advocates delivering value quickly, thus winning the time and budget to continue to improve design.
In this interview, Whitehead shares his thoughts on current data warehouse design, agile development, and the best route to revamping a data warehouse. WhereScape, a data warehousing company, offers WhereScape 3D, a data warehouse planning tool, and WhereScape RED, an integrated development environment (IDE) for building, deploying, managing, and renovating data warehouses and data marts.”
In September, 2012 I had the honor of presenting the keynote address at The Data Warehousing Institute (TDWI) World Conference in Boston. Here is the abstract and video recording of that presentation. I hope you enjoy it.
The carpenter is a skilled craftsman who is adept at reading architectural plans and building what is prescribed. A good carpenter has a well-developed set of skills, high-quality tools, and the experience to build high-quality structures that will last.
The cabinet maker’s work is designed to be seen and must be visually appealing. The joints must appear seamless, and the finish flawless. A good cabinet maker works with the customer to design a functionally effective configuration and select styles, color, and appearance. Unlike the carpenter’s coarse tools, the cabinet maker’s tools are precise and delicate.
The furniture maker’s work must serve a specific purpose, but its actual design and appearance can vary widely. A chair might have arms or not, have a high or low back, be symmetrical or asymmetrical. An innovative furniture maker’s vision is not tightly bound by the appearance of the chair, only by its functionality. The artistic furniture maker is not directed by the customer, but instead measures success by how many customers buy his work.
All three are skilled craftspersons who possess the right skills, tools, and experience. Data warehouse, BI, and analytics practitioners have historically been most like the carpenter, building what the architects prescribe. This talk examines a blend of Lean Startup, Kanban, and agile techniques that offer the opportunity to work more like cabinet makers and furniture makers, infusing creativity, vision, and innovation into our results–-and measuring how well our customers like what we build.
The following is a guest post written by Michael Koploy, an analyst for Software Advice. This post is a summary of a more in-depth interview that Michael conducted with Loren Bast, Director of Business Intelligence at Cheezburger.com. I always love hearing what’s working for BI directors, and I’m never surprised when the things that work have the essence of agility. The Cheezburger story has these characteristics. Please let me know how you like this guest post. If it’s sufficiently popular, I will consider more of these in the future. Cheers, Ken
A quick glance at Google Trends data confirms that Big Data–at least as a marketing phrase–is at its peak. Over the past year the phrase has skyrocketed in popularity, most likely thanks to searchers both curious about what Big Data means, and how they should approach data management when information has more volume, variety and velocity than ever before.
But analyst firm Gartner is quick to condition users that with great technology investment, comes great responsibility. Gartner found that almost three-quarters of Business Intelligence (BI) projects fail, and that only 30 percent of projects will have successfully aligned business objectives and measures by the end of next year. So how can organizations work to ensure their BI investment is as successful as possible?
I recently had the opportunity to chat with Loren Bast, Director of Business Intelligence at online humor network Cheezburger. Cheezburger invested in a new BI tool because it was unable to keep up with the amount of data it was producing across its popular humor websites such as I Can Has Cheezburger and FAIL Blog.
The following article was originally published by TDWI in the May 15, 2012 issue of BI This Week.Startups know that what customers say they want isn’t necessarily what they want. The same principle is critical to the success of your BI project.
As a proponent of agile data warehousing and business intelligence, I am constantly looking for new techniques for delivering value to customers faster, adapting to their feedback, and evolving toward the right business solutions (regardless of initial requirements). I recently read the new book, Lean Startup by Eric Ries (Ries, 2011) and it has rocked my world. In the short time since this book hit the shelves in September, 2011, it has exploded in popularity. Be forewarned, this book is about entrepreneurship and high-tech startups. It isn’t about data warehousing, BI, or analytics … or is it?
The following post was originally published by the Cutter Consortium as an e-mail advisor for the Data Insight and Social BI practice in December, 2011. Hence, the reference to the holiday season. That publication can be found here.
In honor of the holiday season, this month’s topic is focused on an all-too-familiar problem: the common hangover. No, I’m not speaking of an “adult beverage” hangover, although if I find a cure for that I’ll be sure to share it with you. The type of hangover I’m speaking of is the routine failure of your agile delivery team to complete the user stories it commits to during sprint planning.
I’m surprised at what a common occurrence this is for many agile analytics teams. Here are a few example scenarios:
- The team completes development but testing hangs over into the next sprint.
- The team completes the data integration elements of a story, but the demonstrable corresponding BI features hang over to the next sprint.
- The story is too big to be completed in a single sprint, so the team just allows it to hang over into the next sprint.
There are other examples, but you get the idea. A hangover is not the same as a BI feature that is technically done, but the customer review calls for further modification or refinement (it isn’t “Done! done!”). A hangover is simply a failure to have the completed story ready for customer review at the end of the sprint. Continue reading “Curing the Common Hangover” »