An example of the kinds of things we teach and talk about at conferences.
The 7 Deadly Sins of Software Agility.
Everyone has heard of the unicorn Agile team who moves at lightspeed yet when businesses
try to implement Agile processes they often fail. This list highlights the most common
problems that we've seen with Agile implementations in our clients.
#1 — Lack of Commitment
One of the most dangerous myths surrounding Agile is that it can fit snugly within your
existing engineering processes. This isn't true. The core elements that make up an Agile
framework are heavily interdependent, and removing them in an attempt to keep your existing
processes will result in greatly diminished returns on your investment.
#2 — Poor Team Stability
There are few things as damaging to your team velocity as team instability. Agility
depends on well functioning teams that have taken the time to gel. Every time you hire, fire,
or move someone between teams, you will experience a nose dive in productivity. This is
especially true of startups who have high contractor and consultant turnover.
#3 — Poor Testing Habits
In the very early stages of a startup, investing in well tested software is a
mistake. The point at this stage is to validate the business. You should build a quick,
and dirty prototype. However, it would be a mistake to take that untested and
unstable prototype and try to shove it into production. Throw it away! Building
the same software from scratch in a test driven approach will net you huge
gains (often a lot sooner than you think).
#4 — Blocking Code Reviews
We're big fans of code review at Blueshift. We review each other's code
constantly and we pair together on solutions as many chances as we get. However,
we often see code review being abused by teams as a collaboration tool.
Teams should collaborate before a single line of code is ever written, not
after the code is written and submitted for review. Code review is a place
for empathic feedback, mentorship, and learning. It should never block
others from getting their work done.
#5 — Refactoring Too Early
This is a big engineering canary-in-the-coal-mine. Agile tells
us to avoid big up-front design. Still, many programmers when
given requirements for simple problems build large complex (and
sometime convoluted) software architectures. Nearly always,
a simpler more straight forward approach is superior. You should
never do more work, than what is required to meet the current
#6 — Not Refactoring Enough
However, all code eventually reaches a size where it becomes increasingly costly
to implement new features. One of the worst things you can do is
ignore this and pile on tech-debt. Unlike most debt, tech-debt has a very
high interest rate. It should be sought out and destroyed as often as
possible. Your team should constantly be reworking, refactoring, and
rearchitecting the codebase as new features are implemented.
#7 — Fear of Failure
You are going to introduce bugs in your code, you are going to miss
deadlines, and you are going to eventually put breaking software into
production. It happens to everyone, and it is unavoidable. The key to
success, is being able to respond to these mistakes as fast as possible.
Be bold. Try risky things, but have an engine in place to recover
from them quickly. If you are delivering every day, and you break
something, it will be broken for a day. If you are releasing once a
month, and you break something, it will be broken for a month. You're
going to break something eventually, so you might as well move fast.