are you sure you need that
an assumption to be challenged
This week I’ve been meeting with many people who are entirely new to the agile paradigm. Software and data architecture have been the topics of choice. For someone used to big design upfront, agile seems to remove everything they believe is required for quality work. Of course, they are right that agile eliminates many of these things, but perhaps wrong that they are needed for quality work.
The question of consistency keeps coming up. I still fall into the trap of believing this is a need myself. I think back to all the code bases I’ve worked in and wonder what consistency I’ve ever seen. Did the lack of consistency make a significant difference to me or my work? Perhaps instead of explaining that you can achieve consistency through emergent architecture and self-organising teams, I should be questioning their need for consistency. Like me, I suspect they don’t have an answer for this question other than it’s how we’ve always done it.
Coaching courses really only try to teach one thing; ask more questions. It doesn’t seem to matter how many courses I’ve been on or how much reflection on the coaching I perform; I keep finding places where I’m not asking questions. In this scenario, it is because I am falling into the trap of accepting my client’s implicit belief that something is a self-evident truth. I have failed to see unquestioning confidence in statements others make as a potential for exploring the unspoken premises that underpin such conclusive statements.
When someone asks how something can be done in this brave new world, the response should be to question the need rather than accept that the need exists. Perhaps there is a need, and their response will give me a greater context to answer the original question. On the other hand, if there isn’t a real need, then a client’s fear can be set aside.
What do you mean by X?
Why do you need X?
How will X impact the organisation, customer, or user?
Who makes decisions about X?
Does X need to be considered at this point?
I think I may need "consistency" defined in this context. Why can't there be consistency from sprint to sprint? Consistently produce/release value. If consistent code is a thing - even though this seems like wishful thinking (how many people have touched the code base over time?) - couldn't we bake that into our definition of done?
I like your questions. The are always onions that need to be peeled. :) I would add, specific to this topic, Is this "consistency" real? Show me.