Agility is very important to me. In terms of computer science and managing application project management, from design to completion to maintenance, agility is one of the most valuable elements to large scale software design. I’m not sure if people know what it is exactly, but TDD, extreme programming, and the like all try to obtain maximum amounts of this sacred resource.

What is Agility?

Agility is the ability to move with speed, efficiency, and make mistakes and correct them in record time by knowing more about what failed. Imagine an application, or anything for that matter, where you can make a mistake and only be punished by 5 minutes of corrections. In that scenario, you can make any mistake you want and it’s not a game changer, difficult blocker, or any serious issue that slows down your team (*cough* adds to the critical path). That world is obviously impossible to obtain (at least currently) due to architectural decisions like language choices, frameworks, etc. but we can at least try to maximize agility after these choices have been established.

How do you maximize agility?

The key to maximizing agility depends on your project. In software, if you follow extreme programming you’ll get there. Here are some of the key points:

  1. Sit together / Be there in person

    You need to be comfortable with your team; you need to succeed and fail together. We build things for people and the relationships on your team are important. It’s okay to have teams offsite etc. but as long as those teams also sit together and work together, they will benefit from this as well. Otherwise you spend far too much time travelling, typing, and misunderstanding people over IM rather than communicating instantly, receiving feedback instantly, and discussing things instantly. People need to get feedback instantly from someone else so they can build things the right way the first time.


  2. Remove the friction — Say bye to cubes

    Cubes are the worst office invention ever. Examining the flow of information between a cubicle world and a non-cubicle world is virtually night and day. Overhearing conversations might be the BEST way to transfer knowledge and get those who know the answers or those who would like to learn the answers trained in a passive way. Cubes on the other hand are obtrusive to this kind of environment. As a rule of thumb, don’t put them in an office unless they really need to be on the phone consistently (sales/Bdev) or working on sensitive, confidential material.


  3. TDD

    TDD is not absolutely necessary to having agility in the office but it is nice to have. TDD buys you confidence, knowledge, and potentially faster debugging times. In a perfect world, you would write the minimum test first, break the test, make the test pass, and do it over until the application is complete. This keeps you focused on the task at hand, causes you to write less code, and keeps you moving forward as you design and develop new features. Unfortunately, the real world isn’t so linear. You have to go back and forth as requirements change (agility), and you end up changing tests numerous times making you wonder if you should have wrote so many in the first place. At the end of the day, it’s a two edged sword. It causes you upfront time costs but I strongly believe it’s worthwhile in the end.


To be continued…
In my next article, I’ll write about the engineering team, having customers on the team, the general makeup of a team (with an emphasis on startup vs enterprise), and more to come in later posts…