Agile+Scheduling

‍‍‍Introduction‍‍‍
toc

Scheduling is "//the process of defining how to commit resources between a variety of possible tasks//" (Sirias, 2009) and focuses on how to deliver the planned functionality and deliverables. In a development phase while Agile Planning looks at "//what needs to be done//", scheduling is concerned with ‍‍‍"//when to do it"// (Szoke, 577:2011).‍‍‍

The difference between traditional and agile scheduling
Traditionally, scheduling is the process which enables the definition of project start and finish dates and is considered an important tool to measure time and other project progress indicators.Cohn (2006) describes it as when various activities will be done and how.

The main difference with the scheduling of agile projects is the ‍‍‍determining of finish dates for the functions or features‍‍‍ (conducted within an iteration), rather than defining start and finish dates for specific activities in traditional project schedule planning (Sliger & Broderick,2008).

In traditional plan-based approaches a rationalised view is adopted and plans are developed up front on the premise that "//problems are fully specifiable and predictable solutions exist for every solution//". Agile scheduling however is underpinned by the following as identified by Szoke (575:2011):


 * "//frequent inspection and adaption where requirements and solutions evolve//"
 * the approach enables the alignment of development with the customer requirements
 * incremental and continuous planning throughout the project

Scheduling in Agile
Szoke (2011) highlights a study where release and iteration planning were identified as ‍‍‍two of the top four‍‍‍ most important agile techniques (of the 19 identified within a 2009 study).

Agile scheduling works in conjunction with both release and iteration planning. Release planning is the overall view of how the team will deliver the product by creating a theme of user stories (features) across a number of delivery stages (iterations). The iteration planning level is a more detailed view of the actions necessary to implement the user stories selected for the iteration (Cohn, 2005), a single delivery stage. The scheduling aspect acknowledges the estimates provided by the team, the prioritisation of features and also any associated risk that may influence further the customers perceived priority of the user stories.

In order to schedule appropriately within an Agile environment the customer prioritises the user stories to indicate which user stories will provide them with the biggest ‍‍‍@business value‍‍ benefits. However, alongside the customers view of priorities there must also be an acknowledgement of the associated risk with each of the user stories. Cohn (2005) advises that the stories which contain the highest risk but highest value should be given high priority. Those stories with low value and high risk should be largely ignored where possible.

‍ Due to the need to assess the customer views on business value and also the development teams insight to associated risk and estimates, it is sometimes the Product Owner who is in the best position to make the final decision about user story prioritisation (Cohn, 2005). With the close working of the customer and the development team this builds upon the Agile value of close collaboration with the customer. Furthermore, with the conjunction of planning and scheduling, this further enhances the view of working software delivery.

Scheduling within Agile Development methodologies attempts to address the common issue of schedule slip within more traditional development methodologies, such as ‍Waterfall‍. By having short release cycles, generally quarterly, the amount of slip is greatly reduced. This coupled with short iteration periods enhance the feedback about progress to the customer (Beck, 2004).

Jefferies (2004) recommends remaining focussed on four distinct areas during the scheduling process:
 * ‍‍‍‍‍Customer collaboration
 * Remaining focussed on delivery
 * A balance of ambition and reality

Sirias (2009) also mentions the requirement to focus on constraints in order to create an effective schedule which he likens to identifying the critical path.

‍‍‍Benefits‍‍‍ of Scheduling

 * Reduction in schedule slippage.
 * Alignment between development and the customer requirements and organisational goals (Szoke, 2011).
 * Flexibility to address and incorporate changing customer requirements at the earliest stage possible.
 * Delivering the highest business value features (Szoke, 2011).
 * Close customer collaboration (Jefferies, 2004).
 * Inclusivity of customer and team
 * Focus on customer value as advocated within lean manufacturing (Sirias, 2009).
 * Feedback for improved future scheduling and planning
 * Acknowledgement of risk
 * Awareness of domain knowledge growing
 * Ability to respond to changes and user requests

‍‍‍Limitations ‍‍‍

 * Cohn (2006) claims that the main problem of agile planning is ‍‍‍estimating the velocity.‍‍‍The project team has three available options to overcome this issue:
 * 1) Plan velocity based on previous experience and historical values
 * 2) Launch an iteration to identify team velocity and review progress
 * 3) Predict the pace of delivery features per iteration
 * ‍‍‍Another consideration is the role of customer feedback at iteration by iteration level. Whilst there may be an overlying theme at release level, this may significantly alter as the customer gains a better understanding as to the product they require.‍‍‍ However Beck (2004) states that by delivering even a subset of the proposed customer 'requirements', the majority or all of the business benefit will be realised.
 * Customer expectations require effective management due to potential issues of under-development and over estimation often experienced within the first iteration of a release and project (Button, 2007).