Introduction
Last blog I wrote about how we coached and supported the management group to identify next steps in their agile transformation. One of the actions was to change the teams to become Feature teams. Teams who have all needed competences to deliver end customer value. This blog I will describe how I facilitated the Feature team self selection workshop.
Overall agenda for the workshop
Each step of the workshop is described in a few more words under each heading in the blogpost. I described the overall workshop process with a flip chart that you can see below to make the workshop process easy to understand for all participants.
- Presentation of Self selection boundaries
- Product Owner present example deliveries from the backlog
- All prepare their own “avatar” with skills
- Collaboration and self selection
- Each new team validate towards boundaries
- Each team identify concerns with their team setup
- Repeat 4-7 until we reach our goal “Good enough for now, Safe enough to try”
- Short retrospective
Presentation of Self Selection boundaries
We had a few rules to guide them in their self selection and collaboration efforts to identify Feature teams.;
- Do what is best for the company
- Go for teams that is close to equal in size, experience and competence
- We want self managing teams able to deliver on the example backlog items
- We want teams who learn how to collaborate and share knowledge to develop as a team over time
Product Owner present example deliveries in the backlog
Directly after the previous workshop I mentioned in the beginning of this blogpost we worked with their backlog to enhance the value delivery focus and moved towards a backlog with more focus on their product and value deliveries. So we merged each team backlogs to one common backlog. The company have a few different types of deliveries in their backlog. To give all participants a reminder that the new teams in the future should be able to pull any delivery depending on priority we wanted to give examples from each category. The Product Owner presented the different types and one or two real examples from each type.
In their case following are the types of planable deliveries they have;
- customer installations
- New Product Release deliveries
- Planable support issues
Product Release deliveries could be from any area in their big product, so it involves different implementation solutions. Since it is a wide product also domain knowledge is an important factor to consider in the new team setup.
All prepare their avatar with skills
I had prepared a table with a small picture of themselves and stickies with competence symbols as “Scrum Master”, “Java”, “Test”, “UX”, … and their taks was to pick their primary skill what they usually contribute most with in their team. And if they also had a secondary skill they contribute with they could also pick this.
You can see an example (my picture) on the overall process description flip chart (beginning of the blog post) I used to describe the setup in the room.
When this was done I also showed them one validation skill checklist. Basic list of the different competences we usually involving in the different deliveries and the same as the different competence stickies that was on the table.
Collaboration and self selection
Now it was time to have good discussions and collaborations to select their team. They could select team by setting up their
avatar on an empty team flipchart in the room.
I put up a digital clock on the projector for 10 minutes discussion and selection, reminding them of the self selection boundaries and examples from their common backlog they just had heard about.
Each new team validate towards boundaries
When the timer alarm screamed all could evaluate their new team towards the self selection boundaries (see above) and the
team skills checklist to validate if they had any concerns with their new team.
If they didnt have any clear concerns they could consider their team to be “Good enough for now, safe enough to try”.
Each team identify concerns with their team setup
If they had some concerns they got 5 minutes to discuss this and present for others to make it transparent what they would need to get a team fit for “Good enough for now, safe enough to try”.
In the first round they discussed the need to get more domain knowledge within one area of their product but also a concern regarding level of experience when it came to Java developers compared with different teams.
Repeat 4-7 until we reach our goal “Good enough for now, Safe enough to try”
I started the timer and visualized it with the projector again. They discussed their different team challenges and how to change team setup in best way and some people changed teams to solve the identified concerns.
We still had some smaller issues after this round but after third round they felt the teams had a good balance taking the boundaries and skills into consideration.
Short retrospective
They all felt that the teams they created was good and they felt happy about them. And the feedback they had was that they immediately felt very committed to the first team drafts and it was emotional difficult to leave their new friends even if there were some concerns with the team. They didnt want to leave their friends, they rather wanted an after work with them! 🙂
With this feedback in mind, next time I will make it possible to run parallell experiments to keep the options open to avoid having only first draft teams that is emotional difficult to change and just minimal changes is done. Maybe we missed great options that was never discovered due to only one option was created in the beginning.
Coming steps?
Back to our Agile transformation, In the first blog I told you about the setup to create common goals and decision to experiment with Feature teams and using LeSS as guiding framework. After this self selection workshop we have our Feature teams. Still we had a few questionmarks in front of us. How would we setup efficient product ownership, backlog refinement and sprintplanning with Feature teams? How can we foster self management and becoming a learning organisation when spread in different teams?
More blog posts around our steps adapting LeSS into our reality will come later.
