Agile Otter Blog

 I believe in people.  People are amazingly strange creatures. They walk this ridge between depression and anxiety, and walk it with joy. The world need to be stable enough that they can grow competence and skill. When it's too stable then they become bored and depressed, because it's all easily within their skillset and there is no growth or learning; they've been there and done that. When things are not stable enough that they can develop competence, that's chaos and anxiety. The stress of constant change burns them out; they will often just quit trying and then submit to boredom again. In many people, chronic anxiety seems to me (a layman without special training) to be defined as being afraid that they might become afraid. It's weird how we can be like that - fearing fear so much. Of course, we tend to fear most overly-strong emotions, and I have to wonder how much other animals fear themselves. When they do what they're good at, people are beautiful. Watch ...

Aint No Plannin' I see a lot of "agile" teams and their "planning" meetings, but if you forgive me for saying so, I've not seen a planning meeting for a long time.  Typically: No plan is presented No questions about the plan are surfaced No revisions to a plan are made What actually happens then? Usually, someone loads up a list of tasks, and the entire meeting is spent assigning people to the tasks. Does that in ANY way resemble planning? What was planned, other than individual workloads? How was the plan assessed, improved, revised, or confirmed? What was, even, the plan?  So, what I have in mind is simple. Don't Assign In your next planning meeting do not assign any work to any individuals.  They can pull work as part of the sprint. They are cross-functional and self-managing, right? They are professionals you trust and respect, and have autonomy, so they can pull work.  If you are the PO/PM, then you have an ordered backlog for them. Show Your Plan P...

Some time ago, on a social media platform, during a discussion about technology, a pundit posted a piece arguing that teamwork was a horrible idea.   The Compromise Theory: His thesis is that an individual can have a great idea. When other people get involved, they have differing ideas. To settle the differences, the group has to make compromises.  Every compromise is a degradation of the original idea's purity. By definition, he said, every compromise is a second-best choice.  Eventually, the idea is so diluted and compromised that it is hardly worth implementing. The Contribution Theory: Cross-functional, diverse teams are well-documented and understood. They make better decisions, make rapid progress, and approach a problem from more angles.  The thesis here is that "two heads are better than one" for problem-solving, and that the work of an individual (rather than being perfect and pure) is likely to have more flaws and a narrower vision than the work of sev...

The riskiness of a release is proportionate to the number of potentially untested paths in the new code. If there are a thousand new possible paths and we've only tested 4, then it's a significant risk to the installed base. If there are two, and we've tested both, then it's not risky at all. The larger a release (the more stockpiled functionality) and the less complete the characterisation via tests (automatic and manual), the more a company must grow bureaucracy and processes around releasing. The harder it becomes to push a release through all the bureaucratic gates, the more work gets stockpiled before release. This is the self-eating mechanism that CD dismantles. When a release may be only a couple of lines of code, the risk comes down. When it's one function, reached in only one way, then it's a limited set of paths. Saving up for a big release stockpiles pain and risk.