Big BangWhen it's time to build or update an app, many businesses use an approach I call "Big Bang Agile"-an approach that tends to create costly, long-term issues including doubts about the value of Agile. The problem is not that Agile is deficient. Rather, it's that the Big Bang approach is an anti-pattern.

Big Bang Agile involves standing up an Agile team for a burst of work on a project and then driving hard during that burst of work, with visual assets such as wireframes and screen comps delivered just in time, services delivered just in time, and so on. When the app is complete, the organization quickly dissolves the Agile team. The app is then left to stagnate with little to no maintenance or improvements waiting for the next burst of activity around a new major initiative.

This leads to multiple problems:
  • Significant technical debt. Architects and developers typically aren't given sufficient information to design the app correctly, nor are they given time to fix the app during the burst of work. The team isn't given time to go back and fix technical debt, nor is it allowed to fix problems once the project has been delivered.
  • Software rot. When you build a house and fail to maintain it, the house will fall apart prematurely. When you build an app and fail to maintain it, the app doesn't fall apart; rather, our memory and perception of the app fall apart. The team that developed the app forgets how it works and where the unresolved problems are. With the code poorly understood, any changes to it will be higher-risk and more likely to cause defects.
  • Increased costs. The next time you approach the code base, you can expect to spend more time and money rediscovering it, given technical debt and lack of institutional memory. If the next encounter is for another burst of work, the technical debt will go unaddressed, adding to the already accumulating technical debt to the point where the code base become unmaintainable and must be replaced.

There are several steps you can take to avoid these problems.

Maintain a team responsible for providing at least some ongoing upkeep of the app. If you let an app stagnate, the technical base suffers. Moreover, your customers will notice the lack of attention paid to the app. Your team-even if it's just one person-can grow or be augmented by other teams when you need to develop significant new features. Ideally, you'll find that development activity will shift from a hum, to a buzz, to a roar, back to a buzz and then settle at a hum between periods of major feature development.

Take the work to the team instead of building the team around the work. If you are constantly building and tearing down teams, you will spend large sums on recreating team dynamics, camaraderie and communication. Maintaining standing teams that can become productive immediately will save you considerable money and enable you to deliver value to the business quickly, a major objective of agile.

Provide developers with the full roadmap. It's critical that you provide as much vision for the app as possible to the development team. The more your developers know about business expectations for the app, the better they can build the foundation or technical architecture on which it rests. This does not mean that the developers need all the requirements up-front, but the more they know about the features and high-level interface concepts, the better they will be able to design the foundation of the app. The better the app foundation, the less time the team will spend in rework to accommodate changes. This vision should be repeated periodically, maybe every quarter, to not only remind the team but to enable ongoing updates to the architectural direction.

Foster a culture of craftsmanship. How something looks on the inside affects how it looks on the outside. If the code inside an app-the part never seen by the customer-is a mess, that mess will eventually work its way to the surface, where customers will see it. A major reason for Apple's early success was that the founders cared deeply about detail and craftsmanship, creating products that were as beautiful on the inside as the outside. If your organization doesn't foster a culture of craftsmanship, customers will notice. If you have a culture of craftsmanship and for some reason you find yourself engaged in a Big Bang Agile project, the negative impact won't be nearly as great, because you'll be starting from a good foundation.

Take care of technical debt. Schedule time during major feature development sprints for technical debt remediation sprints. Some organizations do this during innovation and planning sprints, or allocate extra time in each sprint for refactoring. This will save you grief if you do undertake a Big Bang Agile project, as the amount of time and money spent fixing previously overlooked technical debt will be limited.