The Lure of Specialization

Everyone knows that developers can’t test! Let’s face it – testers should only test. Developers should only develop as they have no clue what test cases look like and can’t be bothered with such mundane and trivial work. Asking a developer to test or to write documentation is like asking Leonardo da Vinci to build his own canvases and clean his own paint brushes. We need business analysts to tell developers exactly what we need to be developed using very detailed models and specifications (I mean.. developers understand code… they need to explicit instructions so that they know how to design everything with the end perfectly defined). We need project managers to align the team and to optimize the whole. The only way to optimize the whole is to optimize each flow independently… and.. make sure that developers have their own work place – they need peace and quiet – don’t disturb them – this is what email and meetings are for. And.. if the developers get it wrong, if there user doesn’t like what they see, it can never be a developers fault because they only coded to the detailed specification they received – besides, user acceptance testing is a QA thing.

<visualize sound of brakes and smashing cars – explosions – screams – gnashing of teeth!>

Complex systems, such as software development teams, aren’t always best managed through traditional command and control processes. It’s much more complex yet simple at the same time.

Some have suggested that we’re starting to see an engineering discipline applied to software development (and the construction and engineering of software as a whole). Mark Kennaley, in his book SDLC 3.0 – Beyond a Tacit Understanding of Agile, goes a long way to help us understand how existing models, such as theories that help manage Complex Adaptive Systems (Control Theory, Control Systems Engineering, Distributed / Networked Adaptive Control, non-linear control, Birurcation control and chaos control) can help us with the management of Chaordic systems. This makes a lot of sense, and I welcome all of you to explore this, however, for most people in our industry today, these principles need to be distilled into something more consumable. In fact, for the most part, we already have such distillations – we have Agile (the brand-less version of Agile – not the religious brad wars we are seeing out there), we have Lean, we even have derivatives of the Unified Process (yes, I said Unified Process out loud). All, in some form or fashion, are distillation of some of these ultimate truths.

So why are we so easily lured into practices that erode our possibility of success?

Specialization is a result of our rational mind. We were taught to break problems down into smaller problems all through school. When we look at the process of building software, our instincts are to do what we were taught – break the problem down into smaller problem – and solve (optimize) the smaller problem.

It feels natural to segment people’s roles. It’s great to have a job description, a discrete list of what you are responsible for.. understanding your inputs so you can optimize your outputs. Boundaries, silos – they are comforting and logical. When faced with the challenge of software construction it seems natural to have specialists and roles. First, it’s easy to draw a process with such specialists – constructing input, outputs and flows from one role to the next. It’s natural to try to construct a system that has a set of inputs – and operation – and a set of outputs – and we translate that to how we construct our traditional teams. Business analysts accumulate pure business knowledge and transform it into specification. Developers take specification as an input and output binaries. Testers consume specification and produce test and acceptance criteria – and are also responsible for matching acceptance criteria to what is produced by developers. Its also really easy to reward silos – give them specific tasks.. if they do those tasks.. you give them a reward. If they don’t do those tasks.. you don’t give them a reward – HR organizations around the world LOVE this. Simple.. natural..happy.. and, well if you do this – you will likely be committing teamicide (team suicide).

So, why can’t we use a discrete command and control process to control the software development process. The problem lies in the fact that software development and the teams that build software form a “complex and adaptive system” as Kennaley suggests. Let me boil it down a bit..

1. Humans are funny creatures

2. Stuff changes – a lot

3. We rarely know what we don’t know

All the practices you read about with Agile (regardless of brand) and Lean and UP are there to address these distillations (and much more as you might guess). Sometimes “Agilists” come off a bit preachy compared to our Lean counterparts (likely because Lean is decades older than Agile – a bit more formalized, and a lot more proven) – but the core principles and practices we discuss are there to address best ways to address these issues (without getting into too much of the theory surrounding Complex Adaptive Systems).

So – let me focus on the practices that related to teams and roles in the Agile world ( with a touch of Lean inspiration… ). Our chaordic system requires a different approach.

Simply put – silos of specialization can be bad for business.

Why do we want a cross functional team? Simple, it’s to get stuff done faster. Customers only realize value when it’s done. Not when it’s in progress. Not when it’s designed. Only when it’s done. So, we structure our teams and our processes to limit work in progress and get the team focused on getting that piece of customer value to done. In an iterative model, we use iterations to limit our work in progress. In a continuous flow model such as kanban, we have one piece flow – (often called iteration-less flow). Again - why do we want to have a cross disciplined team? Because silos create the need for handoffs. Handoffs are wasteful. Handoffs are wasteful for many reasons – but ultimately, we must address the human condition. As humans, we’re crappy at transferring knowledge and context to one another. When we write words down on paper, at best we can capture less than half of the intent of the words we write. Humans communicate REALLY well when they are face to face – using all of the subtleties of human interaction (facial expressions, body language, the list goes on) to communicate. If you want your team members to communicate well – you must have high bandwidth – and that means communicating in a way that humans communicate best. Back to silos, if we rely on handoffs then there must be a something to hand off – this typically means some artifact of some sort – a document that describes a specification or intent.. but wait, I just stated that we lose over half the context and meaning with anything written or modeled – to many, the solution here is much better documentation – but you will quickly hit a point of diminishing returns – never truly coming close to fixing the problem. Handoffs also mean task switching – task switching is bad – humans aren’t good at task switching. Handoffs mean there is a possibility for jams – where one “specialist” or silo of work has much more work – compared to other silos – introducing waste because people end up “waiting” for stuff.

We promote cross functional, self-managing teams to address the issues with handoffs – to minimize waste, and to help get things done faster, with less rework. This doesn’t just deal with developers – this deals with the ENTIRE team – from those who may be more focused on schedule – to those who may be more focused on quality. I’m not suggesting that our teams don’t have affinities and passions for certain types of work or technologies (we must always leverage this, since the performance of a person with passion for their job compared to the performance of a person with no passion is stunningly apparent) –I am saying that we need to do everything we can to minimize any form of handoff or large scale transition – this means that a team that embraces this does not have the silos of a more traditional command and control/strict roles and workflow based team. Testers test – but they don’t just test. Developers write code – but they don’t just write code. Team managers manage schedules – but they don’t just manage schedules and reports. The team doesn’t rely on handoffs and basks in the glory of high bandwidth communication to maintain context and reduce waste and rework.

Silos also create this weird “not my problem” attitude that doesn’t do anything to help teams succeed. When you have silos its soo easy to establish blame. If what you produce isn’t quite right? Blame it on the quality of your input. If you don’t deliver on time? Blame it on the previous silo. It’s sooo natural to do this, but what teams forget is that regardless of role – the team can only succeed together. Managers of these silos start trying to find ways to “optimize” each silo (“we need more testers” or “we need better specs”) but the results match the effort. Optimization of the whole team is the only way to optimize throughput while controlling operating expenses and investment.

The entire TEAM needs to work together to produce customer value – when this happens we see some stunning results. Waste is minimized, context is maintained, velocity and productivity go up, team dynamics increase, you start to realize a more measurable and sustainable set of results. We don’t promote this practice for some hippie-kumbaya - “power to developers” – software craftsmanship purity movement – we promote it because of the results we can measure.

Here are my calls to action…

1. Question your defined role on a team. Your true role is to help the team provide value – in whatever form that takes. If you’re a developer – accept the fact that you might have to do none-developer work, like writing user documentation, helping write and test acceptance criteria, listen directly to the customer’s voice. If you are tuned as a tester, know that you may be needed to help define user stories, work to help define acceptance tests, write user documentation – whatever it takes.

2. Go and read PeopleWare – it’s an older book – but it is wisely written

3. Embrace the human condition. Know that humans aren’t computers – we can’t be modeled like we do linear systems. Embrace the fact that humans are silly creatures.. and we need to work in a way that minimizes the results of this silliness.

4. Don’t fall into the trap – scaling agile doesn’t mean falling back into a command and control/silo/specialist mindset. I see teams do this too quickly and too often. Struggle for “TEAM”

This topic makes me want to write about “The Lure of a Coding Hero”.. hmm.. maybe I’ll write that on my next cross-Atlantic flight.