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.


The Collaborationist is In. 5-Cent Advice.

It’s safe to say that there isn’t much I haven’t seen in the conference/tradeshow world, having worked for more than a decade on all sides of industry, from show management to vendor to exhibitor. From speaker recruitment to booth design, I thought I’d seen and done it all. That is, until August 3, when I found myself and our VP of Business Development Laura Richardson at the Gaylord Convention Center at National Harbor, Maryland, building a booth for the Every Voice Engaged Foundation from PVC pipe, a couple hundred yards of brown butcher paper and tempura paint.

It’s safe to say that our “Peanuts” inspired booth was unlike any other exhibit at Agile 2015. But the brown-paper booth wasn’t the weirdest part. Nope. We were building a booth from $200 worth of craft supplies and Ikea furniture to share with 11 other companies, who, depending on the project or the day, may be our competitior.

Crazy? Crazy good.

We skipped the fancy graphics, printed backdrops and rental furniture — and instead focused on building a true “Community Collaboration” booth to highlight the community partners who have supported the Every Voice Engaged Foundation since it’s inception. Over four days we joined our fellow Collaborationists in the booth to talk with our agile brethren about how agile collaborative techniques are tackling complex problems in both the public and private sector. Check out the photos below to see the booth in action, and don’t miss the Collaboration TV video series we created with our partners.  We look forward to seeing brown-paper booths, not to mention more collaboration, at conferences all over the world! (And we’d love to hear from you if you are inspired to create your own Peanuts-inspired booth!)

Oh, and a special thanks to Mark Finnern from Playful Enterprise for inspiring our booth design!



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.