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.
XP2019 was held May 20-25 in Montreal, Canada -- the first time that the XP conference has been in North America.
I attended this conference as co-chair of the Industry & Practice track. I was an organizer of the Architecture in an Agile World workshop (see XP2019 Workshop Notes for a summary of workshop results), and I one of the two presenters for a tutorial on collaboration between industry and academia. I was also a panelist in the Security and Privacy panel.
There were three main keynote talks, but the most fascinating keynote was on the first day of the main conference -- a talk by Scott Ambler titled "No Frameworks."
The video of Scott's talk is available online: https://player.vimeo.com/video/343123394
Scott has posted his own notes on the topic on his Disciplined Agile Delivery site: http://disciplinedagiledelivery.com/noframeworks-xp2019/
I agreed with about 50% of what Scott said in his tutorial. He started with a "mea culpa" -- he admitted to being part of the problem in the past, advocating development frameworks that were too complex and too prescriptive.
Scott explained that when he started learning Agile, his own background with the Unified Process made him interested in coming up with a way to do "modeling" in an agile way -- what he called his Agile Modeling Method. AMM was a collection of practices, and people could "use what they needed" from that collection. He followed his work on AMM with two more elaborate methods: Enterprise Unified Process (applying Agile to the IT space) and Agile Unified Process. These started looking like real frameworks.
Scott pointed out that frameworks seem to "put us into a box." The frameworks define a fixed set of principles, rules, and beliefs -- so that developers "don't think" anymore. What if the rules aren't applicable? What if your situation changes? Your prescriptive framework needs to evolve to solve new problems. In Agile, teams are supposed to think and adapt.
Scott says we should enable teams to "choose their own process" rather than have everyone be forced to use the same process. He complained that Scrum can be very limiting, because people learn the language of Scrum, and they have trouble considering practices that might help them but are outside of Scrum. (This is an interesting echo of some of the critiques of Scrum at conferences 10 years ago... at that time, many people in the XP community advocated using the Scrum process framework but supplementing it with many of the Extreme Programming practices.)
Scott spent some time talking about attempts to measure the effectiveness of agile frameworks. He cited studies done by Don Reifer that show that most people don't really get much productivity improvement from Agile methods. He claimed that over time, Agile methods usually improve productivity by only 7%-12%, and that Agile scaling frameworks have a smaller impact, only 3%-5% improvement in productivity. (I am skeptical of these metrics claims, since I haven't seen the study data. Also, I have a bias against Don Reifer -- I have not had a high opinion of Reifer's work on metrics in the past...) Scott's key point is certainly a good one: just "adopting" an Agile framework without really accepting the agile mindset is probably not going to get you a big productivity benefit.
Scott's final point is that there hasn't been any significant investment in "agile frameworks" by the industry leaders (the "apex-level competitors" such as Apple, Amazon, Tesla, and Google). The industry leaders have had more success with Lean and Kaizen -- using a Plan-Do-Study-Act loop to guide continuous improvement.
The bottom line for Scott: don't use an agile scaling framework, just "be agile" -- get everyone involved in observing problems and doing experiments that might make development better. It is *not* a good idea to try to get every team to use exactly the same process.
Evelyn Tian (Evelyn Konsult AB in Sweden) spoke about "Agile, Mushrooms, and Tibet" -- this talk was about understanding the journey of Agile transformation. The video of Evelyn's talk is available online: https://player.vimeo.com/video/343129288
Evelyn explained that every agile transformation is different. You need to take into account the organizational history, culture, and the structure of the products they are building. It takes some understanding to get agile started... just like it takes some expertise to go mushroom picking. You might not know which mushrooms are good and which are poison. A company might establish a number of Agile teams, but managers aren't always able to know which of the teams are the good ones.
Robert Biddle (Carleton University) gave a thoughtful presentation about some of the history of Agile research -- "Humans on the Side: Research, Results, and Reflections." The video of Robert's talk can be found online: https://player.vimeo.com/video/343260864
Robert reviewed some of the research he has been connected with including:
Landon Noll (Google) delivered the final keynote talk, "Programming in the Extreme: Finding a New Largest Known Prime." Landon has been involved in the search for Mersenne primes for many years, and he described some of the technical design issues that need to be addressed for anyone who wants to be involved in the search. The video of Landon's talk can be found online: https://player.vimeo.com/video/343215328. Landon also has some notes available on his website: http://www.isthe.com/chongo.
The biggest barrier to finding large primes is "managing the project." You have to do "reliable" computations, which isn't easy. Everything has to be tested -- you can't trust anything -- compilers, libraries, networking, storage. About 70% of all of your computation cycles will be "testing." If you find a large Mersenne prime, you have to have documentation to prove to the mathematicians and the journal staff that you didn't make a mistake.
I created summary reports of the four conference panel sessions. Each of the panels had some interesting lessons for the Agile community:
I was one of the organizers of the Architecture in an Agile World workshop, which was a 3 hour discussion forum on issues connected to doing "architectural work" within Agile software development projects. The full report from the workshop can be found here: XP2019 Workshop Notes.
There were two earlier workshops on the same topic at the OOPSLA/SPLASH conferences 10 years, and these workshops had a much different emphasis. (Of course, the agenda for each workshop is adapted to the set of participants, and the OOPSLA community is generally more experienced with architecture and the XP community is well-versed in a wide range of Agile development challenges.)
The main outcome of the workshop was a set of education-related suggestions:
There was also some good discussion of the value of having architects who participate in software development (instead of just creating documents and running away).
XP2020 will be held June 8-12, 2020 in Copenhagen, Denmark at IT University of Copenhagen. See https://www.agilealliance.org/xp2020 for more details.