No Meetings
As a Product Owner or Scrum Master
I want to understand how to deal with ‘meetings’ in an AgileBI project
So that I can change the team’s negative view on collaboration
A Massive Change
One of the biggest challenges of using Agile methods to deliver BI projects is the massive change in the way the team has to work.
Everything from the way they plan, their level of accountability, the way they interact with their team, interact with other teams and stakeholders, and the tools and techniques used are all different to what they are familiar with.
Meetings, Meetings, Meetings but not an Outcome to Find
One of the interesting changes is moving the team from their concept of meetings. To the team a meeting is something that:
- is planned in the future
- often has unclear goals
- a raft of people are invited to, often even if they are not required to achieve those goals
- is always for at least an hour in duration
- is often seen as a waste of everybody’s time
Unless its an AgileBI “Meeting”
When undertaking an Agile project, we actually see a massive increase in the amount of time the team spend together collaborating, from attending sprint planning, backlog grooming, retrospectives through to constant group sessions to nut out the many problems they strike.
Initially though we will often see the usual disparaging attitude to these collaboration sessions as they are perceived as the meetings of old.
Planning has Massive Value
Once the team gets to experience the value that sprint planning delivers in helping them work through the steps that they will undertake in the upcoming sprint, they will typically embrace them with open arms. The same can be said for backlog grooming, once the team experience how constantly refining the user stories in advance helps reduce the time required for sprint planning, as well as ensuring that every new requirement is captured weekly, they see the value in these planning sessions.
One interesting example that we often see is the use of meetings to help troubleshoot a problem or clarify an expectation.
Where possible the AgileBI team is always co-located to assist with collaboration and communication. When a new team starts working together and strikes a problem, they will often book a meeting in everybody’s diary at sometime in the future to work through the issue. The same is when they want to clarify the expectation for a user story with the product owner, a meeting is booked in the future.
When running three week iterations these delays can kill the successful delivery of the sprint. Given the team are all dedicated to the sprints there is nothing stopping the team from getting together to discuss the issue when it arises, often by just swiveling their chairs around or by all immediately getting up and standing around a whiteboard.
It’s not until you point this out though that the team realise the latency that these future based meetings cause and change their behaviour.
As with all things Agile, constant collaboration is a major change in the way the team works and often simple behaviours that have been embedded for years need to be changed.
Meetings are DEAD, long live Collaboration
In our AgileBI projects, we ban the use of the word “Meeting”.
All pre-planned events that require the team to get together are scheduled at the beginning of the sprint and have an outcome. Those events are named after that outcome (e.g., backlog grooming). Any other requirement for the team to collaborate are a result of the user stories being delivered, and the team should immediately get together to ensure there is no delay in removing the roadblocks for that user story.
In a three-week sprint, every day counts.
ODE & 3CPO – Talking multiple languages
When we decided to start building ODE we knew a few things already. One of those things was that most of our customers already had data warehousing technology.
They had already invested in Microsoft, Oracle, IBM, SAS, Teradata, Informatica or any of the other raft of data warehouse repositories and ELT technologies that are abound in the market place.
We also knew that it would be a big decision on their part to throw out this technology and implement the technology we decided to pick to be able to use ODE and gain the AgileBI benefits that it provides.
ODE – The start of a journey
About two years ago we started a journey into the world of AgileBI. It all started out of frustration (as most journeys do), frustration about the magic sauce.
The magic sauce was the reason why one data warehouse project would be a raving success and the next a ‘meh’. It was often the reason that after delivering a raving success and then returning 12 months later I would find the data warehouse had become a ‘meh’. By that I mean not updated, not well managed and not delivering to the stakeholders expectations.
The little things I love about YellowfinBI #5
User Guide Videos! Typically I dislike youtube videos and prefer to follow the tutorials to get something done. But when I was using the Yellowfin Append Sub Query functionality in anger the other day I just couldn't get it to do what I wanted, even as I followed the...
The little things I love about YellowfinBI #4
Subqueries! Often you want to manipulate the data you are using to get a report just the way the user wants. And often this requires you to do sub queries on the data you are using (for me it was creating columns for my measures based on offset periods, so I could...
The little things I love about YellowfinBI #3
Up to date and easy to find documentation! One of the coolest things about Yellowfin is that they do releases every month which includes squashed bugs and a raft of smaller new features, as well as point releases every six months or so, that typically introduce major...
Introduction
As a Reader of this site
I want to understand what it is about
So that I know whether I should keep reading
The little things I love about YellowfinBI #2
Making the impact of editing the semantic layers visible. When you edit a semantic layer that is being used by users, there is a high chance that you are going to effect the Dashboards and Reports they are using. Why? Because you are changing the underlying layer that...
The little things I love about YellowfinBI #1
Additive and Semi Additive Measures! When creating measures in your semantic layer (called Views in Yellowfin, Universes in BO, Information Maps in SAS, RPD in OBIEE etc) its important to be able to define your measures as additive or semi additive to ensure they...
Yellowfin makes changing view names seamless
One of the frustrations I have with many BI products I have used is that they often state all their components are fully integrated. But when you go to use it in anger you find gaps that increase the effort required to do simple things. Often its around metadata...