Partially Attended

an irregularly updated blog by Ian Mulvany

AGILE or agile?

Thu Nov 29, 2018

916 Words

Three links today looking at the state of agile as a software development practice.

Flavours of Agile

In Flavours of Agile Pat Kua briefly describes and rates a number of agile processes. There are a ton here, and loads that I’d not heard of. One of the key messages that I get from reading this is that “AGILE” as a fixed practice has been growing, especially within in enterprise, and perhaps not to the benefit of actually delivering or simplifying the delivery of complex processes.

Pat highly rates Extreme Programming for the technical underpinnings that it brings to the delivery of software, and I am 100% behind him on this.

I’m interested in learning more about Modern Agile and about

Feature leads also sounds really interesting - Talking Feature Leads - patkua@work. Feature leads sound like a hybrid between a product manager or product owner an architect and a developer. From my understanding of the content that Pat tends to work in these were probably developers who were tasked to think more broadly about the broader context of specific features in the wider application. This sounds like a great way to organise things.

I was interested to see that he seems to pretty much disparage the scaled agile framework (SAFe).

There are two practices that Pat didn’t discuss in this overview — lean value tree (Lean Value Tree Overview) and the pragmatic marketing framework (The Pragmatic Marketing Framework).

I’ve also picked up a copy of Adaptive Software Development: A Collaborative Approach to Managing Complex Systems (Dorset House eBooks) eBook: James Highsmith III: Kindle Store after reading this post, some good xmas reading in the bag!!

The state of Agile software in 2018

Martin Fowler has posted the transcript of a talk that he gave about the state of Agile Software Development. Well worth a read.

Some key quotes from that talk:

Our challenge at the moment isn’t making agile a thing that people want to do, it’s dealing with what I call faux-agile: agile that’s just the name, but none of the practices and values in place.

You need to find good people that work together at a human level, so they can collaborate effectively. The choice of what tools they use or what process they should follow is second order.

“if you’re doing Extreme Programming the same way as you were doing it a year ago, you’re no longer doing Extreme Programming”. Because if you don’t take charge and you don’t alter things to fit your circumstance, then you are missing the key part of it.

The agile movement was part of trying to push that, to try to say, “The teams involved in doing the work should decide how it gets done,

The lowliest, juniorest programmer tapping away on JavaScript should be connected to people who are out there thinking about the business issues and business strategies of the group that they’re working with.

When I summarize agile to people, I usually say there’s two main pieces to it. One, I’ve already talked about, the primacy of the team, and the team’s choices of how they do things, but the other is our ability to change rapidly, to be able to deal with change easily.

Refactoring is small changes, each of which keeps everything working. It doesn’t change the observable behavior of the software, that’s its definition. And I should know because I was the one who got to define it.

if you want to make changes, you want to add things quickly, you’ve got to quickly understand which parts of the program matter, what do they do, and how do I work so that I can quickly make that change. This also burrows up into modularity. If I’ve got a well-modularized piece of software, instead of having to understand the whole thing, I can just understand part of it. Technical excellence is about being able to build that kind of adaptive software

refactoring relies on testing, and refactoring also relies on continuous integration, and together with continuous integration, you have the practice of continuous delivery and the notion that we’re gonna be able to release the software very, very frequently.

The third thing that I want to stress is the importance of getting rid of software projects as a notion. Instead we want to switch to a product-oriented view of the world where instead of projects that you spin up, run for a while and then stop; you instead say, “Let’s focus on things that are much more long-lasting and organize a product team around that.”

If I was on that team as a developer, I’d want to be on first-name terms with all of the users. I would want to be talking. I would want to watch what they do, I’d want to understand how they think about making their customers happier and see that whole flow.

Another book recommendation that I picked up from reading this blog post was: Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations 1, Nicole Forsgren PhD, Jez Humble, Gene Kim, eBook -

Agile is dear - Dave Thomas

The last link on this topic is to a talk by Dave Thomas titles “Agile is dead” from back in 2015. — GOTO 2015 • Agile is Dead • Pragmatic Dave Thomas - YouTube.

OK, I admit, I’ve not had time to look at this yet, but I’m betting that it’s going to be interesting to listen to.

This work is licensed under a Creative Commons Attribution 4.0 International License