What happens if we don’t do it? – 4 ways to speed teams up

I became Certified Scrum Master (CSM) on 2010. I took a CSM course at beautiful Oporto. My instructor was Mitch Lacey (https://www.mitchlacey.com/). Amazing instructor. If you can attend any of his courses, go ahead. On 2012, he published an amazing book about Scrum, I totally recommend, “The Scrum Field Guide: Practical Advice for Your First Year” (http://www.amazon.com/Scrum-Field-Guide-Addison-Wesley-Signature/dp/0133853624). So practical, so full of examples to understand how to properly apply Scrum and get most of it.

During the CSM training session, when talking about INVEST (https://en.wikipedia.org/wiki/INVEST_(mnemonic)) in your product backlog, value of User Stories and priorities he said, “the first question to ask yourself about a user story, task or process is what happens if we just don’t do it?”. Everyone laughed. Not doing something useless you were supposed to do, it’s a high productive activity.

The more I meet teams, project managers, developers, sysops, etc., the stronger my feeling is that we always try to improve things adding stuff not removing waste. More process, more abstraction, more code, more tools. My recommendation is that the best way to speed teams up is to remove useless or low value things. Let’s see some suggestions.


Distributed Agile is sort of trending topic. We live with multinational companies, distributed teams, remote work, etc. In software development, the #1 rule of distributed systems is don’t distribute. Agile is not an exception. “Hey! To solve that let’s add more communication tools (Slack, skype, more emails, notifications hooks, hangouts, etc.)”. Wait a minute…

Screen Shot 2016-05-06 at 20.33.50

Why we don’t just arrange our products so they can be developed by colocated teams? Less tools, more effective communication. Agile is all about communication. Try to maximise the number of people colocated with whiteboards so we’ll need less tools.

It is all about communication

One related point about Domain-Driven Design or Microservices is that both try to increase overall company productivity defining boundaries for your product that can be developed by focused teams. Distributed architectures are complex, so why do they make sense? Because overall productivity is higher than complex monolithic apps maintained by single teams.


Last but not least, just a mention about the Agile Manifesto (http://agilemanifesto.org/), “Individuals and interactions over processes and tools”. It still amazes me how two developers, a developer and PO, a developer and a QA, etc. can be having a conversation by email, IM or in a Pull Request when they are sat down next to each other. Bravo!

Project management

I would like to remember that in Scrum there is no project management role. When things are on track, everyone is happy, but when things go wrong or risk, “Hey! Let’s add a project manager, or even better, let’s include a new workflow in Jira to control“. Wait a minute…

What about removing project management and coach the team to be really self-organise. Tackle the origin of the problem, do not compensate who is not behaving professionally. What about removing the Jira and just put post-its in the wall? I would like to make a special mention to team metrics, measuring throughput or velocity. Gut is what matters. Velocity is a helper for your gut and team’s gut. Iterations are fire and forget, don’t invest time in tracking, saving those metrics. How many times have you checked a previous sprint for some information?


At the office, people work less. When developers work at home one day because the plumber has to fix something, it’s a high productive day. Less distractions, meetings, noise. Just the developer, her computer and User Stories. Before adding any meeting or additional step in your development process think for a while, is it really needed? what could happen if we don’t do it? My suggestion is try to maximise the number of time developers are writing code (writing tests, discussing on the whiteboard about the technical solution, deploying to production, etc.). Sounds obvious, doesn’t it? Actually, it’s not. It’s difficult for me to understand how some developers can be developing for more than two hours without getting disturb by a silly emails, chat messages o non related meeting. Retrospectives are a really nice place to talk about how the team could be more focused.

Keep the teams small. Smaller, more focused. More people you add, more the chances of being interrupted. This does not happen linearly, but exponentially. Consider each possible type of interaction: chats, emails, conflicts, merges, bugs, unit testings, etc.


Technical trade-offs

“Pragmatism vs. Dogma”. I have seen both scenarios. As an example, I’ve met a team that didn’t write a single unit test. “Bosses don’t let us write tests”, “It slows us down”, you know this song. On the other side, I’ve met teams overtesting everything: Domain, Infrastructure, Integration, UI, etc.

Is it worthy to unit tests a Javascript UI? Is it worthy to unit tests a component that interacts with a database but no business logic inside? Is it worthy to unit tests a third well-known library? The answer is “it depends”.

Writing tests takes time but if we decide what to test correctly, we will save a lot of time. When talking about testing, just be careful about not being writing fragile tests that break often when a refactor is done (without behaviour change). If your UIs are silly, do not contain any business logic and relay 100% in a API, you should not invest the time unit testing them.

Beyond the testing, my suggestion is stop doing a process not high valuable, see what happens with your bugs and your productivity. As my mother says, “don’t say you don’t like something if you haven’t tried at least 3 times”. Stay or rollback the decision. It’s a trade-off.

You don’t wear a helmet when walking around the city just in case of a falling brick. Because it happened once or never, that does not mean you have to add checks or steps in your development process that will take time and make it slower. If you have a proactive monitoring and a fast rollback, you should assume some outliers situations where you could react fast rather than overprotecting. There are probably some exceptions, nuclear fission/fussion, for example.


Don’t push developers, remove the waste. Remove useless things. Remove tools, processes. See what happens. Don’t add. Enjoy being faster and more effective.


  • Iain Argent

    Brian Tracy also recommends prioritising in this way in his “21 Ways to be More Productive” tape. I’ve always found it difficult to get business people to engage with this kind of thinking, though. The response to “What are the consequences if we don’t do it?” is simply “But we have to do it!”.