[agile] Agile on the ground

Agile is

Agile is not

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

Constant interruption. Complex code needs some quiet time.

Just-in-time communication with just enough up front design to have clarity of purpose for the story.

Extracting stories from large requirements and detailed design documents that someone pored over for a year.   That was a year of lost opportunity.

Constant review and simplification of the process.

Ad-hoc, no process at all. i.e. “Let's just get started and work out what the plan is along the way”.

Developing from English-like Epics, Features and User Stories.

Development from high level requirements or use cases.  

Note: If you're still using Use Cases, one use case might map to three to six user stories.

Subject Matter Expert/Product Owner is part of the team and is allocated at least 25% of the time to help out for the duration of the project.  They come to every standup.  They are passionate about the project and actively participate.  Their boss ensures their workload is reduced so they can be available.

Customer is part of the team for the first week but is then allocated (or requests to be moved) to another project or is simply too busy to attend.  A junior proxy sometimes appears but is not empowered to make decisions.  Work proceeds but is marred by a series of escalations when the team appears to have inexplicably built software that isn't needed.  Waste!

Progress is tracked by looking at the burn-up 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 not referenced during the build phase.

Progress tracked by hours worked on individual tasks and from the burn up 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 enough data for a burn-up chart, publishes iteration reviews, and invites them to the showcases, encouraging them to turn up.

Business stakeholders first looked at the application in the last iteration and had some nasty surprises and a large number of changes.  The teams worked weekends for a few months.

Variable scope.

It is natural for the scope of a project to change 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 of these things 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 into 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

Although I previously mentioned Agile is variable scope, most companies need to go to the board to get funding for an IT project so scope tends to be fixed. 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, but at least the mechanisms for change are well established and expected.  The client will usually replace a less important feature with a new one of equal effort.

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 might not be agile and hence 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.

If the rest of your organisation isn't agile, infrastructure and architecture teams may 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 their design, it's pretty hard to alter anything without lots of additional documentation and approvals.  Engineers might need to spend years building devices to support the code you write. You'll need to find a way to be lean and flexible within your boundaries.

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. Using traditional estimation techniques (which use days) it should be clear that the project timeline is realistic before anyone starts.  

Pair programming

(arguably XP, but still relevant to Agile)

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

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.   Some teams do pragmatic showcases where they do best efforts to show progress based on development environments and if the server is down the showcase can be postponed or canceled. Otherwise teams can burn days each iteration preparing a sleek showcase.  Make sure the provided value is worth the cost of the team downtime so more than a few hours of preparation is probably too much. Canceling too many showcases will reduce funding certainty.