Considerations on Planning and Architecture

Abstract

In agile planning you are counting on what you know you definitely have. Depending on the type of project, you are either given a number of resources by your management to do the project, or, as in a services contract, there is a certain amount assigned for resources that you better not overspend. The time constraints will be fixed as well. On the other hand, requirements will be a moving target. Therefore the plan is fluid and includes only a rough estimate of those requirements that might be achievable in a prioritized order. Content is the parameter to adjust when adapting to change. The actual deliverable will be the best that can be accomplished within the given timeframe and with the given resources. Each team will figure out how to accomplish as much work as possible. In contrast to this, traditional waterfall project management teaches just the opposite approach: You start with gathering the list of fixed requirements, then estimate the cost and time needed to implement them. This approach ignores that in most cases, resources and dates are non-negotiable given constraints. The content delivered by the team will always be confined by the team size and available time, regardless which requirements you commit to address in your specification (Fig. 6.1). If the requirements are fixed by management as well as the dates and resources, this is neither waterfall nor agile, but simply unprofessional and a setup for failure. The team will be doomed to fall into a never-ending emergency mode, which is not sustainable and will offer quality decrease as the only way out.