Be don’t Do
If you are operating under a construct that has a Steering Committee, you are probably not operating as an agile organisation.
If you are not an agile organisation your data team will struggle to “be” agile and gain all the value that an agile way of working can deliver. Often a team will start off “doing” an agile way of working as they work towards the maturity required to “be” agile.
In my opinion this is still better than a waterfall approach when delivering data, analytical driven recomendations or visualisations to stakeholders.
Why agile data teams don’t need steering committees
A Steering Committee’s role is to govern a project and be accountable for making sure the project delivers it’s agreed outcomes to the stakeholders.
In an agile data way of working:
- The agile data team govern themselves, with the help of the Scrum Master to assist them improve the way they work. The team are accountable for delivering what they commit to deliver;
- The Product Owner governs the prioritisation of what is done, and will typically have a group of stakeholders who assist them with the prioritisation. The Product Owner is accountable to make sure the top priorities are delivered first;
- The financials are simple in an agile data way of working, you take the cost of the agile data team per day and multiply it by 15 working days for each delivery iteration. You add on the cost of the infrastructure, which is hopefully cloud-based and therefore has a known cost per day;
- The proof of success is shown each ‘Prove it’ day and measured based on the acceptance criteria being met.
So the accountabilties which previously sat with the Steering Committee, being accountable for delivery, making sure the project is on budget, ensuring the right things are delivered, are all taken care of by the team. And they are taken care of without the need to write endless monthly status reports to the Steering Committee or discussing in detail who is doing what with them.
Prioritise whats next, not who’s doing what right now
A Product Owner will often have a group of people that will assist with prioritisation and this will often be done via a prioritisation event. In fact, one of the most effective ways I have seen this happen is for stakeholders to “horsetrade” their deliverables to see who will define the vision statements for the next iteration. The prioritisation event is not a typical Steering Committee meeting, but the participants of the prioritisation event are often the same people that would be on the Steering Committee.
You will find that their is a tendancy for the participants of the first prioritisation event to try and run it like a Steering Committee, don’t let them. As with all agile events, there needs to be a known and valuable outcome that justifies the time spent participating in the event. For this event it is deciding prioritisation of what the agile data team should work on in a 6 to 12 month time horizon, not the review of a status report based on the current delivery focus and effort that is the desired outcome.
If you are stuck between the PMO rock and a hard place
If you are stuck in an organisation that is still undergoing the transition to becoming an agile organisation, and you are forced to operate under a Steering Committee construct, then run!. But seriously if you are stuck with this, I feel for you, I suggest that you ensure the Product Owner attends the Steering Committee and is the “voice” of the agile delivery outcomes.
No doubt if you are forced to have a Steering Committee you will also have one (or more) Project Managers. Their role should be to organise the Steering Committee meetings and produce the minutes (think Project Administration) not to be the voice of the agile delivery team or the stakeholders.
And if you are operating under that model you probably also have a formal Project Management Office (PMO) in place as well, so the Project Manager can also add value to the team by completing the myriad of reporting that the PMO will require. Leave them to manage the dross of low-value traditional reporting that waterfall requires.
Leave the agile data team to focussing on delivering value to the stakeholders as early as possible, and the Product Owner to manage expectations. That, after all, are their roles in an agile data way of working.
As part of the AgileData product we utilise “Information Products” as a way of quickly defining a list of things which require data to be collected, combined and consumed to assist the organisations decisions makers to make prioritisation decisions based on data.
An Information Product (IP) may result in a Dashboard, Report, Data Service or Analytical model being delivered.
Typically each Information Product can be defined in less than a 15 minutes via our AgileData storming process.
Once an initial list of IP’s have been identified, they need to be prioritised. We do this via an interactive workshop, where the key stakeholders determine which IP should be delivered 1st, 2nd, 3rd etc. This workshop is typically facilitated by the Product Owner (if you are leveraging Scrum techniques).
These prioritisation workshops, are what we believe is the new “Steering Committee” in a new AgileData way of working. Its key stakeholders deciding what is the highest value and therefore the highest priority of work to be done next is.