Today the problems we solve in our development organizations are so complex that there is not a single person that knows the right solution. Most likely there is not even a right solution but several options. Today's tech needs to build an organization that encourages collaborative thinking, builds teams and allows for iterations. This is true even if you build motorbikes.
Credit: Petra Färm
Before CAKE changed to a team based setup, product development was run through projects with assigned resources from the different disciplines: electronics, mechanics, design and software. In addition there were shared resources such as a homologation expert and prototype builder. These were not assigned to a project but had to navigate themselves or rely on the manager for guidance.
There were challenges with the setup, maintenance, support and continuous improvements were not dealt with in a proactive and consistent manner.
Some resources were assigned to multiple projects without any guidance on how to balance. In most cases less important projects, support and continuous improvements were simply starved.
There was very little visibility on the projects for people not working in them. Also very difficult for stakeholders to discuss and agree on the joint planning for several projects. Neither visualizations nor forums were available to facilitate discussions.
Team design
Team design is an art in itself and there are many things to consider such as organizational structure, ability to contribute to the team, interfaces. The thinking here is a combination of “Reinventing organizations”, “Team topologies” and personal learnings from various industries but always HW and SW development.
The main factors consider when setting up the teams at CAKE:
Only R&D resources in the teams (Electronics, mechanics, design, software and experts)
Time horizons in the work, design spending a majority of their time in concept phase
The ability to contribute to the team work has to be high else you will not be included (no opiners)
Current challenges such as the many interfaces and entry points to R&D resources, there was a lot of “who screams loudest get there thing first”
Things that worked well, Design was at the time already a well functioning team. No need to mess with that.
The “Head of..” is not a management position and no one is reporting to the Head. Responsibilities included in the Head role (depends on the area):
Consistency and reuse cross platforms
Scalable, maintainable architecture
Quality
Brand and design language
Approvals, formal documentation, processes, etc.
Extremely important with the team setup is that the only way into a team is through the team lead. You cannot email, slack or call team members directly to get your thing in, you have to go through the team lead. This will not only provide the team with the required peace and quiet to work but also make it possible to deliver in a predictable way.
Way-of-Working
Factors that were considered when forming the new way of working:
Enable decisions to be made at the right level, meaning that the there has to be a solid base for decision making available
The majority of the decisions should be at team level, the others are guidance and knowledge for the team to take the right decisions
The right people in the right forums (no passive audience unless the forum is for information sharing)
Visualization is key
Transparency between the different decision forums
Minimize the number of interfaces any team has
According to the book "Team topologies" the cognitive load on teams and individuals in today's development organizations is extreme. The number of relationships a human being can manage is limited and therefore it is vital to consider how tasks are shared with a team. Who has access to the team? Who need to? How can we share information between parts of the organizations without adding interfaces?
The picture gives a simplified view on the stakeholders, forums and planning that formed the R&D way-of-working.
Each forum used a document or tool where information, decisions, and planning was visualized. This is according to research on the importance of "Boundary objects" when facilitating multidisciplinary discussions.
Commercial milestones and status
Commercial planning
The commercial planning including sales and marketing was done together with the business owners. Here the following types of items where shared and discussed:
Marketing events
First customer deliveries and customer communication
Critical R&D delivers that might impact the timeline -> joint risk management for customer communication and planning of marketing events
Scope outs/ins" - what can we remove to deliver sooner? What needs to go in and how will it impact cost and/or timeline?
R&D planning and allocation
The R&D planning was done together in R&D, always starting at the pie-chart level with how the available development time should be distributed across the various areas to make sure no area was continuously starved.
Projects are run both for customers as well as part of the Product Dev & Concept. R&D had one project manager, who both ran one of the big development projects and acted as team lead för the mechanics and electronics team. There were also project managers in other parts of the organization. A requirement for the project managers is to provide a time plan with milestones, release drops etc in it so that each sprint will have the right content to be able to deliver on time.
Weekly sprints
The weekly sprint is the core of development. This is where the execution happens and where most decisions should be made. It is important that the team members have enough knowledge and guidance to know what to do and how. It is equally important that they can work in peace and do not have to manage on-the-side things and interruptions.
There must be a confident gate keeper of the team, the team leader.
1 week sprints
Planning on Mondays, stand-up Wednesdays, sprint close Friday. Only for team members, team lead and eventual dedicated contributor for that sprint. Backlog refinement Friday: team leads and stakeholders/contributors, e.g. project managers.
Learnings
Communication and alignment is key but it is tough to find the right level to discuss with the right people. Meetings are toxic according to "Rework" and it is important to time-box them, always have a clear agenda and outcome. There needs to be trust between the team and its stakeholders, that all will do the job with the best intent and purpose.
There are more than one way to design a team. It could/should perhaps even be that as an organization you do change the team design now and then. Perhaps bring in marketing to create a launch team, or operations for a quality focused team, or...
Reading List
Reinventing organizations by Frederic Laloux Team topologies by Manuel Pais, Matthew Skelton “Boundary objects” - The Right Fidelity: Representations That Speed Up Innovation Processes by Guido Stompff, Frido Smulders Rework by Jason Fried, David Heinemeier Hansson
Commercial milestones and status
