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.
SFT – Just try it
So you have a good idea, but your not sure if it will work? It probably is, just try it. But make sure you minimise what you lose if it goes wrong. Want to hire somebody but your not sure they are a perfect fit? Who is perfect, just try them. But tell them your not...
SFT – Steering Committees Details Not Needed
Steering Committees are not there to discuss anything in detail, review any documents, or negotiate an outcome. Steering Committees are there as a governance group to ensure the project is on time, on budget, doing the right things, delivering the outcome that was...
The world of software licenses is changing
Apple shakes it up again The latest player to shake up the world of software licensing is Apple. They have released their latest OSX version, Mavericks and have decided to make the upgrade free. And it means no more having to pay to upgrade to the latest features on...
SFT – Customers Buy, you don’t actually sell
You never actually sell anything, a customer always buys something. You can't (legally) make a customer buy what you want to sell. But you can convince them that the thing you would like to sell, will solve a problem they have, at a value that makes sense, from people...
SFT – Accountability
So when a project fails, who gets fired or who doesn't get paid? When a job isn't done properly and a customer decides to go somewhere else, who is impacted apart from the customer and the shareholders? Or when an employee leaves to work somewhere else because a...
SFT – What makes you remarkable?
Seth Godin wrote in his book Purple Cow about being remarkable. He blogged how to be remarkable here. Being remarkable makes you different, it means you will be remembered and means your customers will (often) come back again. Today I had a remarkable experience from...
Why don’t we stick a label on “the business”
Im sat here writing a blog post about why data warehouses die, and I was about to write about that person called "the business". How many times have you worked on a a project where team members talk about "the business"? Its not a person, its not a organisational...
What makes a data warehouse die?
There have been a few different threads for me over the last couple of weeks all around what makes a reporting platform survive and thrive or die. A data warehouse by any other name (By reporting platform I mean data warehouses, analytical data marts, operational...
TDWI Putting the BI into BA and the 3 e’s
As I have blogged before I am a great fan of classifying what we deliver as a company by the 3 e's of Expertise, Experience and Efficiency. For me its a very simple way to focus a discussion on whether the thing we are taking to market will be "cheaper & faster",...