Skip to main content

Where to start when there's too much to do

Last post 01:29 pm December 5, 2019 by Ebony Ramey
11 replies
05:34 pm November 25, 2019

Hi everyone,

I recently started as a SM in a young company with a pretty big Scrum team. We're currently 13 people (1 UX designer, 1 UI designer, 5 FE devs, 3 BE devs, 1 QA, 1 PO and 1 SM). The size of the team is already quite inconvenient, nothing new, but there's something that's been bugging me more than that. 

At the moment there are 2 sub teams: Product (formed by the 2 designers, the PO and the QA with the CPO as manager) and IT (formed by the developers and the SM reporting to the CTO).

Even though we are supposed to be an "Agile team", there seems to be a really big split between this two sub-divisions. Things I've noticed are:

  • The "Product" team is way ahead of the "IT" one. While we're working on feature X on the current sprint, they're working on things that are planned to be picked by the IT side in half a year.

     
  • Product and IT have a different set of OKRs, not related to each other.

     
  • The Product side doesn't work on building the increment during the sprint and they're mostly observing. Sometimes they help with testing, but still feels like they're not part of the sprint itself, they're just "supporting".

     
  • The IT side feels like they have no real saying on what gets build. Product has sessions to gather feedback from IT, but they're so ahead of time that it's really hard for them to be actually involved and, by the time they get to work on those features, the details are set because Product already had several design iterations over them and they're preparing the next stuff.

On the good side, both "sub-teams" really wanna work together and see the necessity of having a cross-functional team working together. And after talking to the CTO he also seems aware of the situation and wants to make a change.

On the not-so-good side, these things have created a bit of a tense environment in the team that manifests in people being on edge during meetings or just tired of not seeing any change. Also, management doesn't wanna make any big changes until next year because a tight deadline we need to meet by the end of this quarter, but even with that I'm a bit skeptical of them being completely supportive (except for the CTO).

 

I feel like, even if we don't wanna make any drastic changes yet, we should come up with a plan of how we'll tackle this situation in the upcoming year. But I'm not sure how to bring this up nor what steps we could take. Of course we can't just say "designers should stop for the next 6 months so the engineers can catch up".

Do you have any suggestions on this? Sources I could use, anything would be extremely welcome as I don't have much experience with such a big transition. 

 

Thanks in advance! I hope I made myself understood :)


07:40 pm November 25, 2019

I recently started as a SM in a young company with a pretty big Scrum team

Why do you believe that the grouping you have described is a Scrum Team?


08:51 pm November 25, 2019

Thanks for the reply.

I can elaborate a bit more on the Scrum team thing.

From the company’s perspective, we are a Scrum team, that’s what I meant and that’s why they hired a Scrum master. From my perspective, we are an aspiring Scrum team.

I wouldn’t want to get caught in semantics though. My goal is not specifically to build a Scrum team but an Agile team. If Scrum is the framework we should use it’s something we’ll need to test.

But I think at the moment our main problems are related to the core values of Agile (and Scrum too) for the reasons I explained above.

I’m sorry if using the term “Scrum team” created some confusion, hope I helped clarifying.


04:42 am November 27, 2019

The "Sub Team" adds another layer within your Scrum Team. I think you need to have a smaller scrum team (probably discuss with you manager or coach on splitting them into 2 or more teams). After you the split, have the discussion on sprint goals, DoDs, scrum ceremonies and alignment of why these things are there.

Regarding the observations you mentioned, are these raised or discussed during retrospective meetings? What are the action plans for it? I think these sub-teams have different perspective of how work is done and they are assuming that the other sub team knows it.

 


10:18 am November 27, 2019

Thanks Sherwin!

Regarding the observations you mentioned, are these raised or discussed during retrospective meetings? What are the action plans for it? I think these sub-teams have different perspective of how work is done and they are assuming that the other sub team knows it.

Both sub-teams are aware of it and wanna make the change - we talked about this during retro, they've discussed it with their manager... We have a few action items to do refinement sessions all together, improve the way we split the tickets, do more incremental development... And then we have the big goal of "we wanna work together and everyone to be involved in every step of the process".

So the sub-teams are aligned on what they wanna achieve but we need management support for this and that's what I'm struggling mostly with. I talked to my manager (IT) and he understands and agrees we need a team split and alignment between Product and IT. But we're not allowed to make any "drastic change" before the end of the year because they (management) are afraid this will prevent us from delivering on a really tight deadline we currently have.

I can understand this but I think we should start thinking on how we wanna tackle things afterwards. I'm not sure how to bring this up to management, I feel I need some sort of plan beforehand... But now I'm thinking maybe I'm doing this wrong and I should just talk to them openly and start working from there. Do yo have any tips? Should I discuss this with management right away or create some sort of plan in advance? Should I involve the team at this stage or should we keep focusing on smaller action points?


02:36 pm November 27, 2019

What's the level of trust within this group of people? If you want to make change, it's good to know into what degree they trust each other.


09:39 am November 28, 2019

What's the level of trust within this group of people? If you want to make change, it's good to know into what degree they trust each other.

Great question! At the moment it's rather low. Some engineers don't trust each other, the "Product sub-subteam" doesn't really trust the IT one in achieving the sprint goals, the company itself is not really confident on the agile team either.

This is due to a year of struggle and missed deadlines. The IT team started a refactoring project that was horribly managed, at some point they decided to dumped their "Scrum process" and just "get it done" which lead to a period of (even more) disconnection between IT and Product. To add even more, this project is taking 3 times as expected and it's interfering with other deadlines putting other goals in a big risk which has lead to everyone being on edge as mistrustful.

I think we need to find a way to gain that trust back and I believe the best to do so is by slowly showing that we can work together and be successful. I'm just not sure what to start with :) 



It's hard to explain everything on a post, let me know if you have further questions! 

 


08:54 am November 29, 2019

I have a million questions, but I can see where your original question comes from. Now I'd say this is a great opportunity to collaboratively discuss what happend that has caused the missed deadlines and how to minimize this in the future. I think this is a great opportunity as a Scrum Master to help the entire organization adopt Scrum and how to interact with the Scrum Team to get to a good result together. The way you are describing the situation kinda gives me the feeling that it's a bit us (Scrum Team) versus them (organization). 


10:20 am November 29, 2019

@Sander Dur I totally understand. I'm trying to clarify as much as a I can but it's hard to do with this format.

Thank you for the advice I think you're completely right. I was a bit scared of putting everyone together but after the comments on the forum and if we're gonna be a real scrum team we need to be able to discuss these kind of things and I should be the first one to embrace its values. Courage and Openness, right? :)

I'll organize some sessions so we can share our hopes, concerns, experiences and expectations and see how we can move forward together.


01:13 pm November 29, 2019

Courage and Openness, right? :)

Love this!

Please let us know how it went! 


02:56 pm December 2, 2019

Hi everyone,

Some updates on the topic. As I mentioned my next move was gonna be to discuss with the parties involved how we could move forward, and so I did.

Just today we had a talk and took, in my opinion, an important step forward: acknowledge there's a problem and agree we will solve it together. Might sound small, but I think this shows we have the mentality and the will to initiate a change, which is key for what's yet to come!

Due to the current circumstances we compromised on waiting until the beginning of next year to take further steps. This means, starting next year, we'll be redefining ourselves as a team, what we wanna do, what we wanna be... all with Agility (and Scrum) as the base.

Personally I am really excited about this and relieved I clarified everything with everyone. Some learnings so far: stick with the Scrum values, they're there for a reason. That's what made me realize my approach wasn't the best and I should be more open with the people in the organization.

Thanks everyone that helped me on the forum! Let's see how things go from here, we've got a long journey to go :)


01:21 pm December 5, 2019

This was an amazing read and helped clarify some things for me. Courage and Openess!! Thank you.


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.