Why the Agile Alliance Technical Conference Matters
The Agile Alliance is running a dedicated technical conference for the first time on April 7-9. The rationale behind running the event is at least partly because of the perception that the annual Agile 20XX conference doesn’t have enough emphasis on the technical aspects of software development.
InfoQ spoke to a number of the speakers who will be presenting at the Agile Alliance Technical Conference to understand why they are participating in the event and why it matters. Here are some of their responses:
InfoQ: Why did you choose to participate in the AATC:
I’ve been working in agile projects for most of my time in the IT industry. Hearing what other practitioners are doing and what has worked or hasn’t worked is invaluable – it offers new perspectives on problems and opportunities in our projects and our customers’ projects.
I’m also very excited about speaking and sharing our experiences!
What are you presenting about?
I’m talking about making everyone vampire slayers, or at least bug slayers!
Seriously though, my angle and examples are about developing the potential of each team member to be more active and engaged in the idea of “whole team quality”. The title comes from one of my favorite TV shows, Buffy the Vampire slayer. For seven seasons, there’s this one chosen person with the weight of the world on her shoulders. The enemies get meaner and tougher until the final bad guy seems insurmountable. The fight is finally won when the power to “slay” is shared with more people instead of having one person being responsible for the fate of the world.
I see parallels for agile teams here. We can have a dangerous tendency to place all testing responsibility on a select person or a few chosen people in our projects. There are steps that both developer and tester roles can take to reduce the gaps and realize their potential for quality assistance while still retaining a focus. I’m talking about what steps we’ve taken to do this, and how it’s working for us.
I've been giving my friends in the Agile Alliance grief for years about their overwhelming emphasis on managerial over technical practices, so when I was given the opportunity to speak at its inaugural technical conference, I figured it was on me to put up or shut up. I'm really glad to see the Agile Alliance expand its focus to help organizations improve their technology and developer practices!
From my perspective in the open source community, agile has been left behind. "Agile" insofar as it represents a rejection of waterfall is the new default ideology for software development, and folks pushing "agile" process are, if anything, seen as seeking to add process and constraints to developer productivity. As a result, few developers in my sphere spend much time talking about agile.
This is a stunning and rather sudden reversal. While the focus of the agile community on non-technical practices is a contributing factor, II think a major cause for developer antipathy towards "agile" is that the labor market has changed dramatically since the advent of XP. Many developers in the startup and open source communities have achieved such a level of influence and autonomy that they rarely have to ask permission anymore to follow their own lightweight processes.
These developers may have won their freedom, but—like any ideology—they often struggle to understand the concepts, tools, and practices that surround them. There is tremendous value in being able to tie back practices like unit testing to their roots; developers who understand the history of their tools and practices operate from a broader perspective when thinking about how to best apply them. Meanwhile, the agile community would greatly benefit from greater exposure to influential developers. For that reason, hosting a technical conference that explicitly sought out developers from outside the agile community seems like a great first step.
What are you presenting about?
My talk's title is "How to Stop Hating Your Tests". It's about why so many teams will inevitably grow to hate their tests, and what can be done to prevent or mitigate it. In the talk, I'll show 15 ways in which intuitive and straightforward approaches to testing eventually lead to confusing, slow, and brittle tests; all-the-while, I'll sprinkle in the counter-intuitive reflexes I've built over the years to avoid that outcome.
It is the first agile event focused on some of the more technical aspects of doing agile development. I wanted to participate to have the opportunity to network with other agilists who are working in the field trying to solve real world problems.
It is great to talk about agile methods, processes, procedures, and organizational change, but executing is hard. And the world of tech is changing at an ever increasing rate. The people in the trenches (developers, architects, testers, etc) need the opportunity to see how others are applying new technologies and practices to enable their agile teams to be successful.
He is talking on Agile Data Engineering for data warehouse design:
My topic is Agile Data Engineering for data warehouse design. In the last few years agile has finally made it into the DW and BI world. But the old ways of designing and developing a data warehouse just do not lend themselves to an agile approach. So how do we do that in the modern IT landscape in a way that allows us to be agile?
First off, we need to change our evil ways – we can no longer afford to take years to deliver data to the business. We cannot spend months doing detailed analysis to develop use cases and detailed specification documents. Then spend months building enterprise-scale data models only to deploy them and find out the source systems changed and the models have no place to hold the now-relevant data critical to business success.
We have to be more agile than that.
We need a way to do Agile Data Engineering if we ever expect to achieve the goal of Agile Data Warehousing.
In my talk I will introduce the attendees to just such a method known as Data Vault that I have been using for over 10 years to iteratively build out my data warehouse data models. It is a straightforward, template-based approach that lends itself to not only iterative design, but repeatability and ultimately automation.
Laurie Williams is the Associate Department Head of Computer Science and a Professor in the Computer Science Department of the College of Engineering at North Carolina State University (NCSU). She said that
An essential part of excellence in software development involves the technical practices of the development team.
Agile software development is all encompassing, spanning from project management, leadership, business, to technical topics. One conference cannot completely serve all these areas. The technical conference is a deep dive into the topics that involve the technical community.
I am talking about pair programming, which has been a key practice for agile teams since the late 1990s. Software engineers who use the pair programming practice find many benefits, including better quality software and better design in additional to benefits to the team such as knowledge management, reduced product risk and increase teamwork. Over the years, some teams have adopted the practice to a large degree (“extreme pairing”), others sporadically (“on demand pairing”) while others continue to resist the practice. In this presentation, we’ll be talking about the practicalities of adopting pair programming.
Jeff (Cheezy) Morgan, Cofounder of LeanDog, and Ardita Karaj of EPAM Canada will be jointly presenting a live coding/TDD session. In a conversation with this reported they explained their motivation for participating.
Cheezy participated in the OnAgile virtual event run by the Agile Alliance last year and is keen to participate in an event which puts the technical practices front and centre.
Ardita spoke about how important the promotion of the strong technical practices is, given the sadly low uptake levels of this aspect of agile adoption among many organisations. They choose a live coding activity so that people will be able to see how realistically a developer and tester can pair and how the ATDD and TDD frameworks work together.