At the end of April we attended Craft Conference in Budapest. The two most repeated concepts were microservices and containers, but the underlying theme throughout was how up-to-date ideas and practices are required in order to produce high performance teams.

In this post I will try to bring those aspects together focusing, not necessarily on what is new, but on what is proven to work.

Be prepared for learning and do it fast

It doesn’t sound new:

Instead of arguing about new software ideas, we actually tried them out by writing quick prototypes, keeping the ideas that worked best and discarding the others. We always had something running that represented our best thinking at the time.
– The Macintosh Spirit

“High performance teams do between 10 to 20 iterations of MVPs in a week”, to quote Marty Cagan. He emphasises the importance of MVP (minimum viable product) as an experiment for validating that the purpose is feasible in the minimum time possible when the team is focused on the key risks: value risk (is anyone is going to use it),  usability risk, feasibility risk and stakeholder risk.

To achieve this he talked about the separation of two tracks for products: one for discovery and the other for delivery, each with different processes and speeds. For deliberate discovery, Dan North highlighted the importance of embracing uncertainty of scope, technology, effort and structure for validating positive and negative assumptions.

Product teams need an immediate connection with the product they are creating. Mary Poppendieck displayed a very illustrative video by Bret Victor to show this concept of immediate feedback.

Jezz Humble proposes a Learn (create value hypothesis) – Measure (how do we test it?) – Build (gather the necessary data)  approach for ‘High Performance Organisations’. It is important to create feedback loops to validate assumptions and enable an experimental approach to product development using methods such as impact mapping or hypothesis-driven delivery. A nice example of this comes from Etsy – ‘Etsy’s Product Development with Continuous Experimentation’ as presented by Frank Harris and Nellwyn Thomas.

End-to-end empowered teams

Product, Development and Operations have to work as an ‘end-to-end’ team that solves problems instead of delivering features. They have to work out solutions and iterate.

Many of the companies that have ’embraced’ agile are actually following what Jezz Humble describes as a Water – Scrum – Fall process. It starts with the product team gathering ideas, making a business case, prioritising them and planning a roadmap. Then the development team iterate in different sprints to build the features, which are then used by the operations team, often failing in maintainability and impact.

To spread agile throughout an organisation, these layers have to be broken. Moving to ‘end-to-end’ teams is one solution but it involves several important changes within the organisation:

• Dev has to be part of the product process. Developers are not just for coding and great things happen when they have the chance to listen to clients about the good, bad and ugly aspects of a product (Marty Cagan).
• Organisations have to attach monitoring and deployment to product development. They have to change the cycle of monitoring development. Whereas, usually the last thing to think about in a feature is securing, deploying and monitoring (James Turnbull).
• Create a win-win relationship between Dev and Ops
• Accountability has to be part of the team. The company needs a team of missionaries, not mercenaries (Marty Cagan).
• Colocation is very important. It enables discussion and collaboration-driven solutions.

Focus on business value, customers and outcomes

One common mistake is the use of velocity as a measure of team performance. It should only be a measure for use in planning. Shipping features is not victory (Marty Cagan).

The goal of software development should be to ‘sustainably minimise the lead time to business impact’, not just to produce software (productive != effective). Code is not the asset, it is a cost.

Sometimes greats solutions have 0 lines of code or, even better, come from deleting lines of code. (Dan North)

Therefore, it’s important to give business problems to a team that is obsessed with the customer and has contact with them. Services are customer-focus and you should use this to decide what metrics to monitor. Business metrics are on the top because if you are running a business and you have no metrics obviously something is wrong (James Turnbull)

Organisation culture , vision and strategy

To operate a high performance team, it is fundamental to foster a culture of trust and empowerment, aligned with a commitment to continuous improvement. Jezz Humble characterises it as:

• High cooperation between members
• Messengers trained
• Risks shared
• Bridging encouraged
• Failure leads to enquiry
• Novelty implemented

Continuous improvement happens through retrospective in a blameless environment.

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand
– Jezz Humble

It’s worth pointing out that experience shows that some individuals find it hard to work in this way. It’s not for everyone and sometimes hard decisions have to be made for the benefit of the team.

Finally, the whole team needs to be motivated and have unity of vision. This can inspire individuals at any level.

Delivery and quality

High performance companies manage the triangle of scope, quality and time by not compromising on quality.

Teams have to be able to release work often and with confidence, so it goes without saying that you need to invest in the process of continuous integration and delivery. However, at the same time the teams have to be ready to deal with failure.

We need to be conscious that, in a complex and adaptive system, failure in inevitable and in response build resilient systems. We cannot prevent failure but we can avoid it being amplified.

How can we test that we’re able to handle failure? Have a look the Chaos Monkey from Netflix.

Want more on this topic?

If you’re interested in exploring these topics further access the presentations from CraftConf.

Embracing uncertainty: why you should and why you won’t
Dan North – Dan North & Associates

Great Product Team, Successful Product
Marty Cagan – Silicon Valley Product Group

Microservices: software that fits in your head
Dan North – Dan North & Associates

You Can Have It All: Software Development at Ludicrous Speed
Jez Humble – 18F

Monitoring As A Service – Modernity and Self-Service
James Turnbull – Kickstarter

The Future is Here, it’s just not evenly distributed
Mary Poppendieck – Poppendieck.LLC