There’s a lot written on the subject and today we can get good insights through LLM, if we know the question to ask. Below is a way of creating the possibilities for great development teams to emerge that I’ve just successfully many times, and with successful I mean that we where able to create a good start for the team that the participants found valuable.
Set up the Team
Sometimes we run into those teams that seems to manage anything, they analyse, deliver and adjust continuously, decision making works smooth and everyone seems to have a role to play, if that is not enough, they also do it with a smile. Sometimes this happens by chance and sometimes by deliberate and thoughtful design and intervention. Let’s look at the preconditions that makes it possible for such teams to emerge.
We need to find a product area or assignment that has a longer intent and is clear enough to gather people around a common goal. It doesn’t have to be fully analysed but there needs to be a direction, a perceived user need and a first hypothesis about what competence that is needed. With that in place we can put together a small crossfunctional team with as high degree of dedication of their time to the team as possible. The team then refine and clarify the understanding of the product by developing it.
Typically the initial steps are made by a small group, 2-3 persons that starts framing the product, drafting an initial product vision, finding the initial users and their needs, perhaps giving it an initial name and coming up with the competence need.
Kick starting the team
How do we get a good and fast start for the team? We got a lot of unknowns in front of us and want to start learning as fast as possible.
We all come from different background and experiences of how to work efficiently and there might be more or less buy in to take an empirical approach moving forward. Thus I find it well invested time to spend the first day to go back to basics and align our language and knowledge around foundations of empirical approaches, team work and perhaps Scrum in it’s simplest form.
Second day we turn to the more team specific topics, introducing the team to the product, run start brainstorming of potential sprint goals, refining the backlog and creating team agreements.
Then jumping straight into sprint planning an the discovery journey begins.
Two key words for success is collaboration and co-creation. Let’s take the Team Mission as an example. It is reasonable that the team gets presented to an initial draft of the Team Mission, after all it is the organisation that has decided to invest in this but the team needs to make it their own inorder to take ownership of it. Therefor, present the draft to the team and let them discuss what they like and what they dislike and then incorporate their ideas into a new initial Team Mission statement that they have been able to impact, this builds ownership and buy in. Showing up with a pre-baked idea to start from might work, it depends on the level of trust and collaboration you’ve currently got. Co-creation builds ownership and engagement, the process might be perceived as a bit slower but pays off the long run.
And no, not everything is suitable for co-creation, sometimes we just need to act to stabilise a situation and there’s no time to debate, but that’s not the case in this situation.
A few words to the ones that feels this is a bit too fast; We’ve identified a product to develop and we’ve decided to invest in it by forming a team around it so we likely see it as important. At this stage we don’t know that much, we just have a bunch of assumptions, that users will like and use the product, that we’re able to build it as a team, that we can technically build it and that it will scale. Those are all complex questions and the fastest way to answer them is to build our way through, pen an paper will keep them as assumptions. So we need to put something in the hands of the users as fast as possible and then start inspect and adapt.