How agile are you? Are you doing the common agile practices but missing the point behind them? Here are three questions to ask yourself:

A major goal in agile is to stay releasable. Do a little. Get feedback. Do a little more. In fact, a great question to ask is what would prevent you from releasing what you have now? The answer can help you highlight areas where changes might have a significant benefit. Look at each thing, prioritize it relative to the others and then try to change so that each item is handled during each iteration.

There's a notable difference between working for a start up and working for a large company. One major distinction is focus. Start ups that aren't focused don't tend to last long. Large companies can afford to go many directions at once. But they often do so at a cost. By fighting against themselves with cross purposes they lose some of the leverage that their size could provide.

Stories represent business value. If you accomplish them, it will help the business. Tasks, on the other hand, are a means to track what must be done to accomplish those stories. They can be really helpful in communicating what work remains and coordinating on who does it.

Quick. What's the point of estimating stories? If you said determining how long they will take to implement, you only got part of the equation. In addition to helping the team to project the contents of future iterations, estimation can be an invaluable way of getting the team up to speed quickly on what is coming soon.

Iteration demos are a great way to show the progress that the team is making. They can help to keep the extended team up to date on the state of the application. They can generate feedback on where to go next. A few tips to get the most out of them:

Your organization has skills and areas of knowledge. Each person (or group) is good at something. You might take this to mean that the best strategy would be to give them something to work on that matches that expertise. That seems most efficient. Give them something they're good at and they'll get the most done, right? It depends on how you define efficiency. If it's how much they output per unit of time, maybe so. If it's how much business value they output per unit of time, maybe not.

Many companies claim to be agile. If you look at their practices, a lot of them are pretty far from what most would consider ideal. Where do you draw the line? What threshold do you have to cross to claim agility?

Traditionally, we've categorized requirements as "musts", "shoulds" and "frills". In theory, the musts had to be there to ship. But in reality, many of the musts didn't make it. And unless easy or sexy to the developers, you can forget about the shoulds and frills. So who decides which musts make it? In the absence of someone working with the teams to prioritize things to a finer level, it is determined by the order of attack of development. Those not done yet when things start to look bad get thrown out.

Agile solves this problem by ranking the requirements (typically in the form of stories). If you could only have one thing in the release, what would it be? What if you could have two things? Etc. This ensures that you're attacking the most important things first and that if you come up short, it will be the least important things that get left off.

I attend a lot of meetings. That's not a bad thing. Meetings can be very productive. They can be an opportunity to get the right people in the room and quickly make decisions or convey information. But they can also be a waste of time.