Agile 2015 Keynote: Awesome Superproblems

On August 3, Luke Hohmann, Conteneo CEO and Acting Executive Director for the Every Voice Engaged Foundation,  presented the main stage keynote “Awesome Superproblems at Agile 2015 in Washington, DC. Luke’s keynote detailed how agile collaborative techniques and practices are being used to tackle wicked problems beyond building software. The problems being tackled are bigger than any one person can solve and exacerbated by inaction — thus the title “Awesome Superproblems”. Luke describes how making  progress on solving these Awesome Superproblems is enabling us to find new patterns that can be applied to solve classes of similar problems. And are being used around the world.

We hope you will watch the video and discover  how the collaborative, social and serious games born from the agile community have blossomed into multidimensional frameworks that agilists are using around the world to solve awesome superproblems without any special superpowers except a willingness to try.

Want to get involved? Check out Every Voice Engaged for more details.


Featured image taken by Doc List at Agile 2015.


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.

Awesome Superproblems: Luke Hohmann to Keynote Leading Agile Conference Agile 2015

Mountain View, California – July 1, 2015 – Today Conteneo Inc. announced that its founder and CEO Luke Hohmann will present the opening keynote for the Agile 2015 conference in Washington, DC on August 3, 2015. Agile 2015 is the leading live event for agile practitioners and is organized by the Agile Alliance, whose mission is to advance agile development principles and practices. This year’s conference and keynote speakers will focus on how collboration and communication are the cornerstones of effective teams.

An early leader in the agile movement, Luke Hohmann’s diverse background uniquely prepared him to found Conteneo Inc., a cloud-based software company dedicated to enabling organizations optimize their decision-making through multidimensional collaboration. The inventor of the Innovation Games® collaboration frameworks, author of several seminal books on software development, frequent keynote speaker and serious games expert, Hohmann will focus on how the agile values and practices favored by progressive organizations can tackle problems — Awesome Superproblems – that are well beyond software development.

“Awesome superproblems are problems that are bigger than one person or team can solve, and they get worse through inaction,” commented Hohmann. “However, when we make progress on solving one, we find that new patterns that can be applied to solve classes of similar problems. I’m thrilled to have the opportunity to speak at Agile 2015 and reveal how the collaborative, social and serious games that were created in the agile community have now blossomed into multidimensional frameworks that are being used by agilists around the world to solve these problems—all without any special superpowers except a willingness to try.”

In addition to being the founder and CEO of Conteneo, Hohmann is also co-founder of the Every Voice Engaged Foundation, a 501(c)(3) nonprofit that helps citizens and governments tackle technical and wicked social problems. Every Voice Engaged and its community partners will be on hand at Agile 2015 to share how collaborative, serious games are being used around the world to tackle problems like municipal budget shortfalls, increased school enrollment, urban planning and environmental issues like the California water crisis and more.

Every Voice Engaged is also a sponsor of Agile 2015. To register and attend the conference, visit


Conteneo is the leading provider of multidimensional collaboration solutions for the public and private sector. The Conteneo Collaboration Cloud and our Collaboration Consulting services enable organizations to improve performance across the enterprise, including culture and change management, market research, strategy, complex sales, and innovation and product development. Current and past clients include Adobe Systems, Cisco, Emerson Climate Technologies, HP, Rackspace, Reed Elsevier, Qualcomm, SAP, Yahoo! and others. For more information, go to

Every Voice Engaged® is a 501 3(c) nonprofit that that helps citizens, governments and nonprofit organizations collaboratively solve problems through the use of social, collaborative games that are unsolvable without civic engagement. Find out more at


Photo by Nan Palmero. Taken at Fortune Growth Summit 2013. Some Rights Reserved.