What is the Denver Method?
In 2014, my firm needed to build a large software application for a new contract we had won. With our own developers swamped, and being leery of outside contractors after a bad experience, they wanted to know if I was interested in building a new team. I responded with a proposal for a rather unorthodox team I would set up and manage, using some ideas I had been thinking about for a while. As part of the proposal, I set some conditions that would allow me to have complete authority over how the team would run, operating within the company but much like an outside contractor in terms of hiring, policies, and practices.
At first, only a couple of my ideas didn’t adhere to accepted Agile norms; the rest was very typical Scrum and XP stuff with a Kanban board for pull-based workflows. But once our ideas began to show impressive results, we decided to allow ourselves the freedom to think completely outside the box of typical Agile insights and explore new ideas. The outcome was a whole new toolset of processes, methods and basic tenets which we gave names to for working purposes. In early 2017, I started my own company and began building more teams using this toolset. Eventually, we decided on a name for the whole toolbox – the Denver Method. The ideas shared in this blog come from that toolbox, in the hope that they may benefit other development teams the way they have benefited us. I will use the names we came up with to distinguish Denver Method tools and ideas from popular Agile methodologies.
Some day the tools described in this blog will be published in print. Until that day comes, I will write about my experiences here. Please enjoy and I hope you find something useful among these pages. If you're reading this blog, you're the kind of person I would like to connect with. Please find me on LinkedIn and say hello.