[agile] Agile in the Trenches

Agile is

Agile is not

Lots of face-to-face communication at the right time.

Constant interruption.

Constant review and simplification of the process.

Ad-hoc, no process at all.

Developing from English-like User Stories.

Development from high level requirements or use cases which the Subject Matter Expert (SME) can't understand properly.

SME is part of the team and is allocated at least 25% to help out the project.

SME is part of the team for the first week but is then allocated (or requests to be moved) to another project.

Progress is tracked by looking at the burn-down chart and velocity, using story points.  Other than for calculating how many iterations were possible to fit in the timeline, the initial indicative project plan for development was ignored by the programmers until completion of the build phase.

Progress is tracked by hours worked on individual tasks and from the burn down chart and itemized in three different timesheets and in a task tracking system and on a project plan.

When any of the above didn't match exactly, the developer in error was asked to explain why.

Clear communication to all stakeholders of how the development is tracking, for better or for worse.  The project leads made sure the business stakeholders were involved as soon as there was something to look at.

Business stakeholders first looked at the application in the last iteration and had some nasty surprises and a large number of changes.

Variable scope.

It is natural for scope of a project to grow as more information is revealed, since it is impossible to capture all requirements at the beginning.  Desired functionality won't work as planned, back-end data won't be available, user interfaces too confusing, products will fail to deliver the goods.  All need to have workarounds or the software won't be successful.

Fixed scope.  

All the stories required for completion of the project must be on a story card by iteration one. No new stories are allowed without a heavyweight approval process.  

To allow the software to function, programmers are forced to sneak in new stories using spare time between iterations.  These secret stories can't be formally tested because then there would then be reporting visibility of them and they'd get In trouble.

A clear vision of what the project outcome needs to look like and how it is going to be put together. Clear workshops, investigation, high level architecture and goals.

A fuzzy vision of a number of directions the project might take and then code like hell to see what the result is. This approach wastes a lot of money and often fails but is surprisingly common.  

Theoretical Agile

Real Agile

Scope is variable

Most companies need to go to the board to get funding for an IT project. In order to release cash, the board naturally wants to know exactly what they will get for the money. There is usually a fine balance where changes are carefully negotiated with the business stakeholders.  

Everyone who has something to deliver for the project comes to the morning standup.

It's very unusual to find a company where every department is able to act in an Agile manner.  Infrastructure teams are usually not agile and won't come to standups so some members of your team will be less productive at times to manage those external parties.

The architecture of the solution can evolve to be simplified or get more complex if needed.

Infrastructure teams and architects often need the solution documented in high detail before development starts, in order to secure the necessary approvals in time for go-live.   Unless architects are open to wholesale changes to the design, it's pretty hard to alter anything without lots of additional documentation and approvals.

Estimations are done using story points which have no time component.

Developers still think of tasks in terms of days.  There is usually an “exchange rate” at estimation time of days vs story points.

Pair programming

(arguably XP, but still relevant to Agile)

Pair programming is a useful way to skill up and mentor junior developers, but most good members of teams work faster alone. Unless the software will be used to to run a nuclear power plant, it is almost impossible to justify the perceived additional cost to the business stakeholders.  Programmers are expensive.

100% code coverage

Full code coverage can make refactoring efforts unreasonably onerous to the point that developers avoid making important changes.  A codebase with Junit tests that take ten minutes to execute will slow development to a crawl unless those tests are only executed as part of the continuous integration build.

Keep Junit tests for the important tricky pieces of code only, such as rules engines, calculations, date manipulations, not for Controllers or getters and setters.  

Instead robust Selenium tests are used to exercise whole vertical slices of the application, right through to the back-end.  

Showcases at the end of every iteration.

Unless there are new obvious features being delivered, all parties can agree to skip the showcase, especially if all the bug fixes have already been desk checked by the SME.