Effects of team members leaving and joining a Scrum Team

Proper spring weather had just kicked in few days ago where I am, this week my focus will be moving from artefact or events in scrum framework management to role such as development team which means as a scrum master willing to stay on for the long term with an organization even when the team can self-managed that they may not necessarily need a dedicated Scrum Master, my discussion is targeted around managing team member leaving especially when a new project just started and you've mapped out like five sprints upward but one or two members decide to move on for another opportunity.

As an experienced Scrum Master, I believe HR has a key role to play in the Agile world making sure they themselves are agile enough to know a potential candidate has all the necessary prerequisites of filling a role of an Agile software developer If for example an HR is only focused on getting an experienced developer even though he had no previous Agile experience which can in the early time be a pain for the team but a well Agile enthusiastic developer joining a team that's already on Quadrant R4 on the situational mental maturity model.

Also, I believe a very well experienced cross-functional won't even blink for a seconds if someone n the team decides to leave and will only reduce the number of stories they carry into the sprint which will, in turn, reduce the team velocity and will eventually pick up when someone else with Agile experience joins the team.

I am not a fan of running the lowest suggest number size of the development team as suggested by Scrum guide to be 3, my reasons are quite valid and have been talked about by many Agile experts, having a team of three cause nothing but instability because for example only one tester will be needed in that team and even though the team tend to be cross-functional, what will happen if the tester is sick or have to go on a long holiday and a sprint cycle to just started ? Will the team be held to ransom? So all these make up my argument that a Scrum team of 5 development member will crumble in no time and will cease to exist after a few sprints.

I will be leaving it here today being Friday and load of work to do this weekend in the garden in preparation for summer.

Comments

Post a Comment

Popular posts from this blog

Informal discussions with Agile team members

This week I'll be writing on why I believe informal discussion could foster the relationship between an Agile Coach, Team members, Scrum Master and the organization in a whole. I took a look down the memory lane and I noticed all the places I've worked even before my Agile Adventures, informal discussions have helped me to built bridges from the higher senior management to the junior staffs because most of these discussions started either in the dining room or hallway as a brief chat in which most of them got escalated to a more in-depth talk and 8 in 10 was successful. I realized the best way to get people attention is when at the moment of triggering a conversation they are occupied with something other than work then they'll flow, a good example is a developer will be more than happy to take a Gemba walk with you down the street to talk through some pain he's going through in gathering investigation into a story or task but won't be too keen to talk while sitt...
Read more

Benefits of having a full-time Product Owner

Having worked with different development teams from teams with little to no knowledge of business value to teams with vast knowledge in working out the business values themselves without having to regularly consults with the product owner in pointing them towards the right direction in making sure software deliveries go hand in hand with securing business values alongside the development. Commonly in the Agile world, many organization tends to have someone from the Management or Director level take charge of the product owner role alongside their official title. i.e a technical director still acting as a product owner or a Solution Architect whose role should be just technically inclined and not interact with clients who are the primary users of the software being developed by the team. Listed below are the reasons why having a full-time product owner always work in favour of the team. The full flow of communications  Commitment  Attention to details D...
Read more