Scrum team in need of actual scrum
Hi everyone,
I am rather desperate and not sure what to do. I have been working with a team for 1 year now and I still have no clue how to improve the situation. I will try to be brief as possible.
- ETL/SQL DEV
- ETL/SQL DEV
- Business Analyst, Kobol dev, System Admin
- Python Dev für GEO insurance (50%)
- BO developer (currently vacant, partially filled by BA to keep ops running)
- PO
- SM
- Team used to be 9 people, 2 of which had to be removed as they did too much legacy work and also were very disruptive given their personality.
Context:
DevOps team.
Business Analyst does 50% of work outside the team (data analysis, service, system admin) and some development/operations on SAP-BO
Both SQL devs build data marts & individual tables/views for dashboards but also other teams (GEO team)
Python Dev mostly works for another team, does some python analysis using the datamarts built by the SQL devs
‘Products’
Several SAP-BO Dashboards & other BI intelligence
Mostly Ops, some Dev of the SAP-BO Dashboards
Inherited Ops from outside the team (monthly reports etc, this costs the BA 50-60% of his time)
Problems:
We have too much operations, little development.
We have no vision – because we are not a team, but a group of individuals.
We have no sprint goal – because everybody has their own tasks to do.
We have no actual products besides the dashboards and the datamarts – but no one defining feature/product.
Nobody likes doing scrum, but has to go with it because the insurance company chose it.
The people have to do tasks relating to business analysis (BA) or SQL tasks (SQL devs) with little or no overlap with each other.
So we basically don’t have a team, we have 4 individuals in group with a team name, from time to time some hand-offs, but not more.
Our customers mostly needs some datamarts, or ask us to enhance existing dashboards with some new reporting figures - but this is hardly innovation - just execution.
The existing and planned dashboards have value and they need to be done, but there is no innovation, mostly just a backlog of ‘features’ that we are supposed to develop – individually most of the time with little overlap.
Scrum-wise we don’t estimate stories together, there is no actual exchange or challenging of ideas, stories are just cut from existing features/epics which are handed down from product managers to the team, sometimes in co-operation with the team (but not the stereotypical scrum idea of a cross-functional team interacting with customers to write stories together in find out what solution to develop).
What can we do?
I am trying to refine the idea of a product & product vision & team vision, but it has been going very badly. Because what we have been doing, what applications we own and what we are asked to do by the company makes us more like a group of individuals that just deliver was is asked rather than an actual scrum team that delivers innovative solutions to customers problems.
I also now trying to fully understand why we have basically overlap in tasks and where we could get some, but so far the argument is always: There is little overlap in work, so there is no point in forcing cooperation, writing or estimating stories because its just useless overhead. Stories have little content at all, it only is done because it needs to be done and that it acts as a reminder on the board what to do.
Nobody likes doing scrum, but has to go with it because the insurance company chose it.
How have company leadership communicated their expectations, in terms of the different outcomes they wish to see achieved?
The Scrum framework is not a fit for every situation or team. The group of people you have sounds more like support than development. Kanban would probably be a better solution for you. Is your IT support expected to "do Scrum"? If not, you should make the case that your work is not typical software development and more software support.
I do like @Ian's question. If the "company chose it" then have the "company" provide the expectations and benefits that they feel would be realized.
Hi everyone and thank you for your input!
The company chose SAFe for reasons not known to me. Probably because like many other companies, they want to be more agile without really leaving waterfall.
I don't know how the expectations were communicated, but I don't think it matters for the team unless I make the case that they would have to abide by it if they want to stay with the company. Because they don't care about theory. And they are not entirely wrong. If epics are written mostly without them, and cutting the epic into stories when nobody will read the stories but them, why would they use it? When I use the argument of better transparency, of better structuring the work and minimising surprises in face of complexity, I don't get any followers.
The team is not typical software engineering indeed, but Scrum is applied also to other teams. For me the issue is more what of Scrum can I actually use to improve the team and what makes no sense given the circumstances.
Just using KanBan is out of the question as the company demands Scrum to be used.
For me I think the most oppressing question is:
How can we structure the work, interact with stakeholders and use stories effectively when I have a team with currently little overlap, a mostly top down safe environment and people who don't see the value of stories above and beyond reminders to do work?
Any ideas on how to approach it? What would you do?
I'd fall back on the Scrum Values of Commitment, Focus, Respect, Openness and Courage. These are the professional underpinnings of Scrum and a necessary foundation for Scrum to be implemented at all.
We fall back on these basics when implementing Scrum proves hard. For example, if I could achieve a little bit of openness where senior leadership recognize "we aren't implementing Scrum. We thought we were, but now we realize we aren't, and now we see the gap we must navigate towards agile practice", then that's a win.
@Ian's wisdom is better than anything I could say.
I will point out that SAFe does not use Scrum as defined by the Scrum Guide. They use a variation that they call ScrumXP. The rules of engagement are fairly clearly defined for ScrumXP so you may want to improve your knowledge of it. It may help you with when working with your team and others in the organization.
We fall back on these basics when implementing Scrum proves hard. For example, if I could achieve a little bit of openness where senior leadership recognize "we aren't implementing Scrum. We thought we were, but now we realize we aren't, and now we see the gap we must navigate towards agile practice", then that's a win.
Loved this.