What is Hyper-Agile?
Now before you get too excited, let me explain what this means. Hyper-Agile is a term I’ve come up with for an agile organization that has become so obsessed with rapid prototyping and iterating that its processes start falling through the cracks. While it is perfectly acceptable to move fast and break things, in the extreme it can destabilize the fundamentals of the software and ultimately hurt your work quality. (Edit: I found out that Facebook has now appropriately announced to its new mantra as move fast with stable infra. I will touch on infrastructure destabilization in this article).
Hyper-Agile’s Susceptibility to Tech debt
It takes an exceptional PM to recognize the impacts of tech debt and the importance of making sure all fundamentals are covered. Tech debt, like any other debt, if not addressed will eventually accrue interest. If you over look some process in this sprint, it will more than likely come back to kick you ass in the next sprint. Some especially troublesome tech debts to watch out for are:
- Doing a hack job instead of doing it the right way.
- Branching and merge conflicts
- Security backdoors
As mentioned before, it is vitally important for the PM to ask for and understand the impact of each tech debt. While indeed it is sometimes difficult for the PM and engineers to agree on a schedule, it should be the engineer’s responsibility to voice any concerns of tech debt. Everyone is responsible and should be held accountable.
I strongly suggest PM’s folks read up on The Joel Test, a classic write-up on what should be part of every engineering organization to understand engineering’s challenges.
So you may ask, is my company hyper-agile? Here are a few symptoms to watch out for:
Organization becomes QA-dependent
A rule of thumb is this: Quality begins to suffer when things move too fast. Engineers typically write unit-tests and perform periods of development testing to ensure that the quality of software is acceptable. However, when an hyper-agile organization bites off more than it can chew, what often happens is that the QA becomes more and more relied on to ensure quality. While the QA does have an important role, they should not be the sole stopgap when it comes to quality assurance. In some companies, there are no QA’s at all, so one can imagine the how destructive hyper-agile behavior can be.
Poor and neglected infrastructure
Another characteristic of a hyper-agile company is when there is poor or neglected infrastructure. When an organization moves too fast, both software and physical infrastructure are impacted. Things as simple as the development of an integrated test build job, build machine, and even a quiet environment for the engineers to work at are often forgotten when there’s not enough time to deliver committed features. These are the kinds of sacrifices that should not be made and can have tremendous impact on your work quality.
A result of poor infrastructure is that there’s less time for documentation from all departments. This can result in more unneeded Q&A sessions and an abundance of throwaway code, just wasted labor. Some symptoms of having poor documentation and scaling issues:
- Bug-tracking system doesn’t work as well JIRA, FogBugz and other systems all rely on good documentation of each bug and diligent status updates. It makes management’s job easier as well.
- It is harder to get people up to speed. Without good documentation on the engineering infrastructure and domain knowledge, it can become very time-consuming to lead or train.
When there are aggressive deadlines ahead you need a team that is willing to work harder and to push themselves. A hyper-agile company is often unable to weather that kind of stress, especially when the engineering processes are being constantly skimped. And so for those few standouts that are actually working their asses off, a hyper-agile company can often overlook them without a formal process of committing and scheduling. The result? Unhappy and under-appreciated employees.
Originally published at productmike.com on September 19, 2014.