Category: iterations

Fighting fires the agile way

March 5, 2008 by cspag

Let's face it, no matter where you work, fires flare up from time to time. Some are serious and need to be addressed, some are just smoldering and can be put off for a short time, and some are just people yelling fire when there is no fire. Some organizations are perpetually in fire drill mode and can't break the habit. So, if you're an agile organization and your agile teams are committed to completing their iteration tasks, how do you fight these fires without interrupting your agile teams Even if you allow a buffer of time within your iteration planning for handling unexpected requests, you still run the risk of distracting your development teams with potentially harmful context switching.

Micromanagement in Agile/Scrum. Sprint to sprint control

February 15, 2008 by Artem Marchenko

There are not that many people who like micromanagement. No surprise that the fear of day to day micromanagement scares some people off the agile processes. That is not the only way agile processes can look micromanaging. All the agile processes employ the idea of iterative and incremental planning on pretty much every possible level. Scrum Product Owners can change the project priorities every 14-30 days, in Extreme Programming, the usual iteration length is just one week. Naturally the possibility for the rapid shifts in the priorities can make it difficult for the team to design and build a good architecture and work at a full possible speed.

Is Iteration Zero a good idea?

January 17, 2008 by cspag

As I've been contemplating moving agile throughout our entire organization here at Data Transfer Solutions, I've been considering the usefulness and effectiveness of an Iteration Zero. Many agile teams use what's known as Iteration Zero to put the necessary systems in place to enable the delivery of value to the customer. It's essentially the getting started iteration. It takes place before any development begins. I think Peter Schuh described Iteration Zero very well in his book Integrating Agile in the Real World. Peter says:

"An iteration zero does not deliver any functionality to the customer. Instead the project team focuses on the the simple processes that will be required for the adoption and use of most agile practices. From a management point of view iteration zero may include:

• Initial list of features identified and prioritized.
  
• Project planning mechanism identified and agreed upon.
  
• Identification of and agreement upon a team customer, essential stakeholders, and business users and the nature of iterative planning process, such as the time of planning meetings and the length of iterations."

Velocity: Measuring and Planning an Agile Project

December 10, 2007 by Jeremy Weiskotten

Bridgekeeper: “What is the velocity of an unladen swallow?”
King Arthur: “An African or European swallow?”
Bridgekeeper: “Huh? I don’t know that…”

- Monty Python and the Holy Grail

One of the most important metrics of an Agile team is its velocity. (No, you don't have to give the receptionist a stopwatch and do laps around your office.) In project management terms, velocity is the amount of work that a team can complete in a specified period of time.

Unfinished work

November 21, 2007 by Artem Marchenko

Agile processes recognize and try to effectively use the fact, that software creation is a difficult and not very predictable process. Therefore quite often teams applying agile processes end up with the not completing all the committed product backlog items by the iteration end. Teams just starting to employ Scrum or XP can sometimes end up with half of the items being not completely done. Naturally in such a situation people are tempted to finish the uncompleted stuff as soon as possible. Some think about extending the iteration length for a week or two, some think about marking the item half-done, adding half of its size to the team velocity and continuing with it during the next iteration.