Things I used to take for granted as an Agile Developer

I am lucky to have an opportunity to work with some of the worlds best software developers for past couple of years. TDD, Pair Programming, Continuous Integration, Fast Builds, Value Streams, User Stories and a lot of other goodness all became a norm that I have forgotten about my previous job where I used to get a source code checkout that compiles smoothly only on a lucky day.

The past few months was an eye opener about what is software development outside the cocoon.

High Specialisation My job was that of git helper and unit test script runner, we had a test script writer and developers all specialising in their on areas of work , leading to large number of handoffs.

Long Running Builds 2-3 Hrs. Build was running on an environment that is shared across the organisation and used by multiple teams and was not predictable.

Ad-hoc Workflow The work could move from any role to other in any direction at any point of time. A test complete to ready for analysis was not that uncommon.

Collaboration We did a lot of that! The ETL tool produced a single binary file that was checked into the version control. The team was supposed to work in parallel to improve the throughput. We often overwrote each others changes and collaborated closely to recover.

What is Done? Truly we had no clue what DONE meant. Our project was an upstream dependency for another project and we never knew that what the downstream needed. We used to complete our cards and claim points without even consulting the downstream project.

Unfinished Work We had a lot of that. Expectation was for everyone to move as fast as they can, to eventually realize that they cannot move any further. There were knowledge gaps, cyclic dependencies between each others work, integration failures which all took ages to resolve. We did not learn from that, instead we tried harder.

What is value stream? Our build was part of the by the downstream project build pipeline and the results were not considered in publishing a build. Our story wall was represented at the bottom side of the downstream project.The build remains red for days and sometimes weeks, but that did not have any impact on developing new functionality. Also see the point above on Ad-hoc workflow.

The Mythical Man Month


We attempted to add more developers, Subject Matter Experts, dedicated Business Analysts and there was very little improvement. It was frustrating to work under these constraints. But it was practical lesson of Deming's Red Bead theory, how most of the problems were systemic rather than people related.

Next time when I pair program, TDD, BDD or work on a build improvement, sit across dining table layout I will have a greater appreciation for all those goodnesses and ones who developed and supported an echo system for all those goodnesses to flourish!