4 Asking the right questions

 

This chapter covers:

  • How to use knowledge of the “dark arts” of project planning and management to benefit the practice of Agile
  • How to use lines of communication with your colleagues to collect planning information
  • How to use aspects of waterfall style project planning to create concise planning notes
  • How to use planning information to estimate project feasibility
  • How to create milestones that help organize interactions with colleagues outside the project team
  • How to handle cases where preliminary planning indicates a project is inadvisable

Open lanes of communication with key areas of the organization outside the project team are required for a project to be successful. Now an Agile project manager needs to ask the right questions, and communicate the right information to their colleagues.

Agile is intentionally adaptive. However, Agile is not very predictive beyond the short time horizons of implementation iterations. Over the course of a project, project teams may acquire enough experience to feed into an analysis of how the team is performing within the project. But, even with experience-based analysis, software tasks remain unique and therefore hard to measure and compare. It is never too late for surprises in software development.

4.1 Adapting Agile

4.1.1 Identifying fake Agile

4.1.2 Communication is key

4.2 Studying the dark arts

4.3 The old scriptures

4.3.1 Keep it under your hat

4.4 Foresight and immovable objects

4.4.1 Do not eat the seed corn

4.4.2 Launching a product is not an Agile project

4.5 Distilling requirements from early-stage descriptions

4.5.1 The vision behind the project

4.5.2 Use cases gather information without requiring precision

4.5.3 From use cases to requirements

4.6 Scaling requirements to the project setting

4.6.1 Challenge requirements

4.6.2 Answering requirements in the functional specification

4.7 The feature and benefits list

4.8 Design documents

4.8.1 The qualities of an implementation

4.8.2 How to build it

4.8.3 Do the implementation risks make sense?

4.9 Look, feel, sound, and movement

4.9.1 Visual design is easier to start early

4.9.2 Do not overemphasize looks

4.10 Tasks: the individual steps to getting to the goal

4.10.1 What resources are needed?

4.10.2 The resource conundrum

4.11 Waterfall test plans and an Agile approach to testing

4.11.1 Waterfall test plans

4.11.2 Testing in Agile projects