Information Technology Reference
In-Depth Information
While Agile projects do plan, they tend to produce a higher-level plan early
7
[4], and then detailed planning in short increments. At the end of each incre-
ment, they use the additional knowledge gained during the increment to
make the most effective plan for the next increment. The schedule evolves
with the evolving incremental plan.
One of the common pitfalls when executing incrementally is to push off
work, thinking it is lower priority because people think it will be easy to do.
The key to success is balancing the focus on the high-priority work that
needs to be done now, while keeping an eye on the big picture and reducing
risk of unknown areas where analysis has not yet been completed.
8
In the
BOND workshop, we used typical scenarios to help train project leaders in
the ramification of incremental and evolutionary development.
At BOND, we required a complete, high-level project schedule indicating
major milestones at the start of each project. This schedule would be main-
tained. Recognizing that the current real work was being managed through
the day-to-day
standup meetings
and
visible task lists
that were institutional-
ized in the organization,
9
we explained that we did not encourage great
detail in the master schedule.
LESSON 3
A common pitfall in both Agile and traditional development organizations is
building schedules early with too much detail too far out, leading to incon-
sistencies with real on-going work.
The purpose of the master schedule was to ensure that all stakeholders,
including the customer and senior management, understood the big picture.
This schedule was used as a
reminder
of major commitments to ensure we
weren't adding unacceptable risk by pushing off work that should be
addressed earlier. We trained project leaders in the specific scheduling
guidelines that had been agreed to relative to the master schedule, the level
of detail, and which details should and shouldn't be included to keep the
master schedule current without unnecessary effort. Refer to Table 5-4 for an
example of schedule guidelines similar to what was used at BOND.
7. Reference “Coarse Grain Planning” described in
Crystal Clear
. See the reference for more information.
8. In the DART case study later in the topic, this common pitfall is discussed along with a practical
approach to help avoid it.
9. Most projects used Scrum practices at BOND. Daily “standup” meetings and visible task lists are com-
mon Agile practices. These practices are discussed further in the DART case study.
