5 min read
this post is based on the less framework website less.works
So working in a team and using scrum mastery, the team has grown, initially the team was 9 people (making it big enough for a normal scrum team, however then it suddenly ballooned to 12. My initial way was to pair program the team, this meant that we ended up with 4 groups of 3(in this instance it worked. The aim of the project was a training exercise to allow staff to up-skill and learn some code at the same time, so this worked. It also allowed staff to work on their own AWS/Azure courses(which was allowed at the time). This was only supposed to be for a few days before moving onto other teams, so we took this on board and began to work with staff(however you may disagree with that, it misses the point of this post)
The team then grew to a size of 16, just prior to the end of the sprint. I was approached by another scrum master who suggested using a LESS framework. LESS is a framework that allows multiple teams to work on a single project. As this is an agile scrum method, of course there are differences to how teams choose to engage with the work, but it seems to be working.
Two Planning Sessions
This is the first element of less, there are 2 planning sessions within the day, the first is a joint session with the whole team(or their representatives) to select the items for the next sprint. This should take an hour in order to pick the items, clarify their intent and then move onto sprint planning session 2. In this, the teams work in their small groups to refine the stories into smaller more granular pieces in order to make each part of this achievable for the development team and show momentum in the development of products, as well as identify order and structure of planning, design and testing. - this I think will help in the weeks to come, but also need to make sure that the story points are clarified continually throughout the sprint and more granular tasks added regularly in order to keep pace and the level of commits up.
the aim of two retros is for each team to have their own separate retro, then have a joint retro in which representitives from each team discuss their retro. it's strange because the two teams are still one larger team, so doing it this way allows both teams to understand where the other is at with regards performance and pick a goal that both agree on on to work towards in the sprint.
I'm still learning how to write the perfect retro, and at the moment i'm still looking at different ways of doing this. I'm also hired initially as a software dev, so trying to keep the skills sharp whilst learning the scrum mastery element is also tricky. if you have any idea how to do the two together, let me know.
Our aim in this sprint, with two teams is to aim to “review and commit” regularly, in order to make sure that code quality stays high, but also commits are regular to keep the transparency between the teams.
I need to read more in this and how to best achieve it.
There is also the need for SAFe agile practices too which I am reading up on constantly to try and gain an understanding.
Balancing both scrum mastery and Software Dev-ving is impossible for me at the moment, i think i fall back on the old mantra, do one thing and do it well. I'll have to leave Dev learning while i learn the scrum mastery thing...then move on...