A lot of the articles I read about agile don't describe the context in which their advice applies. The authors don't take the time. Many authors aren't even aware of their context. They haven't seen enough different kinds of agile implementations to understand that their advice doesn't apply outside of their context.
Writing was easy for me when I worked for Leading Agile because we had a well documented and limited context. Grossly oversimplified, companies who wanted predictability in their software development efforts were attracted to our offering. We had one message, one services offering, and one target market.
Everything on our blog and everything on our website and every talk given at a conference adhered to this single context. That context was explained so much that it didn't have to be explained every time. Yet every blog post pointed back to that context in some way. It all dovetailed together.
Every aspect of agile, of teams, of org structure, of metrics, of forecasting, of planning, of funding, of portfolio management, of roadmapping, of prioritization, and on and on needed to be explained in terms of that context, so there was lots of fodder.
I stopped blogging when I left Leading Agile because of this need for the applicable context to be explained. When I left the firm I left the context. I've seen agile done many different (valid and effective) ways before my time at the firm and in many ways after. For which context should I write? How should I explain the applicability of my opinions?
I don't run my agile programs now the way we did at Leading Agile. It's not because I didn't believe in that approach, didn't find value in it, or can't do it. In fact, I like that approach a great deal. But it doesn't apply to my context now. Predictability isn't my driver.
This isn't anything new. People have been arguing over agile since the 90s, with much disagreement stemming from the unique and unstated context in the mind of each author and consultant.
What triggered me to write this was some things John Cutler wrote. "…the key to putting bets in motion is to tailor your working approach to the bet." How you develop the idea of the bet and how you implement the bet should vary based on the nature of the bet, the uncertainty of the opportunity, the uncertainty of the solution, urgency, size, allowance for failure, level of collaboration needed, and etc. There's no single agile prescription that's best for every kind of bet. John explains the anti-pattern of when companies "lack any sense that the things they are doing have different characteristics. They try to use a mono-process for everything." "Impact: picking less-than-optimal ways of working." And "Mono-process kills companies."
Don't bother trying to do agile "right" and don't fret over other people's advice when it doesn't match your context.
