We Played MORE Than Two Games – And Changed the World!

Dear Agile 2016 Attendees –

In my Agile 2015 keynote, I challenged the Agile Community to change the world by playing two games. With the help of the Agile Alliance, the Scrum Alliance, Agilists around the world and a whole bunch of other people, Every Voice Engaged Foundation was able to accomplish a whole lot! Here is a brief summary of what we accomplished since August of 2015.

Completed: We produced a very large Zero-Based Budget Participatory Budgeting project for San José, CA in February of 2016. This project enabled the City to better allocate more than $63M in funding for Neighborhood Services (report here). This project is a terrific example of how San José, CA continues to experiment with various forms of Participatory Budgeting for dollar amounts that are quite significant. We are presently hoping to expand this to get City employees involved in the process because we think they would have excellent insight on the best way to allocate reallocate funds within a budget.

Completed: We produced www.d3decides.com, a project in which residents of District 3 were given $100,000 in funding. Residents submitted ideas, shaped them into proposals, and selected the funds. If you like Product Box, you’re going to love watching the videos of residents pitching their products: http://d3decides.com/phase-four/. This project also enabled us to extend Buy a Feature to enable single-player mode on smart phones, dramatically increasing our ability to engage residents.

Completed: We wanted to see if we could push the boundaries of Participatory Budgeting, so we gave $500 to the Sunnyvale Middle School (grades 6,7,8) under the condition that the kids were in complete control of the funds. They used our software platforms to create project ideas, shaped them into proposals and then selected them. The winning project surprised all of the adults: replacing an existing water fountain with a new model that could refill water bottles (better for the environment ;-).

In-Flight: We’re presently producing a project for San José, CA in which residents of a specific neighborhood of District 2 are determining how to spend $1M. Yup – that’s a pretty big chunk of change. We’ve completed the ideation stage. Details here.

In-Flight: We finished a whole slew of updates to Common Ground for Action, our deliberation platform we created in partnership with the Kettering Foundation. We’re in the midst of planning a big project for 18 members of the US Congress on Making Ends Meet (inequality), Immigration Reform, and Political Fix (getting American politics back on track).

Completed: We’ve trained more than 100 facilitators (this was pro-bono training!). And we’re going to KEEP on training people.

In-Design: We’re hoping to work with Kettering and other Communities to improve race relations with public safety (police) and the communities they serve. This is an especially sticky problem so we’re moving with respect and caution.

Finally, y’all know we’re crazy dreamers… so I’ll close this post by sharing The Democracy Machine, our vision of an expanded platform that integrates and extends our work in Participatory Budgeting and Deliberative Decision Making. Written by John Gastil with contributions from Luke Hohmann, Amy Lee from The Kettering Foundation, and others, we’re proud to have published this work in collaboration (there’s that word again! ;-)) with the Ash Center for Democratic Governance and Innovation at the Harvard Kennedy School.

Dream and Play On, my friends.

Crappy Code or Crappy Collaboration?

One of the fastest growing memes in the software development community is “Technical Debt.” As outlined by my colleague Martin Fowler in this post:

“Technical Debt is a wonderful metaphor developed by Ward Cunningham to help us think about this problem. In this metaphor, doing things the quick-and-dirty way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick-and-dirty design choice.”

An example of Technical Debt would be the result of asking an individual or a team to add some URLs for a website. The “quick and dirty” approach might be to “hard code” the URL, making the resultant system brittle and unusable if the URL changes. The “proper” way to do this might be storing the URL in a database or configuration file that can be easily updated – but the “proper” way definitely takes more time, and in reality the URL may not really change all that much.

Unfortunately, a growing number of technical teams are jumping on the Technical Debt bandwagon in order to get their business leaders to allow them to make desired improvements in their software architecture. More explicitly, these teams do not have Technical Debt. Instead, they have poor collaboration with their business counterparts — and that lack of collaboration is forcing them to “scare” their business leaders by asserting they have massive technical debt.

I tackled this topic in my Agile 2015 keynote when I discussed how organizations should tackle wicked problems. Briefly, the wrong way to tackle a wicked problem is to identify a single option that the group accepts or rejects. In the case of Technical Debt, the wrong approach is to assume that you have to rewrite your system — which most developers will advocate, especially when collaboration with the business is poor.

The right approach to tackling a wicked problem is deliberation, a process in which a group of people evaluate between three and four strategies for tackling a problem, the actions associated with each strategy, and the inherent drawbacks of these actions. Does this mean that sometimes rewriting the system is the right option. Sure – but only after you’ve actually considered options!

To illustrate, let’s consider options, actions and drawbacks for tackling Technical Debt.

[separator type=’transparent’ color=” thickness=’1′ up=’-1′ down=”]

Option 1: Total Rewrite

This is the option that is (often forcefully) advocated by developers: “The system has so much Technical Debt that we must totally rewrite it!” An inherent drawback of this option is that investing in a total rewrite means NOT investing in new features or serving existing customers. But to move beyond a trivial review of the option and its inherent drawback, we need consider specific actions and drawbacks. (In the framework we use for deliberation, there are typically 5 to 7 action-drawback pairs for an option, and you’d need to tailor these for your situation).

[unordered_list style=’circle’ animate=’no’]

  • Action: Change the technology we’re using in the rewrite. Drawback: Our developers don’t have experience in the new technology, training is expensive, and it introduces unnecessary risks.
  • Action: Do not make changes to the existing platform so that developers can focus. Drawback: Customers may defect, and bugs will not simply vanish.
  • Action: Increase budget and let 3rd-party developers handle bugs and new features. Drawback: This will further depress our ability to invest in new products and our existing developers will have to manage questions from the 3rd-party developers.


Hmmm… Isn’t it interesting that once you consider the drawbacks of the actions required to implement an option, the option often becomes less appealing? That’s not a negative; that’s a positive, because it should also motivate you to consider another option.

[separator type=’transparent’ color=” thickness=’1′ up=’-1′ down=”]

Option 2: Purchase Software

Once the organization considers a total rewrite as a potential option, the business team will quite naturally suggest that the organization get out of the business of writing software altogether and simply purchase a system. An inherent drawback of this option is the loss of control and inability to tailor the software to meet the specific needs of the business. Let’s review some potential actions and drawbacks for this approach.

[unordered_list style=’circle’ animate=’no’]

  • Action: Develop a list of requirements for selecting a vendor. Drawback: Developing requirements for existing systems is time-consuming and often results in “forgotten” requirements.
  • Action: Identify and evaluate software vendor offers. Drawback: Evaluation of a vendor is costly and may require undesirable workflow changes.
  • Action: Implement the new system. Drawback: We’ll have to train users on the new system.


What’s curious about Option 2 is that it is usually similar but “opposite” to Option 1. In both cases, the options involve addressing the Technical Debt through standard mechanisms. The key to creating a really powerful choice isn’t just saying yes or no to one option, or simply considering two options that are opposite. The key to deliberation is to make sure that there is at least one additional option that helps us consider the problem we’re facing from an entirely different perspective; a perspective that sheds meaningful insight into the true root cause of the problem.

Option 3: Improve Collaboration Through Roadmaps

My experience is that a lot of what is called “Technical Debt” is really a lack of effective collaboration between business leaders and their technical counterparts. Eventually, the lack of collaboration creates schisms that can become unsolvable, with developers clinging to their belief that a total rewrite is required to get what they want, while business leaders scheme to replace those frustrating engineers with an outside vendor.

An alternative to rewriting a system or buying software would be to develop a collaborative roadmap. (You can find my pattern language for product roadmapping from my book Beyond Software Architecture here). By learning how to collaborate more effectively, business and technical leaders can manage the strategic evolution of their solution and identify the backlog items that authorize the work necessary to implement it.

Let’s review some potential actions and drawbacks for this approach.

[unordered_list style=’circle’ animate=’no’]

  • Action: Develop a collaborative roadmap. Drawback #1: Our positions may be so entrenched that we’re not willing to engage in the hard work needed to build an effective roadmap. Drawback #2: Our Agile method says that all we need is a backlog; introducing a roadmap will require us to change our method.
  • Action: Identify the right participants for this process. Drawback: The right participants may not have the perceived title or seniority; therefore, their opinions and insights will not be accepted.


Collaboration Over Crappy Code

The deliberative process that I outlined above exposes the actions and drawbacks behind each potential solution. There may be others in your individual situation. Regardless, I hope this post has got you thinking about the real challenges that exist in identifying and managing Technical Debt — and whether you really have as much crappy code as you think, or more crappy collaboration than you’d like.