The XP conference is a conference focused on agile software development. The XP conference has always been one of the main European agile conferences going back to 2000. Prior to 2018, this conference was a small independent conference, but now it is sponsored by Agile Alliance (the organization that also runs the much larger annual Agile conference in the US). The conference usually draws 200 to 250 attendees from a cross-section of academia and industry. Many agile experts from North America, Asia, and Australia also attend the conference, so it has a worldwide flavor.
XP2020 was originally scheduled for June 8-12 in Copenhagen, Denmark. However, the COVID crisis forced the conference organizers to convert XP2020 into an online conference, with all keynotes, talks, and tutorials delivered over Zoom.
Once again, I was involved in the XP2020 program, as one of the two presenters for a tutorial on collaboration between industry and academia. I also worked as a behind-the-scenes helper for the panel session on Agile in the Age of COVID.
The online conference was able to accommodate a larger crowd. There were over 900 people registered, partly because any Agile Alliance member could register at no additional cost. There were many of the parallel tracks that had over 100 attendees. The conference length was trimmed a bit -- each conference day was only 4 hours or so (with 15 minute breaks between sessions). Many of the short 15 minute talks were pre-recorded, but the speakers were available for the Q&A sessions near the end of each 90 minute session. The audience members used the "Chat" feature of Zoom to post questions -- and sometimes to even carry on side discussions during the talks, which is something that doesn't happen in a conventional conference.
In many of the talks, the speaker would start with a couple of questions to get the audience engaged. The audience was prompted to use the online tool MentiMeter -- to create a bar charts from one or two multiple choice questions, or to create a word cloud from a more open-ended question.
There were two interesting keynote talks, and the best one was on the first day of the main conference -- Philippe Kruchten (Univ. of British Columbia) discussing "Technical Debt in Software Development."
Philippe's slides are available on his blog site: (slides in PDF format)
Philippe explained that technical debt is something that depends on the future evolution of a piece of software. There are two different levels of technical debt: code-level and architecture-level (which is harder).
Agile development doesn't prevent technical debt from being created.
The term "technical debt" originated in an OOPSLA 1992 paper by Ward Cunningham, and it is a limited metaphor to explain the way that code complexity causes trouble over time. Steve McConnell later expanded the definition this way: technical debt is a set of code and design level decisions that are expedient in the short term, but that make things harder later. The "debt" is an "actual or contingent liability" that affects internal system qualities -- especially evolvability and maintainability. Technical debt may be invisible, but its effects *are* visible.
Philippe explained some of the frequent sources of architectural debt:
Each of these might be caused by time pressure or lack of architecture knowledge. Also, architectural debt can sometimes be a result of inadequate architecture documentation.
In order to explore how useful or useless the technical debt metaphor might be, Philippe referred to an interesting book about metaphors: Metaphors We Live By by George Lakoff and Mark Johnson (1980).
He analyzed some of what people mean when they talk about technical debt -- and it doesn't quite match with the concept of bank debt. One alternative (again, the metaphor is also a stretch) is that it an "Unhedged Call Option." (See https://www.infoq.com/news/2014/12/call-options-bad-code/ for further discussion of this idea from Steve Freeman and Chris Matts.)
Philippe also pointed out that technical debt can sometimes be a wise investment. It can help get a product to market faster, and it can also help a development team get some real customer feedback in order to learn what to change. (Slides 37 to 41 of Philippe's presentation show how the payoff of creating a more valuable product can offset the cost of reworking the code.)
The presentation concluded with some concrete suggestions for improving the way we work with technical debt:
Philippe's final advice was to be serious about technical debt. Put technical debt items into your backlog as soon as possible. Don't ship prototypes that are filled with technical debt. And don't expect technical debt to be fixed by summer interns.
One of the most interesting experience reports was a talk by two people from ThoughtWorks -- "Your Security Team Needs Design," by Emma Lundgren and Kelsey van Haaster. Here is the online version of the paper: https://www.agilealliance.org/resources/experience-reports/your-security-team-needs-design/.
Kelsey van Haaster was one of my fellow panelists at the XP2019, on a panel where we discussed security and privacy. In that panel, she talked about ThoughtWorks policy of giving every employee a "family subscription" to a password manager -- with more people doing work from home, it makes sense for a corporation to try to prevent security issues by keeping an entire family's home computer systems secure.
But in the XP2020 talk, I learned that *implementing* this kind of security scheme is not easy, because "the instructions for getting and deploying the password manager were too complex, and people were making lots of mistakes." The right way to address this problem was to do some simplification and make some design improvements. The speakers made the point that the design of "security" must take into account "usability" as well (the usability of the security features that must be set up and configured by users) -- if it doesn't, then users will make so many mistakes, the system will still be insecure.
Aino Corry (Metadeveloper) spoke about "Retrospectives Antipatterns" -- her talk was based on the book she is about to release in fall 2020. There is a lot of material on her antipatterns at this website: https://metadeveloper.com/retrospective-antipatterns/
Retrospectives are an essential part of any Agile team's process. From time to time, the team sits down and has a discussion of what they have done together -- sharing issues, understanding what has happened, appreciating and learning from the discussion, and "forgiving" mistakes.
Any good meeting starts with a topic, followed by divergence, discussion, convergence, and finally a decision. In a retrospective meeting, the decision is about what experiments to run in the future iterations -- to improve the system. And of course, it is important *not* to blame people.
Aino outlined some common retrospectives antipatterns, and some things to do to get out of the problem. She went through a few interesting examples:
This way of looking at the problems that Agile teams have with effective retrospectives is a good supplement to the standard retrospectives reference works, such as Agile Retrospectives by Diana Larsen and Esther Derby.
On the final day of the conference, there was an excellent panel on "Covid-19's Influence on the Future of Agile." This session was moderated by Steve Fraser, and I worked with Steve to create a summary report of the panel for the conference proceedings.
There were four main observations made by the panelists:
One of the panelists was Steve McConnell from Construx -- author of the well-known book Code Complete. Steve's company put together a survey about remote working, collecting data by surveying many of Construx's customers. The report is available on the Construx website -- WFH in the Age of the Coronavirus: Lessons for Today and Tomorrow: https://www.construx.com/resources/wfh-in-the-age-of-coronavirus-report/
Steve made a useful observation about "trust" among team members -- which suffers when working in a 100% virtual environment. He said, "The half-life of trust is 6 months." Trust degrades over time if you aren't in direct contact (or take some actions to reinforce trust).
I was initially skeptical about having a conference online. Of course I missed traveling to an interesting city, and I missed having hallway conversations with people from all over. But the virtual meeting technology worked relatively well, and I think I learned some things from the sessions.
Each conference day started around 3:00pm Central European time, which is 9:00am US Eastern Time. Some of my friends on the west coast had to get up very early to participate, but no one complained.
All of the participants were very disciplined about time. Talks generally started on time, and none of the sessions ran over by more than 5 minutes.
XP2021 will be held June 2021 in Copenhagen, Denmark at IT University of Copenhagen -- assuming the COVID crisis has eased. See https://www.agilealliance.org/xp2021 for more details.