Team Down Sized? What now?

Additional detail. The timeframe for having the new resource is unknown. 

Did you gain transparency over the reasons for turnover? Was the matter inspected in Sprint Retrospectives, and if so, were any measures taken to try and adapt?

Ian's point is good. If you haven't figured out why there was turnover that left you without a Scrum Master and down at least a few Developers, you could potentially be in a position to repeat that turnover with your new hires. Depending on how long it has been since they left and how much effort has been put into recruiting new team members, that could be signs of what needs to be corrected at an organizational level. Doing the right stuff to hire and retain members of the team is beneficial to both the team and the broader organization.

In the meantime, you're probably right that the Scrum framework as described in the Scrum Guide is too heavy at this point. It's designed to coordinate activities around a small number of Developers plus a Product Owner with coaching and facilitation from a Scrum Master - easily 4-5 people at the smallest size. With 2 people, you probably don't have the problems that Scrum is designed to solve.

I have mixed feelings about going to a just-in-time continuous flow approach. Not that I don't like a continuous flow, but I'd want to understand why you chose a cadence-based approach rather than a continuous flow approach in the first place. The structure and consistency can be useful for external stakeholders.

If you would be planning on going back to a cadence when you staff up the team again, I'd almost want to stay in the cadence and look at how you can lighten the events. Perhaps you can do more continuous refinement and planning while leaving an opportunity to review the product and reflect on your processes on a cadence. That is, hold something like a Sprint Review and Sprint Retrospective on the normal cadence while taking a just-in-time approach to refinement and planning.

If you think it could be a strong desire to go to a continuous-flow model after the team is fully staffed again, then perhaps making the change now would be less painful. You can build your tools and way of working around the continuous flow and continue to make more minor adjustments as new people join the team.

Regardless of your decision, maintain the Product Backlog and the Sprint Backlog (or, if you go into a continuous-flow model, some more detailed/technical task board). Ensure the Product Backlog is visible to external stakeholders, and they can understand what it's communicating. Keep the Sprint Backlog or task board up-to-date and visible to the appropriate stakeholders, too. Communicate often, especially about risks and impediments.

@Ian - This person left for a more senior role in a sister company. We knew it was coming, and we could have been more proactive, but the role has proven difficult to backfill. 

 

@Thomas - We went with a cadence-based approach simply because we felt it would help to establish a rhythm, and it did. I like the idea of just-in-time planning and refinement. Question about the sprint review, though: the increment we're now working on only "matters" to a minimal subset of stakeholders despite its broader business value. Should we hold a review with that subset of stakeholders to inspect and collaborate? Or should we maintain cadence with the global set of stakeholders?

We've even considered a more continuous flow-based approach (for now, and yes I know this isn't scrum). 

Nothing in Scrum precludes delivering every PBI as soon as it is "done."

- use what works

- get back to a viable team

- from there get to a sustainable team

- is it viable to attempt to maintain a development/release cadence rather than a maintenance cadence with the team size you have? Only your team can answer that. Maybe with the team at the degraded strength it is at, "staying in touch with customers and returning to workable team size" is the extent of a viable goal for the time being?

Communication and transparency should be pretty easy between the two of you.  My concern will be to external entities.  With any kind of situation of this kind, the company would be negligent if they didn't look at the continued need for the team.  And the "unknown" timeline for backfilling gives some indication of the company's perception of the team.  So everything that you can do to make the work you continue doing visible external to the team is going to be important.  I would recommend that you continue anything that provided external visibility so that everyone can see you are still working as productive as possible given the circumstances. I would query your stakeholders ( include management in that list for now) to see if they feel there is anything missing in your transparency.  The Product Owner should be working VERY closely with stakeholders now to identify the right things to do for the product in order to provide the most value you can. 

On the continuous flow topic, Kanban would not be a bad idea.  Especially if you took the approach of using Kanban with Scrum (https://www.scrum.org/resources/suggested-reading-professional-scrum-ka…) because this could still be applied when/if your team starts to grow.  It still provides the cadence of Scrum, the benefit of the events and artifacts while providing you a more flow based way to work.  You may even consider expanding your Scrum board to include activities that are inclusive of the Product Owner's activities to provide more visibility.

With just 2 people the Scrum events are a bit heavy.  So adapt them as needed but don't abandon them.  As your team grows you can start to return to the events as you know them today with the new team adapting them as your team grows.  Just because you had a team that did things well doesn't mean that your new team would do them well with the same process.  Take this as an opportunity to inspect and adapt continuously.  Being agile doesn't apply only to the way you behave when building software.  It also applies to the way your behave when building a team.

@Daniel - This is helpful advice. We've shifted our review into a just-in-time model with a subset of stakeholders. Still, to your point, you're missing the "collaborate on what to do next component," which oddly enough has not been adopted culturally ("why should I attend a review if part of it doesn't matter to me") mindset. It's also harder to wrangle stakeholders in isolation. 

In your experience, are there any PO activities for starters that are helpful to visualize? I'll review them with the team.

. 

Daniel - One other detail. We now have a timeline for 2 developers, but it's not for at least a month or two. So I think the team perception is still green. 

The news about the developers is a good thing. 



As for the "PO activities" I'd suggest it doesn't have to be just the PO.  The developer on the team can do a lot to make their work apparent to other developers.  For example, with only one developer on the team they should reach out and ask developers from other teams to do code reviews.  While these other developers might not have direct interest into the work being done, they will probably start asking questions about it.  News travels around about things that are interesting. 

PO should talk to other POs.  Look for opportunities to collaborate on delivering functionality or use them for peer reviews similar to a code review.  

As much as everyone complains, status updates and emails are useful.  When the team delivers something put out a short "notice" to a wide group of potentially and definitely interested people.  Never miss an opportunity to publicize something that was done.  By the same token, request input from the same people in the same way.  Train them to look in one place for interesting information and take advantage of the "push" capability of email to get things in front of others.  Slack (or similar products) can be useful for this as well.  Create a channel (in Slack terms) for the stakeholders.  Both the Developer and PO can post there frequently.  Ask questions, share a screenshot of something.  Just make sure that people outside the team are being included.  The more you do that the more likely it is that they will start to take advantage of it.   And share things such as the news that the team has been approved to add 2 new developers in the near future.  Let them know now that there is a future for the team.

Very helpful! Thanks, Daniel.