“If you want to go quickly, go alone. If you want to go far, go together.” – African proverb

Teams are at the heart of development. Teams make all the difference. A well running team has happy engaged people and produces results. A dysfunctional team has miserable and disengaged people and can do more harm than good. Doing rapid responsive development requires a lot from a team. Not just doing it, but also learning how to do it. And doing it with hardware and all its challenges, it requires even more.

High performing teams

Characteristics

Rapid and responsive development is about high performing teams. And high performing teams are all about people, leadership, goals & results, and organization & support. See the image below for details on what that means. 

Boost team performance

The following 10 aspects help you boost team performance (based on “11 ways to double velocity” by Jeff Sutherland)

1. Team morale – Happy people produce more. Appreciation and a stimulating environment do wonders. Respect people for what they do, give them what they need and trust them to get the job done and be proud of it. Lead by example. Provide purpose, time and means to learn, grow, work on some fun stuff as well and blow of some steam.
2. Small Stable Dedicated Teams – Simpler communication and ability to personally connect makes small teams, of about 5, more effective. Team performance doesn’t happen overnight however can be destroyed overnight. Stability (not fixed) provides the time to build while enabling beneficial small changes and time to recover from them. Being dedicated to one team boosts collaboration, alignment and long-term team trust leading to accountability and high performance.
3. Swarming / T-shaped people – Broader skills and knowledge and perspectives from different specialties, will minimize dependencies and hand offs, and enable swarming increasing the team’s overall capability and ownership.
4. Finish early / Yesterday’s Weather – Teams that finish early accelerate faster. They get excited and confident from a “successful” sprint. The trend is your friend. Use “yesterday’s weather” for estimating how much can be completed.
5. Ready backlog – Great performance needs great preparation. Poorly understood work items tend to expand development effort exponentially causing the team to fail the Sprint Goal or not deliver the expected outcome.
6. Interrupt Buffer – There will be interruptions so create a buffer for it, preventing it to cause unpredictability and not being able to finish the work in the sprint. It should be used wisely, only when truly needed and not all at once.
7. Every day better – Also known as “Scrumming the Scrum” or Retrospective. The art of continuous improvement and removing waste. Take at least one impediment from the Retrospective and put it on the sprint backlog with highest priority. 52 opportunities/year for a 1-week Sprint!
8. Daily Scrum – Daily Scrums improve communications, eliminate other meetings, identify impediments to development, highlight and promote quick decision-making, and improve the Development Team’s level of knowledge.
9. Co-location – Co-location makes communication and alignment a lot easier and speeds up decision making. The less co-located, the higher the tax on efficiency and effectiveness. This makes for an economic-based decision.
10. Fix bugs same day – Bugs left to be fixed later, even a few days, compound the cost of fixing it. Bugs making it to production become “technical debt” and are exponentially more expensive to fix and badly impact customer value. Loose ends cause overhead, reduce focus and may lead to rework. The more a job is really finished (including testing, but also documentation, etc.) the better.

Team canvas

To improve binding of a team, it helps to have a catchy name, perhaps a logo and some agreements. You could create a team canvas as in the example below.

Leading to high team performance

A high performing team does not grow overnight. It’s a lot of TLC to create the environment and conditions for it to grow. We need someone to feel responsible for this TLC. When using Scrum, that person is called the Scrum Master. This person needs to be a leader able to lead the team to higher performance. This person is constantly on the lookout for ways to improve and support the team. As Barry Overeem put it: a Scrum Master should be able to lead, facilitate, coach, teach, mentor, manage, remove impediments, and being a change agent.

There are several models for leading teams to high performance. Some very well known ones are:

• Situational leadership® for teams (Blanchard) – The leader has to be able to assess a situation and apply the most appropriate style. When used in conjunction with Tuckman’s stages of group development (Forming, Storming, Norming, Performing), the leader has to assess which stage the team is in, apply the most appropriate style, and guide the team to the next stage. This means, first getting the team to start moving, then get buy-in and provide clarity, after that we can start reinforce progress and amplify alignment, an finally we can strive to maximize performance.
• The five dysfunctions of a team (Lencioni) – Based on observation of poor performing teams and their impediments, five levels were found that build towards a high performing team. It all start with building trust, vulnerability based trust, where we admit mistakes and weaknesses, ask for and offer help, appreciate skills and tap into them, look forward to meetings and working with the team. The next step is mining for constructive conflict to solve problems quickly and have lively interesting meetings, by truly listening, actively, honestly and constructively debating, and allowing and appreciating each other to have different meanings. Now we can start getting true commitment by clarifying direction and priorities, alignment for the entire team, and pivot or persevere without hesitation. The next level up is creating accountability by expressing and clarifying expectations, values and principles within the team, and showing respect towards each other. The final and highest level is getting results by avoiding distractions, celebrating succes and failure, and minimizing individualistic behavior.

Leading to high product value

Similar to a team, a great product doesn’t grow overnight and also needs a lot of TLC to create the environment and conditions for it to grow. We need someone to feel responsible for this TLC. When using Scrum, that person is called the Product Owner. This person needs to be a leader able to lead the team to higher product value. This person is constantly on the lookout for ways to improve the product and support the team doing it. As Antonio Costa put it: a Product Owner should be able to lead, negotiate, communicate, facilitate, manage, and be a scientist, entrepreneur and business analyst.

The specialist challenge

Teams are central in rapid and responsive development. Hardware teams typically involve different disciplines like mechanical, electro-mechanical, mechatronics, etc. Some teams are even more cross-functional and include software developers. And the optimum team would have all disciplines involved in the values stream to deliver value to a customer (e.g. sales, purchasing, manufacturing, etc.). Depending on factors like development size and complexity, this usually quickly adds up to quite a few people.
Since we can not expect a small team to have experts in any field and capacity to do the work of a hundred+ persons, and we want to keep our team small (see team size), we need to organize for a collection of small teams. There are different ways to do this like network (holocracy) or hierarchal (team-of-teams). Several scaled agile frameworks provide solutions like Scrum@Scale, SAFe, Less, Etc. Not every team is the same. Depending on the actual circumstances, trade-off decisions have to be made and there may be a mix of teams: hardware, software, hardware/software, support (e.g NPI), enabling (e.g. test automation), etc. 

The “specialist flexibility” U-curve shows the trade-off between specialism depth-breadth, ranging from I-shaped person (highly specialized person) to the comb-shaped person (Jack-of-all-trades), and cost for development and cycle time. The advantage of having multiple specialisms is that it enables better, faster, and more efficient development. The opposite is also true as specialism depth (knowledge, insight, skills, mindset) reduces. Typically, as the number of specialisms a person can handle grows, the depth reduces. Specialism depth depends a lot on talent, motivation and experience. Often you see that people have large depth on one specialism and less depth on another one. For instance a mechanical engineer with basic elector mechanical engineering competence. This means this person can understand implications of decisions and make better trade-off decisions, but also makes the team more flexible as they can assist for any electro mechanical work in the team increasing flexibility (‘swarming’). What can also help to support this, is standardizing or if possible automating tasks so also people with limited specialism depth can perform it. For example, a decade ago only CFD specialists would be able to determine performance impact of a design change, nowadays a lot of this is at the push of a button and is the need for the specialist reduced. And what about when you automate the ordering process? Now you can order most parts without in-depth knowledge of the ordering process. And how about using a simple script language for test automation so anybody in the team can create simple automated tests.
When specialist become part of a cross-functional team, they still need to keep ‘ their tools sharp’, learn and grow. There is a need for people to share and gain knowledge and insights, learn new skills, talk to like-minded to share and test ideas, etc. For this there is the so-called Community of Practice (CoP). These can be unofficial and short lived to official long lived groups that come together regularly to share knowledge, plan improvements, collaborate on exploring and realizing ideas, etc.

Of course specialism is not the only thing to consider. A team is a living system, hence we say “stable” instead of “fixed”. Junior people need a chance to grow, people may leave or change role, etc. And how about diversity and inclusiveness which provide color and different view points to the team.

Cohesion

The amount of cohesion in a team or team-of-teams depends on the circumstances, bot current and desired in future. As shown in the image below, there is an optimum to be found when combining scattering cost and scaling cost. The first being the cost incurred when working separately on multiple topics at the same time, the latter when working collaboratively on few topics at the same time. Depending whether the optimum is more to the left or right, a type of team (of-teams) can be defined: fully integrated, closely related, loosely related, segregated. One is not better or worse than the other, it is just finding the right setup for the actual conditions. One may influence conditions and find a different optimum (e.g. lower cost of scaling to enable teaming-up).

Events

Incremental and iterative development means short cycles of plan-do-check-act (PDCA) or Observe-Orient-Decide-Act (OODA). Most teams use Scrum which has defined the following events: Sprint Planning (plan the Sprint), Daily Scrum (sync and plan the next 24hrs), Sprint Review (review done work) and Sprint Retrospective (how to improve). Besides that, time is reserved for refinement (prepare upcoming work). When working with Scaled agile, similar events are added for the next level up (team-of-teams). Since hardware development has a lot to deal with specialists, outer team dependencies and often long lead times, it is important to pay much attention to this during the events. For example during planning check and plan for risks due to dependencies and fit for different specialists, during daily scrum recheck and act, during refinement look ahead to anticipate, during retrospective plan to reduce or eliminate dependencies, etc. For more details on these events, please read the in-depth article Events – Good practices. When working with multiple teams (scaled agile), similar events are added for the next level(s) up.

One of the most heard objectives to using Scrum for hardware development, is that long lead times make it hard or even impossible to deliver a done increment at the end of a sprint. Especially since the old Scrum guide said “delivering a potentially releasable Increment of ‘Done’ product at the end of each Sprint”. In the new (2021) Scrum Guide, this phrase is replaced by “creating any aspect of a usable Increment each Sprint” and “adhering to a Definition of Done”. First of all, the team with respect to their stakeholders defines what ‘usable’ and ‘Done’ mean. Usable is whatever brings value to any stakeholder. Done depends on the maturity of team and environment, to what is possible given current circumstances.
A possible strategy is using a cascading DoD where there is an increased level of done for respectively stories, features and releasing. It is important to realize that a Sprint is not just a time box to deliver a product increment, it is also learning cycle. A chance to learn if something works, if it is what the customer actually can use, if there were unexpected side effects, etc. So even thought the length of the sprint can vary to maximum a month, with the previous in mind, we don’t have to stretch the sprint to fit long lead times, etc. It is far more important to have frequent moments of feedback, alignment and re-planning. Especially when learning agile, it is recommendable to have a higher frequency like weekly sprints, and adapt the (cascading) DoD to that.

The burn-down challenge – why projects run late

Development is inherently uncertain and we learn and adapt as we go. Some things we can prevent or minimize (like changes to the team), while others are an essential part of the game (like discovering risks). In the figure above, you see some examples of events that influence the burn-down.