WASHINGTON, DC – There is a lot of buzz around town about agile: being agile, wanting agile, doing agile. Some say that agile is not all its cracked up to be. Others say they want agile but when you ask them what agile means, they can’t really put their finger on it. Some say agile means that things get done fast, or that developers are responsive, turn on a dime, and are open to change (change of mind, change of requirements, or even new requirements mid-stream). Some people think that agile means new requirements reported at 5 pm tonight will be done by tomorrow morning.
For us, agile means a couple things…
For one, it means that if you want to fix (freeze or lock-in) any project management variable, i.e., budget, timeline, scope, quality then you have to have fluidity in one or more of the other project management variables. Likewise, if you want one project management variable to be firm, then one or more of the others must be flexible. For every fixed or firm project management variable you need another to be fluid or variable. If price is fixed then scope or quality needs to be fluid. It price is firm then timeline, quality, or scope needs to be flexible. If any of these are firm or fixed then their counterparts need to be fluid or flexible.
That’s agile.
For another, it means that we are open to change – after this sprint is done. It also means that we have some structure in the way we work, i.e., sprints, Kanban, user stories, standups, retrospectives, continuous integration, test driven development, velocity, burn rates, and pair programming. So, when we talk about agile, we have a common understanding of what these terms mean and we all practice these regularly and methodically as part of the way we do business. This structure helps us do a better job of delivering predictable results, increasing transparency, managing expectations, and getting shit done.
That’s agile.
