It’s not about the tools and processes…
I’ve been reading Quora lately, and despairing. Nearly every question about Agile there is in this format: “What tool is the best for doing {X} in Agile?”. This is disappointing. What happened to the Agile Manifesto? That bit where it says “People and interactions over processes and tools”? People seem to have forgotten the lesson – or perhaps never learned it in the first place. What’s gone wrong here?
It’s not about the tools…
A lot of people seem to make the mistake of starting with a tool or a process, and then finding and fitting work into the tool and process. This is doing it backwards. Start with the work – just the work. If you have a small cross-functional team, you are operating in a greenfield system and you don’t have major dependencies or bureaucratic hurdles, you probably don’t need a tool. Or the tools you need, which I’m frantically trying to tell the hundreds of people asking these questions on Quora, is index cards, post-it notes, and pens. This is not being pedantic or facetious, it’s being accurate.
Don’t start with the tool
Start with the minimum you need. It’s often less than you think. Pens and post-it notes will probably work fine. You’re probably thinking “well that might work fine for a little while. But once the system builds up a bit of complexity, and you add another couple of teams, and suddenly there are people from portfolio governance and finance and who knows what wanting to find out what’s going on. What will you do then? You’ll need a tool, of course!”.
There is some merit to this line of thinking, but there is a big problem. If organisational cruft starts building up around whatever work you’re doing, the immediate solution isn’t to enable and feed that beast by buying an expensive tool that provides reporting to nosy people. The solution is to fight that cruft. Use the great principles of Lean Thinking to minimise waste, reduce work in progress, drop inessential documentation, remove handovers. Pull out the weeds, don’t fertilise them. Fight the pressure to use tools, rather than give in to it.
Tools can encourage bad behaviours
Tools like Jira can be useful in some contexts, but they often take the place of conversations and face to face communication. They are information refrigerators, not radiators. Whiteboards and post-it notes are simple, inexpensive, fast and simple to use, and are a locus for human interactions. They also don’t feed into the traditional command-and-control behaviours of organisations. Data and metrics can definitely be useful (I actually wrote a gigantic Ultime Guide to Agile Metrics, if you’re interested) – but they should stay within the team. They should be used for introspection and experimentation, not for feeding into endless reports.
Tools can displace ways of working
Teams should build up their own ways of working that make sense for them without any tools first and then look to see if there are any problems or gaps that tools can fix. Often, there aren’t. Some people start with the tools instead, and then find ways of working that fit into the tools. “Jira seems to want us to create tickets in this way”. “Rally has this workflow system built-in, so we should probably just use it rather than make one up for ourselves”. And so on and so on.
Tools should be used to automate boring processes or fill in gaps – not dictate workflows and story types. That’s putting the cart before the horse, and promoting it to Boss Horsedriver. Start with a small team, minimal tools (i.e. post-it notes), and the minimum set of processes required to get work done. Then see what else needs to be filled in or added.
Tool vendors do not have your best interests at heart
People selling tools have their own agenda. Which is, of course, fine, everybody does – I do, you do, your company does. But it’s important to identify that agenda. Tool vendors don’t just want you to buy their tool, they want to lock you into their ecosystem. They want you to use their workflows, automate everything, load as much of your data into their schemas as possible. Basically, they want to make it as difficult as possible for you to ever leave their little tool world – because then they stop getting revenue from you.
Being dependent on a tool vendor is not good for you or your company. Having valuable data locked up in a proprietary database is not good for you or your company. You want the flexibility to be able to add and drop tools as and when you need it.
It’s not about the processes
The other questions I see asked a lot, this time in LinkedIn groups rather than Quora, is about processes. The questions are usually along the lines of “we’re trying to figure out what to do when [something slightly weird] happens. But we can’t find the answer in the Scrum guide! HELP! What do we do?!?!”. These poor young Scrum masters, with their knickers in a knot. The trainer who gave them their certificate after two days in a room with a few bored colleagues and some butcher’s paper, did they really not give out ALL the answers to life’s problems?
Documents like the Scrum guide have their place, but they do not provide all the answers because they do not know your context. And the amazing thing about software development is that every context is unique. Which means there is no standard process for what to do in every situation.
There is no one size fits all process
There’s nothing wrong with asking for advice. But there’s a mistake to think there is some pre-ordained wisdom lurking in a tome or the mind of a master. Teams are operating in unique contexts, and it’s impossible to figure out what to do without understanding that context. What worked for one team in one company might not work in another. People should try to first figure things out for themselves, based on what they know and what experience and context they have.
Don’t force processes on other teams
Another antipattern to watch out for is a team or group forcing identical processes across an organisation. Contexts can vary not just between companies, but even between teams in the same company. Teams can vary in size, experience, agile maturity, domain expertise, background, diversity, and technology or platform. Just because a team has found a way of working doesn’t mean it’s right for another team. People should always discuss tactics and share stories and learning, but that doesn’t mean forcing everyone into lockstep. Diversity is strength, and consistency is overrated.
Start with the work, then fill in processes where you need them
Just like tools, teams shouldn’t start with processes. They should start by simply doing work: defining and selecting high priority valuable slices of software, and delivering them as quickly as possible. If they find certain patterns that work well, they might become processes. So you could add them into the ways you are working. But if something is done in a predictable repeatable fashion, it is often wise to try and automate it rather than define and standardise it. Software design and development is a creative process, unique each time (and even development is a form of design, remember). Standardised processes can often be more destructive than helpful.
DevOps is a classic example of this, in relation to IT Service Management (if you’re unsure about the difference between Agile and DevOps, I explained that here). Rather than big convoluted processes like ITIL, DevOps aims for simple flexible processes, backed up lots of automation.
In Summary
Tools and processes aren’t evil. Agile says don’t do them. It just says make sure they are subordinate to the real priority: people and interactions. The best way to start building software is to throw half a dozen smart multi-talented people into a room together, with a few laptops and a whiteboard and lots of post-it notes, and leave them the hell alone. Every move away from that basic model is usually a step in the wrong direction.
