Invest in teams, not projects

At IBM in the 90’s I was involved in number of client projects. It was before the days of collaborative, iterative and value-led software development approaches – back then formal project and programme management methods ruled the roost – but what really made these gnarly, complex, expensive, hierarchical multi-year programmes successful to any degree, was not the control and management structures, but the teams working well together with accumulated knowledge of the business, the user, and the technology.

Behind the project control mechanisms, work breakdown structures, risk logs and planning processes, there were large teams of very smart people developing code, working on big batches of functionality that would progress through test and into release over many months. These teams often worked at the client site, where over time they built up knowledge of the customer’s business, the technology solution, and of each other. Teams had formed, with a shared purpose, combined skills and knowledge to deal with problems as they arose, and even working within an inefficient delivery system, these teams solved problems and delivered value.

At the end of these programmes, once the solution was ‘complete’, the vast majority of the team would be reassigned to another project, usually for a different client and perhaps in a different industry. I was always troubled by the loss of combined knowledge, and I coined this a ‘form-and-disband’ model for delivery.

Projects will come and go. It’s accumulated knowledge and skills in people that delivers value from technology.

Thankfully, methods and approaches to software development have changed, but I still see the form-and-disband mentality in lots of places. Often it’s an underlying assumption of plans and business cases, that you can stand up a technical team, and they will begin delivering high quality and high value software within weeks or days. Sometimes it shows up, when things get tough, in sweeping and reactive changes to existing teams such as adding heads to ‘increase’ capacity, or removing to save cost, that disrupts any kind of value that would eventually flow.

This problem is even more pronounced for teams working on digital solutions – software that needs to adapt and change continuously and rapidly, where value is measured as part of an overarching customer experience that is improved over time, and where tech teams need to work as part of the business operation. This form of continuous delivery needs a stable team for the long term, a team that builds a knowledge of the languages, frameworks, customer/user value, context of the business and industry… the context in which the technology is being used. These teams need to also get to know each other, strengths and weaknesses, they need to bond, solve problems as a unit, to form a tribe.

Software engineering is a creative process, it is not a mechanised and predictable production line, because human beings develop code, and human beings are not like-for-like interchangeable units. You cannot plan for the unexpected, but you can deal with it, and even find opportunity in it.

Really great teams take time to form, and to begin to perform. Using software to provide better products and service, and to get closer to customers, means committing first to growing a long-term capability in people. Once you have built this capability, whether it’s through partners or in house, you also end up with more predictability in delivery, allowing better planning and forecasting.

One way to do this is to make ’team churn’ one of the leading indicators for your agile team, programme or portfolio – the number of people that move in and out within a certain period – it’s a simple measure of stability.

Projects will come and go, but it’s accumulated knowledge and skills in people that delivers value from technology. This needs care, attention and maintenance for long term benefit.