Learning prioritised: How we used 'Boot camps' for newly formed teams
To complement the dynamic reteaming approach used to restructure, we supported newly established teams with multi-day onboarding activities we called 'boot camps'. Here's what we did.
As I covered in this post, as CTO and CIO for Seek Asia, in collaboration with our CPO, led a restructure of the business, which saw the union of the product development capabilities of two previously job board businesses:
We used a dynamic reteaming approach described here by my ex-colleague Jane ( https://medium.com/@jane.freider/self-selection-with-distributed-teams-how-to-make-it-happen-af4d249772a4
and also partially described here by me :
As I covered in this post, we supported teams that were newly established using the dynamic reteaming approach with boot camps to support the formation of the team and establishing new norms:
For this post, I will expand on some of the elements we covered in the boot camps. The length of the boot camp would be anything from 3-5 days preceding the team starting regular sprints or cadences. I’ve generalised a bit as each ‘Boot camp’ was customised for each team formation but it gives you a flavour of the range of activities covered and their purpose.
Purpose and responsibilities
Part of the underlying design was to "reset" the relationships between team members and management. The teams were shifting from an environment quite hierarchically between levels and siloed between roles. For instance, product and engineering roles were not even based on the same building floor!
There was a deliberate effort to instil an awareness of what decisions they could make as a team and how to get support when they needed it.
The coaches provided help to the teams by arming them with skills and practices and facilitating workshops, which assisted the team in making sense of the direction, scope, and mission. Examples that they could apply themselves in the future as needed.
To this end, there were also micro-leadership workshops (ie "Who’s the lead then?") and workshop formats that helped explore roles & responsibilities similar to the one I described here:
Shaping the work
This might include helping the team build their backlog, teaching or facilitating sessions on story/journey mapping, and other approaches to breaking down work, challenges, problem spaces and solution spaces.
Depending on how greenfield the work was, it might have involved a design sprint or collaborative mapping of opportunities such as what I’ve described here:
Opportunity to learn and practice new concepts
As I posited in the post above, we theorised that part of the challenge of adopting new practices in a team is a timing issue. During the ordinary course of work, it is not always the case that everyone is ready to adopt a change simultaneously.
Whether or not the idea of forming, storming, norming and performing cycles is a thing or just a nice theory, it was enough for us to decide to test the hypothesis. We were very happy with the results after running and improving upon the approach to conducting these boot camps.
Mob programming
Coding Kata
C4 architecture diagrams: https://c4model.com/
Kanban & Lean games and simulations to learn key Lean and Queuing Theory concepts such as: https://www.agile42.com/en/agile-teams/kanban-pizza-game
Cloud and Serverless concepts
… and heaps more, whatever was most relevant to the teams mission.
Team identity
We have often seen the tribal behaviour of teams, and whilst, in the worst cases, these behaviours could contribute to silo behaviours, a shared identity can support unity and come together around a common purpose. Identity is a crucial part of this, so we decided to experiment with supporting teams with a budget to invest creatively in their team identity.
This could be for decorating their workspace, investing in branded swag with their team logo, etc. This often became a fast point of unity with the designers on the team as creative team names and logos quickly became decorated hoodies professionally printed, stickers and other gear the team would proudly display.
Agree ways of working
Not every team has the same ways of working. Most development teams adopted something like scrum or kanban as a starting point, with some other teams choosing even faster feedback methods such as a ChatOps style approach. Some teams were more operationally focused or specialised. For instance, there was a team focused on anti-scraping and other content protection strategies for which the approach and shape of work was quite different to the majority of other teams. The right way of working in the right context.
It helps to discuss and align this as a team at the beginning. We suggested teams start with what they had at least some expertise within the team on with an expectation of proactive effort to ensure everyone on the new team would be supported in gaining the concepts and practises related to the chosen way of working.
Design Sprints & engaging with customers/users
We would sometimes be in new territory, such as kicking off something completely new so that we might follow the boot camp with a week-long design sprint. These time investments are unimaginable in some companies where the rush to solve bias is intense.
We believed that the long-term average pace is the most important to optimise for, and as such, if a good foundation could lift your average pace higher, then it was a sound investment. You had to be willing to validate that because otherwise, you risk gold-plating versus making sound investments of time.
Riskiest Assumption smashing e.g. Proof-of-concepting, experimentation, problem solving
Teams might have some risky assumptions they identified in the early days of the bootcamp and commit time to tackling these head-on.
Mini-Hackathons
Individuals who had been in teams before the merger of the two organisations may have been in situations where change was infrequent, and practices had become stale and inefficient. Building relationships through some team level hackathons focused on things relevant to their mission was a good team-building activity which also demonstrated different ways of working and the impact of focus.
Goal-setting & refining purpose
Whilst the teams started with a purpose as part of the mission recruitment / dynamic reteaming approach we used, we by no means assumed it was perfect, and so time was often invested in refining the understanding of the mission and what success would look like, and what theories we had about the best ways to achieve it. This helped build more substantial ownership of the mission within the team.
Setting commitments (Principles, values, etc.)
Some teams (this was probably more a minority of teams) found it helpful to document commitments they had to each other about the values, principles, and behaviours they expected of each other and were willing to call each other out on should they be inconsistent.
At a minimum, most teams would document things like their Definition of Done.
Establish their Build Pipelines
It’s often most straightforward and fastest to establish a build pipeline for a greenfield system, so teams, if relevant or possible, might use some time in the boot camp or in a subsequent ‘Sprint Zero’ to establish build pipelines, standards and conventions for shipping their software through various environments and production.
Establish dashboards and alerting
Again, it may have been in the boot camp or a subsequent ‘Sprint Zero’, but teams would instrument what they could - even if, to begin with, no data was flowing through because no product or feature was live so that data could be visible as soon as it was available. Each home area of the office features information radiator screens where congregations of discussion often occur.
Coaching support
We invested in in-house coaching (in addition to regular investments in online learning and 3rd party training) on a range of disciplines, and these coaches also supported activities for the boot camps as well as general coaching of teams and individuals as needed. It worked on a model supporting people requesting help (with some principles inspired by the book ‘Helping’).
Agility - we had an overall coach and a ‘scrum master’ like role per domain (although we focused a lot on teaching teams to fish with their ceremonies and practices).
Quality & Test Automation - There was a significant need to shift from manual testing to incorporate more automation and upskill those interested in developing in this area. This led to manual testers building the confidence to do test automation and some shifted into pure software development roles. And, of course, software is a team sport, so developers were also part of the quality automation approach.
Product Management - Product Management is a broad range of disciplines relevant beyond just product roles and a structured curriculum was developed in-house in addition to 3rd party training.
Engineering - there were many new languages and engineering practices adopted from the legacy to new platforms and always something new to learn.
Data & Measurement - We aspired to be a learning organisation and had a champions programme of individuals who supported teams on uplifting their data practices.
Have you done something similar in your organisation? What was the most difficult part to establish? What challenges did you need to overcome? Share your experiences in the comments.