Skip to main content

Scrum team in need of actual scrum

Last post 05:19 am August 10, 2022 by vishal Rajadhyaksha
6 replies
07:32 am August 5, 2022

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.

 

  1. ETL/SQL DEV
  2. ETL/SQL DEV
  3. Business Analyst, Kobol dev, System Admin
  4. Python Dev für GEO insurance (50%)
  5. BO developer (currently vacant, partially filled by BA to keep ops running)
  6. PO
  7. SM
    1. 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.


05:22 pm August 5, 2022

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?


05:32 pm August 5, 2022

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.  


07:04 am August 9, 2022

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?


05:43 pm August 9, 2022

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.


10:14 pm August 9, 2022

@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. 


05:19 am August 10, 2022

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.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.