Traditional

The “waterfall” or “mini-waterfall”.

Characterised by stressing deadlines and deliverables. I think it makes sense in non-creative pursuits. I.e. waterfall makes sense when you are rolling out a shrink wrapped solution like $softwareProduct in a fixed time frame.

Perhaps you should call yourself a system integrator?

Agile, aka embracing change

Read the https://agilemanifesto.org/ which is short and up there in quality with the US constitution.

The above diagram is of course based on an Awesome client relationship, though an agile team can follow the same practices.

The irony of my experience with “agile” is that despite Individuals and interactions over processes and tools there is a lot of process and weekly delivery iterations that can be quite stressful when things go wrong.

When does “agile” go wrong imo?

• Team has to be incredibly strong, cohesive and cross functional (not overly hierarchical). When it’s not, things go wrong because it will be difficult to align and deliver being human and all.

• Adopting ceremonies (aka meetings / bureaucracy) that might not make sense - there is a weird cottage industry around “agile”. A lot of “middle managers” are trained in “agile” and they want to implement their learnings, but often I feel they don’t really know why or they don’t know of other tooling that might have eclipsed it. For example Jira is often used because it what middle managers know. However it’s awfully slow and feel like a crutch compared to other tools like Github Issues (which is a better tool imo at the time of writing). Some ideas, tools and rituals suck, and it can daunting to challenge them, especially when mandated by the client.

• Poor prioritisation and alignment of the backlog - often this has to do with a poor vision or product management in my experience. It needs an incredible amount of discipline to be useful. And then when it goes wrong, you need a constructive culture of accepting and documenting failure. This is uncommon, though needed for meaningful change and innovation.

• The BA has a lot of responsibility - in a team you cannot defer to the business analyst to do the talking. Better developers communicate independently. I view the BA as a facilitator. Ideally taking great notes and making people feel comfortable. That person doesn’t need to be technical, and they should not be gate keepers, otherwise things can go wrong.

• Good pairing is pretty exhausting remotely with tools like Zoom with bad networks / audio. They often go wrong, lacking initiative to address them.

• Failure to revisit some ideas - Acceptance Criteria I feel can be so heavy weight that you don’t want to revisit some “Done” cards. Though often enough chiseling away at a problem again and again gets that innovation you want. “Good enough” isn’t right for me sometimes.

• Client requests for a Roadmap - this essentially leads to reluctance to make changes down the road. Client must participate in the agile process and perhaps learn from the business analyst how to report and convey value creation without the typical Roadmap. It’s wrong when agile becomes waterfall.

• Launch 🚀 but no “landings” - teams often celebrate launches, or worse they just develop in silos without any connection to the real user of the software. Real software iterates on real users and often the client is the user and I often feel that can go wrong because they are second guessing their users demands. Tell tale sign of some disconnect is when there is no clear feedback channel for the user.

Conclusion

Science is about critical thinking and I want to apply that to Agile Software Development. My fear as a consultant is walking a tightrope of having structure and process, without having the bravery or openness to test the dogma. I don’t want to fool myself, and deliver Emperor’s New Clothes.

For me, agile works wonders when it doesn’t go wrong. If you think of better points or points I got wrong or overstated, do please let me know. The blog is very much open to change!