Today I am reflecting on how difficult it is for individuals and organizations to deal effectively with uncertainty and ambiguity, and how the underlying belief in the possibility of certainty has such a strong hold on us. Examples of that desire for certainty that have appeared on my radar over the last few years include:
What we have to say, what you want us to hear.
That’s how our blog works. It’s interactive. Let’s learn together.
How long should a team spend analyzing something before doing something?
A team I work with recently used a "spike" to investigate how to implement a new system capability. The spike was open for two sprints, although I am not sure how much effort was expended over the course of those two sprints. The fact of this spike being open for two sprints made me curious about the trade-offs made… given the agile value of Working Software over Comprehensive Documentation, was the team leaning too far in the direction of comprehensive documentation? And if so, how would they know?
In thinking about this trade-off, I like the following thought experiment… what would each extreme look like?
I recently found myself in a conversation with a colleague regarding feature teams vs. component teams. The colleague was expressing his frustration with feature teams. In his environment, there are a number of shared infrastructure systems on top of which are built a variety of products and features. His frustrations included:
"I'm implementing a user story and I see a way to improve/refactor the existing code while I am at it. Should I do that?"
"I've completed implementing a user story and want to clean up the code I've written. Should I do that?"
"I have an idea for a better way to solve this problem. Should I implement it?"
"This piece of legacy code is complex and painful. I want to rewrite it. Should I do that?"
Do any of the above questions sound familiar? I've heard them on many projects and on many teams. The questions reflect both a desire to "make things better", as well as an uncertainty as to the boundary of "what's ok to change". I wish there was a simple answer. Sometimes there is, but often there is not. How do we decide if, when and how to implement improvements?