Latest information from Radtac

See all topics

Subscribe to the Radtac blog

Connect with us

Recent Posts

Latest information from Radtac

Cross Functional Teams – really?

Multitasking - Shutterstock

Having spent 16 years in Retail Banking in the late 90’s, I made the entirely (il)logical jump into IT; just about the time that the panic started to set in for the millennium cutover when all IT systems were expected to black-hole. I even remember that Virgin decided to stop all flights that bridged the hours from 1999 to 2000!

However, having served my apprenticeship as a Business Analysis, in October 2000 I joined a company as a Business Systems Manager. A strange title because it was part Business Consultant (understanding the requirements from the ‘lines of business’ I was supporting) and part Project Manager (prioritising competing needs and creating business cases, baseline plans etc.). To be honest, not a million miles away from being a proxy Product Owner but delivering in a very traditional / waterfall way.

A Project Leader supported me, who was more akin to a Team Lead in Prince2 terms, plus a team of 6 Analyst Programmers.

But here is the Thing! The Analyst Programmers did the Business Analysis, did both the User Interface and Technical Design – the entire stack. They also wrote the Code, did the Tests and released to live. They then provided a level of post implementation Warranty Support before formally handed over to Operations for ongoing routine day-to-day support.

What very modern thinking! A truly cross functional team of ‘generalised specialists’, including DevOps. Then things changed, probably around 2002 - remember the date!

Our privileges were removed so that Analyst Programmers couldn’t release to live any more, so we introduced a Release Manager. We also recruited two Business Analysts who were shared across 4 teams!

This was followed by appointing three Technical Architects, some Project Managers (who also got company cars!), then Test Analysts, to such an extent, that there were so many of them that we needed a Test Manager! To top it all, the Analyst Programmers became Developers within a well-defined hierarchy:

  1. Associate Developer
  2. Developer
  3. Senior Developer
  4. Lead Developer
  5. Development Manager

The four stable cross functional teams were split into their respective Silo’s. Each was assigned to projects by a Resource Manager, who then spent their time trying to start other projects by releasing resources (people) from projects that were over-running – but that’s another story.

As a consequence of these silos, we introduced ‘hand-offs’; these created tensions between the respective disciplines so we lost any form of collaboration and in practice the ‘new system’ created a blame culture.

Now the timing is interesting because at the same time as we were dismantling our cross functional teams, Agile was starting to gain traction in the industry.

Brief history lesson follows:

  • 1994 Dynamic Systems Development Method is created (DSDM Consortium, 2014b),
  • 1995 Ken Schwaber and Jeff Sutherland present a paper on Scrum at the OOPSLA (Object-Oriented Programming, Systems, Languages and Applications conference) (Sutherland, Patel and Casanave, 1995),
  • 1996 Rational Unified Process (RUP) (IBM Rational, 2014),
  • 1997 Feature Driven Development,
  • 1999 Kent Beck publishes Extreme Programming (XP) Explained (Beck, 2004),
  • 2001 The Agile Manifesto is created (Agile Manifesto, 2001).

In fact we ran our first Agile project in the summer of 2005, by which time we had completed our dismantling! And yet Scrum talks about teams with the following characteristics:

  • Development Team are cross-functional, with all of the skills as a team necessary to create a product increment;
  • Scrum recognises no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule;
  • Scrum recognises no sub-teams in the Development Team, regardless of particular domains that need to be addressed like Testing or Business Analysis; there are no exceptions to this rule; and,
  • Individual Development Team members may have specialised skills and areas of focus, but accountability belongs to the Development Team as a whole. (Scrum Guide 2013)

The Agile Manifesto says that Business People and Developers must work together daily throughout the project; there is no mention Analysts, Architects, Testers, etc.

Years later, we are now trying to re-create these cross functional teams; creating a culture of cooperation and collaboration and recognising that teams will be made up of generalised specialists – like a Rugby team.

Whilst there will be Hookers, Flankers, Scrum Half’s and Fly Half’s, each member of the team will be expected to tackle, to run with the ball, to catch and to pass and kick the ball.

I have never heard a Rugby player say: “no, no I don’t run with the ball, I’m a Forward!!” And yet, I still hear that in our IT development teams today; “no, no I don’t do Testing, I’m a Developer”. Even worse; “no, no, I don’t Code anymore, I’m an Architect don’t’ your know!”

So my question is: why did this happen? Why did we create these Silo’d specialisms at the very time we started to recognise the importance of cross functional teams comprised of generalised specialists.

I'd be curious to hear how you feel about this. Please share your thoughts with me using the comments box below

Darren Wilmshurst Head of radtac:consulting

Image source: Shutterstock

Did you know Radtac, is the lead author and editor of the official textbook for the BCS Foundation Certification in Agile? To receive the first chapter of the book or purchase a copy visit Agile Foundations: principles, practices & frameworks.


Darren Wilmshurst

Darren Wilmshurst

With his strategic C-suite-oriented approach to IT leadership – and his infectious energy – Darren has successfully delivered multi-million pound business transformations for e-commerce sites, ERP implementations, outsourcing and offshoring, including multiple Agile transformations. Read more