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
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
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
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
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
Simply put – silos of specialization can be bad for business.
Why do we want a
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.
Subscribe to be the first to get our expert-written articles and tutorials for developers!