How many rodeos does one actually need?

None.

Since ancient times (before the smartphone, kiddos) Software Development Teams yearned to shake free from the yoke of their Project Manager, who would beat them mercilessly with a cruel device called a “Gantt Chart” and shout about “Delays, Risks, and Issues” from the village square loud enough to alert the feudal lordship (who’s wealth and power provided them with a diet rich with animal protein, earning him the nickname “Steak Holder”). The Business Analyst, was oft seen at the side of the Project Manager (or, thru witchcraft, obviously, was a second spiritual entity that lived inside the PM’s very brain, I tell ye!) was labeled an ally of the PM and faithful servant to the Stake Holder, despite the alliance being an uneasy one at times because their primary objectives were frequently at odds, a nuance often overlooked (or more likely, nary a shat was given) by the brave Software Developers and the brilliant System Architect. Nevertheless! The BA and the PM looked only to impede the progress of the Software Development Team, and ruin all the fun, of everyone, everywhere.

Then a magical thing happened…. a wizened team of white-bearded developers came from behind the waterfall where they lived and traveled to a snow-covered mountaintop in the land of many wives to preach the power of a new methodology, one that was dynamic and delivery-focused; in a word…Agile. But almost as soon as it was launched, many practitioners lost sight of the fact that the true Agile Manifesto was meant to be *additive* to prior software development lifecycle and project management methodologies. They embraced the concepts that supported speed and conveniently forgot that those that are used to make sure everyone is running in the same and the correct direction. This partially arsed approach is what I refer to as “Short Cut Agile”. And the land went NUTS for Short Cut Agile, men praised its simplicity, women wept at its elegance, and children could finally become Project Managers (Okay, okay, that last one is really mean, and not true, but funny, right??). And all was right with the world, forever and ever, the end.

Not quite.

The world is still obsessed with the term "Agile", and if pressed to define, many people will mumble thru some version of Short Cut Agile (probably sprinkling in the words "sprint" and "scrum" to up wow factor). But the teams that are successful, even those that never read past the TOC of the Agile Manifesto, rely on the basic tenants of old school business analysis and project management, they just do so either without full awareness or without fanfare.

Why, tho? Why would developers, who long suffered the cruel humiliations of having to slow down “progress” to provide human-readable descriptions of their design, still rely on good business analysis and project management?

Because it makes the answer to “how many rodeos are required” be… none. Leveraging the tactics of the skilled BA/PM allows a team to successfully build novel products. Focusing on business need and delivering business value, in ways that ensure engagement and mutual understanding*, is what defines the margin of the cutting edge that will actually be adopted by real-world users, everything past that point is dancing bear-ware that dilutes the product’s ROI.

So set up daily 15 minute calls and cloak yourself in "Short Cut Agile" if you need to get in with the Agile crowd, but if your team is building great products, hug your business analyst, and buy your PM a cup of coffee. And if “they” happen to be roles played by one person, absolutely burn them asap, that person is totally a witch.

*This is one of the benefits of even “short cut Agile”, the concept of showing users what is being built early and often is a great addition to the communication of design, but care must be taken to understand it is the users that sit at the front of the drafting table, not the product team.