It takes great leadership to build great development teams. In this post we look at the rules for great development teams. The rules may seem simple but they are incredibly hard to implement.

Be cross-functional

Be cross-functional: Developers, Testers, Customers and Operations work together to build great products. There are no handovers between organisational silos.

The first big anti-pattern is business analysts that pose as product managers and don’t truly own the product.

The second anti-pattern is one team building a product and another maintaining it. It is sometimes said that developers don’t want to work on incidents.  The argument is that it takes their focus off the project they are working on. In New Ways of Working for Development there should not be projects. Only a single backlog that the team works on that includes feature development, refactoring, architecture work and incidents and problem fixes in one single place.

Less huge

If a team focuses too much on efficiency they start using large batch sizes. The illusion is that large batch sizes give us economies of scale. Economies of scale then leads to efficiency. Or so the argument goes. The problem with this line of reasoning is that we miss the relation between batch size and cycle time, and the relationship between batch size and feedback speed. Great teams deliver small chunks of functionality frequently.

Follow a process

Great teams don’t work ad hoc. They experiment with some flavor of an Agile or Lean Methodology. The choice of the process itself is not as important as picking a methodology and constantly improving. Great starting points are Scrum or Kanban. For large organizations look at the Scaled Agile Framework (SAFe), Large Scale Scrum (LeSS) or Disciplined Agile Development (DAD) as great choices to start the journey.

Small teams

Teams consist of less than 12 people. It is helpful for them to form part of a bigger product community. This community should probably not be more than 150 people. Again these are rough guidelines. Have a look at the Spotify model with its Squads, Tribes and Guild constructs or the SAFe model with its Team Programme and Portfolio Layers.

Test Everything

Test everything - not only functional requirements. An essential part of the test cycle is non-functional requirements. Associating a test with every piece of functionality is a fundamental rule which contributes significantly to the solidity of the product.

Automate everything

Almost every aspect of the build, test, release, change and deployment processes should be automated. Code propagates from laptop to production seamlessly. In highly mature organizations even infrastructure provisioning is fully automated.

Measure everything

There are real-time performance metrics across the full production cycle. This should include target customer use cases that look beyond the traditional reactive metrics of availability and performance toward proactive customer metrics such as websites visited and paths taken. As Richard Campbell, founder of Humanitarian Toolbox, says, “The challenge is to get to good metrics. It is very easy to make vanity metrics . . . [that don’t] tell you a lot".

Create flow

Great teams don’t worship efficiency or utilization. Teams get products to customers quicker by optimizing flow. They do this by pulling work from backlogs and WIP (work in progress) limits are in place. The enemy of flow is large batches and batch-thinking. Fitzgerald and Stol succinctly sum this type of problem up: “Actions are done on batches of products, after which they are queued for the next processing step. By contrast, flow refers to a connected set of value-creating actions— once a product feature is identified, it is immediately designed, implemented, integrated, tested, and deployed.”

Servant leaders

Servant Leadership proposes a more meaningful way of leadership to ensure sustainable results for individuals, organizations, and societies. The characteristics of Servant Leadership include listening, empathy, healing, awareness, persuasion, conceptualization, foresight, stewardship, commitment to the growth of others, and building community.

Give

Teams are helpful to other teams and they constantly collaborate. If they have the skills another team needs they help out and optimize the flow of the enterprise.

Improve

Great teams get better all the time. They reflect and decide what they can do better for the next round of delivery. A good rule of thumb from James Altucher is to improve by 1% every week.