For a long time I have expressed my disapproval of deadlines in agile software development, because in my opinion they cause unnecessary pressure and stress in the teams. With a few exceptions, such as a legal requirements with a fixed date, most deadlines seem artificial and arbitrarily set. So why should a team possibly burn itself out and work to exhaustion just to achieve an imaginary goal? One of the things that matters in agile software development is delivering value at a steady, sustainable pace, i.

“Before taking this live, we need to coordinate with C-level. This can have strong implications on our sales.” “I still need to coordinate with my Head on that.” “That affects the other team. We need to clarify if they’re OK with that.” “We’re still waiting for the agency’s input, but then we have to get started right away or we’ll run out of time. Can’t you guys prepare something already?”

In the first part of our series on Accelerate, we described how the top performers in software development perform orders of magnitude better in the 4 key metrics. The question remains - how do they get it right? Software development is a complex business, so conclusions of “the team is successful because they did X and Y” are problematic. However, as part of the Accelerate research, the authors identified 24 characteristics and capabilities that contribute significantly to improvements in software development velocity 1.

There are many talks and articles that deal with the growing complexity of software and scaling software development teams. But often, it is hard to see a fundamental improvement apart from anecdotal stories. Rather, the question often remains: Does this really help? The findings described by Forsgren, Humble & Kim in the book “Accelerate” 1 are quite different: Here, large-scale surveys were used to determine which characteristics correlate with high-performing software development teams and which do not.

Are flexible team structures good or bad? On the one hand, (mostly) management wants flexibility in team structures so that the right people can work on the most important issues. On the other hand, stability over time is necessary to build a high performance team. What do we do with this clash of objectives? Flexibility - Where does the need come from? The need to build teams flexibly arises precisely when the skills needed to address a topic do not match the skills of the team.

A work in progress limit helps to keep focus and deliver the desired value to customers faster, instead of working on many things in parallel over a long period of time. Figure 1 illustrates the idea (see The Illusion of Progress - Non-Productive Busyness). Figure 1: A WiP limit creates focus and leads to faster results. But what if it doesn’t work that way? What if you focus on one topic, but it still drags on for a long time, as shown in Figure 2?

What do I mean by ‘process fiddling’? Implementing ideas as they come in. You hear or read something and implement it in the company or team, sometimes with external support, without considering whether the prerequisites are actually given. For example, it makes no sense at all (in my opinion) to implement a discovery delivery process in the team if you don’t have a true cross-functional team with a certain maturity.

We’ve looked at literature on various topics on the blog before, such as legacy code or dysfunctions in teams. Team Topologies deals with organizational design and team interaction, wich are also essential for effective software teams. Now you might think this is mainly a topic for managers and organizational developers, but the underlying principles apply to all team members in software development teams. Team Topologies was released in 2019 and addresses a core problem in modern software development: how can we continuously deliver new features quickly and with high quality?

Ineffective Busyness If a team works on too many topics at the same time, employees will eventually specialize in individual topics. This has disastrous consequences for the team: Knowledge silos: If one person drops out, the topic is at a complete standstill until he or she is back and can continue working. Suboptimal solutions: If only one person is working on a topic, there is no discussion about different solutions, there is no pair programming and reviews become shallow.

A Leadership Fable — Kathryn & her Team Most of the book comes across as a fictional business novel. You may like that or not, but it helps to visualize the conflicts and issues involved in teamwork. The book deals with CEO Kathryn and her leadership team at the fictional Silicon Valley company DecisionTech, Inc. Kathryn has been freshly appointed as CEO since the company — 150 employees in size, some of the founders still on board themselves — is piling up more and more internal problems.