Chapter 16 - Further Agile
Deprecation of upfront tasks
It's difficult to fully comprehend requirements until system development has begun. However, there is no reason to reject normal engineering practice, ie, study a problem before attempting to solve it; define the architecture before tackling the details.
Iterative development is good - dealing with changing requirements and refactoring - but they do not justify abandoning the initial tasks of analysis and design.
User stories are a useful way of checking the completeness of requirements. However, if they are used as the basic form of requirements abstraction is lost. The resulting systems are narrowly geared to specific user stories and often do not apply to other uses (or users).
User stories are not a substitute for defining a domain model and separating machine and domain properties - what the main people who will be using the software are. The correct priority of delivery working software is not a reason to reject generalisation: Good software developers plan for change; they design flexible architectures that solve more than the problem of the moment.
Difficult projects are not suited to a development process that is simply a sequence of implementations of key features, prioritised according to their business value. Difficult projects require foundational work - building architectural elements such as communication and persistence layers that extend across features.
Features interact according to their dependencies, which unmanaged causes complexity of a multiplicative kind. Well defined, coherent architectures keep things manageable.
Rejection of dependency tracking tools
Projects that skip analysis of task dependency do so at their own risk. Advice to stay away from Gantt charts and dependency management tools is naive and detrimental.
Such tools are not a panacea, but they have proved their value over time.
Rejection of traditional management tasks
While self-organising teams, with no managers assigning tasks, are the best solution for a few teams, the approach is inappropriate for many others.
Test first development is excellent, so is refactoring. However, the repeated execution of the basic steps of TDD can't be taken seriously. It leads to tunnel vision and a focus on the latest test.
An effective process needs a high-level perspective and consideration of the entire system.
Deprecation of documents
Criticism of document-heavy processes, with no customer benefit, is certainly justified for some industry segments. But, with mission-critical systems, documents are legally required by certifying agencies. Modern programming languages can incorporate design into the code itself. However, as a form of engineering, software engineering needs a predictive approach and the supporting documents.
- Pair programming: applied occasionally, but no evidence that it is better than code reviews or should be the sole means of development
- Open office: so long as communication is maintained, there is no single, optimal setup.
- Work at a sustainable pace: but often organisational and financial pressures impinge.
- Minimal functionality: don't let projects become bloated - but removing functionality from a big system will inevitably lead to complaints.
- Planning poker: interesting but prone to intimidation and not a substitute for more scientific approaches. Eg, people not being able to express their views clearly.
- Cross-functional teams: good for broadening everyone's experience, but sometimes specialised areas require specialists' skills.
Take a second look, improve the design. Eg, spotting commonality, use inheritance.
As a substitute for design, refactoring is bad. But as an accompaniment to the initial design, it is good.
Short daily meeting
Simple verbal progress reports - the three questions. Brings in a verbal contract, a commitment, between the team members. It promotes team communications - ideally with team members in the same location. Good for identifying issues
- Short iterations: constant feedback
- CI / Regression testing: don't break the build
- The closed window rule: no functionality added during an iteration
- Timeboxing: deliver on the deadline - even if some features aren't implemented
- Product owner: A rep on the team from the customer organisation who decides what goes into the product.
- Delivering working software: maintain a running version
- Velocity / Task boards: maintain regularly updated evidence
- Regauler testing