Structural changes, SCRUM, Kanban?
Can you be a scrum team without executing on anything?
So, for about a month now i have been attached as an agile coach to a data stewardship team.
Their product is a BI-tool with several different areas and they recently adopted SCRUM as a way of working (February 2022).
The weird thing is;
No one is actually developing on the platform within the team, they act as "key account managers" and stakeholder input gatheres, formulating these inputs and ideas into backlog items, these backlog items are more descriptions rather than actual developing tasks.
There is no crossfunctionality within the team, no one can take any work that was not introduced by that specific person.
There is no knowledge sharing, due to the fact that they all work in different areas within this BI-tool.
They spend up to 80% of their time not working on the actual product, but attending meetings, doing community work etc etc.
A typical backlog item could be a pure description of what a stakeholder would like, and their "Development" is the legwork, analysis and "scoping"
When a backlog item is "done" it is then pushed to a DevOps team, also working in SCRUM, who then actually executes on the demands by doing the needed developing frontend and backend.
So this is my question.
What structure could be better for this data stewardship team, other than scrum.
Currently it is wasted on them as i see it, this is also the feeling within the team.
I thought about a setup where the data stewards worked in a looser Kanban setting, a middle layer who can mitigate the input (PO and an architect) and then the DevOps team who can execute on the refined backlog items.
So, any thoughts? Suggestions?
There is so much more history, but it's hard to explain in text without the post being to long, as it already is :-)
Two thoughts.
- How is the Product Owner accounting for value, and to whom
- What does the "DevOps" team think of having supposedly Done work pushed onto them by others for actual completion?
Honestly, this team sounds like they are fulfilling the Product Owner role for the DevOps team. Given the siloed nature of the work, I don't see Scrum as being the right choice. Scrum works when the entire cross-functional team is able to self-organize to get work done. As you describe it, there isn't any work that can or is being done as a team.
If you could break down the work that the team does into a consistent workflow, you might be able to use a Kanban board to help visualize the work. But if each item requires a unique workflow, Kanban would be of no use either.
Not all work fits into an agile framework or methodology but there are some concepts that work no matter the kind of work. Making information available and transparent has never failed me or the people I work with. Trying to eliminate wasted effort is also something I always recommend as it saves time and money. Keep things simple. Complex processes never help anything. Involve stakeholders in the discovery process. In this case the DevOps team is a stakeholder so including them along the way will actually help them provide better solutions.
Since the work you describe seems to be different for each item and can only be done by a single individual, it might be best to have the individual doing the work to create a checklist. Old school I know but sometimes there isn't a need to improve.