Individuals and Interactions over Processes and Tools

Individuals and Interactions over Processes and Tools. Yes, really.
The Manifesto for Agile Software Development is four fantastically brief points:

  • Individuals and Interactions over Processes and Tools.
  • Working Software over Comprehensive Documentation.
  • Customer Collaboration over Contract Negotiations.
  • Responding to Change over Following a Plan.

People still don’t understand or embrace it though. More than the others, misunderstanding of the first point really stings like salt in a wound when people don’t seem to understand what it means or the importance of it. For instance, I saw an advertisement for a tool on Twitter yesterday evening stating that

”For best agile practices, you need the best tools”

For best agile practices, you need the best tools

I regularly have people excitedly tell me about new tools that they have come across, usually offering some excellent collaboration features with some lovely HTML 5 interfaces. My first response is usually along the lines of yeah, it looks great, but what problem is it actually solving and is that something that can be better addressed by improved face to face interactions?

Tools can be brilliant, and some definitely can help some teams to perform better, but the majority won’t be on any benefit to the majority of teams.

When a tool solves a problem there may well be a very strong business case for the team to use it, but what are the side effects? Does it inadvertently stop teams from communicating?

A lot of teams like to use electronic boards to visualise their user stories. A lot of these tools allow development team members to define the tasks that are required to complete a story, and people are able to assign themselves to the tasks that they are going to complete. In an ideal world, that’s probably fine, however the side effect that I have observed in a number of teams is that it reduces the collaboration between team members – people no longer have to talk about what they are working on or what they are going to pick up next, or even how well a story is progressing because they can get all of that information from the board.

When teams start to reduce their levels of communication (interactions), quite often their levels of collaboration start to suffer quite significantly as well, and it can go as far as to act as a barrier between teams becoming self-organising because in effect the board is organising things for them. That’s not to say electronic boards are bad, but do they really offer anything over a plain whiteboard and some post-it notes? If your team isn’t co-located then they probably do, but otherwise I’d suggest that you think twice before moving away from the simplest solution.

Less is so often more, and my own preference when I do have to use electronic boards is to stick to something simple such as Trello, rather than going for the more complex and theoretically more powerful Jira.

Tools should assist teams, and when they are complicated they are simply a burden. It seems to me that because most tools are designed for the most typical Agile teams, they are designed for teams who aren’t terribly performant and generally don’t do what they should, so they require capacity to store thousands of defects. They don’t work well together, so they want a way of communicating via a board rather than face to face.

Scrum exists only in its entirety, otherwise it’s Beetroot

"Scrum Exists only in its entirety and functions well as a container for other techniques, methodologies and practices." "…although only implementing parts of Scrum is possible, the result is not Scrum"

This is one of my favourite parts of The Scrum Guide, authored by Ken Schwaber and Jeff Sutherland. I feel that it is a key part of Scrum that is so often over-looked and forgotten by teams who are finding that they aren’t experiencing the results that they would otherwise expect.

The Scrum Guide also states that while Scrum is simple to understand it is also difficult to master, and I think that this is what leads a lot of teams to cutting corners and/or missing the point of some of the finer but significant details.

The Scrum Guide is a very short and concise document – cover to cover it’s only sixteen pages – and I’d encourage everybody who has interest in Scrum to take twenty minutes to read it, and then spend a little bit of time digesting it and trying to figure out what it actually means.

I’ve previously blogged about Five signs that you aren't actually practicing Scrum, but I’d like to add another one to that – that you haven’t read The Scrum Guide.

Like a GCSE Maths course; the content is not negotiable. You can change it to make it easier, harder, more of a logical flow, etc. but the bottom line is that if you aren’t following the syllabus then no matter how good or bad the course is, it isn’t a GCSE Maths course!

You can almost certainly make Scrum better – despite how much I respect Ken & Jeff’s work I find it hard to believe that there isn’t at least one way that Scrum can be improved. The bottom line, however, is that Scrum is a defined framework and if you aren’t doing what you should be, even though you might have the best Framework, Model or System in the world, it isn’t Scrum.

When you don’t understand the path you’re following, you are destined for failure almost no matter how good what you’re doing actually is.

If you’re hiking through the hills and you think that you’re following a well-established and well used path, you’re less likely to take some of the precautions that you might if you were off-piste. This analogy reflects my greatest concern with teams who aren’t following the framework that they think that they are; when you believe that you are following a well-trodden path you probably don’t act with the scepticism or the suspicion that you otherwise might. It’s easy to feel secure and safe when you’re part of the crowd, and I believe that to be true of teams who think that they are following Scrum but aren’t.

If a development team isn’t self-organising, isn’t estimating stories, isn’t transparent or doesn’t have a definition of done understood by everyone and considered as part of estimating and Sprint Planning (to list but a few things), then it is Scrum only by name.

By all means keep doing what you’re doing if it works for you, but don’t pretend it’s Scrum. Call it something whacky like Beetroot and you never know, with the right marketing it might just make you a millionaire.

Job titles in Agile, and why they are bad

95% of teams/companies that claim to be Agile, aren't actually practicing Agile.

I don't know how true that statistic is, but I could easily believe it from conversations that I've had.

There are a lot of things that teams and companies struggle with when it comes to Agile, but one that stands out above the rest is that teams get caught up with particular people having particular jobs to do. At the most basic level, this means that developers develop, testers test, designers design and managers manage.

But then, why should anybody be surprised by that - almost everybody has a job title, which pretty much draws a box around what work is theirs, and what work is somebody else's. It's one of the most fundamental differences between a truly agile start up and a lethargic mid-size company.

In Agile it is skill-sets rather than job tiles that matter. Anybody with the right skills should be able to pick up a task, and job titles create a significant barrier to that.

The two friends who are fresh out of Uni' and are each working sixteen hours a day to try to make it big with their startup do anything that they can, whether that is developing, designing, testing or sales, etc.

It doesn't take a genius to work out why companies continue to assign job titles - it makes a lot of things, not least recruitment and HR a lot easier. But do the advantages outweigh the disadvantages? It's a difficult question to answer, but I'd be inclined to say that they probably don't.

There's a lot of cultural challenges around Agile which makes recruiting the right people critical, yet many have inadvertently stopped people from becoming truly performant before they've even started.

The Scrum Guide makes reference to the 'Development Team', which encompasses everybody who isn't Product Owner or Scrum Master. It's one of the less subtle parts of Scrum that people get wrong, sacrificing a big benefit.