Remember what the “rules” of Agile are: Individuals and interactions over processes and tools, Working software over comprehensive documentation, Customer collaboration over contract negotiation, Responding to change over following a plan.

That’s it. Those are the only “rules.” Scrum and Kanban have rules, but Agile really only has tenants. Agile doesn’t mean no documentation up front. Think of the requirements more of a living document, that should be pretty fleshed out before programming starts.

We’ve adopted a policy of sprint 0, where we have no programming for the first 2-4 weeks. After that, it’s always 2 week sprints. Sprint 0 is filled with proof of concepts, documentation, and knowledge transfers. Keep in mind, when doing a sprint 0 your stories should have tangible deliverables.

At the end you of Sprint 0 you should not have a velocity of 0 and a bunch of team members saying we talked about the features needed and have an idea of where this is going. You should have UML diagrams, tested POCs, Database diagrams, documents describing using one framework over another, more fleshed out stories and epics, etc.

We also started having product owner proxies, for executives who can’t make the time commitment to the products. People who can speak in their absence.

As for buy in, we had the opposite problem. The team wanted to start, but management hated it. Telling an executive a project manager no longer exist can be an awkward conversation. It’s all they know.

Sprint commitment
You should also have epics that will last the entire release. We attached every story to an epic, to ensure that the story is aligned with the product owner’s vision. We posted those epics on the wall around the office. This has helped keep the team focused on the product’s goal.

Last note: Developers are allowed to know or talk (even have meetings) about what’s outside of the current sprint. Just make sure they can finish the work they commit to in the current sprint, before working on a story in the future sprint.