Project management recommendations #

Understand what the customer wants #

Best to get feedback from the customer. You should not rely only on the customer proxy.

Get formal as early as possible #

Questions come up when drawing the domain model. Even semi-formal texts like Use Cases, risk list or tests add value.

Stable requirements from start to finish are an illusion, because software is always something new — the old would be bought ready-made.

The scope should be fixed at the latest at the time of End of Elaboration, otherwise it will be difficult to adhere to the four project variables. Therefore, no project for more than nine months. If it takes longer, then make several projects out of it and work through it sequentially.

The project manager must have the scope under control. #

The four project variables #

cost/effort
time
functionality
quality

If there is not enough time, the project scope can be reduced or split into sub-projects, which are then processed sequentially.
Alternatively, the schedule can be extended
More people rarely works (Brooks’Law). Because these people must first be must be trained, must understand the solutions that have already been created, and must not then must not get in each other’s way.
No dirty solution, as this then becomes technical debt and then catches up with you catches up with you at some point.

Software is communication intensive #

Management by walking around. Otherwise, another wiki and/or daily standup meetings.

Distance is expensive #

Dr. Dobb’s Journal, December 02, 2008, http://www.ddj.com/ “The Distributed Agile Team - Communication challenges are your greatest risk”, by Scott W. Ambler

Go to the site every day #

Who is doing what?
Who is on the site?
How far along are we?

Besides, so is the construction site:

The program code
Version control tools: Who does what? What is touched often?
Bug tracking
Architecture documents

Priorities #

There should be a definition of priority.

Always proceed iteratively #

A positive feeling is created by the intermediate results.
Continuous integration is easier than big bang integration
Errors and misconceptions are detected earlier.

Feedback from the customer #

Inspect - Adapt #

Scrum knows the terms “Inspect - Adapt” for this, i.e. you look at how things stands, and adjusts if necessary the direction.

Project control #

Budget control plus progress control Management by walking around; Presence creates commitment No diving off (for three weeks now programmed Joachim…)

Regularly write down:

Milestones (achieved/missed)
Number of employees
Money spent
Difficulties encountered
Special incidents

If you regularly make some kind of dump of the whole project data, then you can later understand how the project went.

Daily Build #

Continuous Integration are daily builds that run every time someone commits a change to the main pushed a change to the main branch of the repository, which can — and should — be the case several times a day.

The usual tools #

Version control
Work package management
Unit testing frameworks
Metrics and code checkers like findbugs, checkstyle etc.
Separate build server

Build Breaks and Branches #

“Branch or not to branch”, not too many (central) side branches, because branches can greatly dilute the point of “how far along are we?” .

At least daily build and regular releases: every 2-3 weeks for the team during the sprints, with demo for the customer proxy; every 2-3 months for the End customers for testing. Rollouts for end customers sometimes happen even less frequently, it depends on the environment.