Just north of Dallas, you will find Lake Grapevine, a gorgeous lake with some of the best sunset views in Texas. It is also man-made, thanks to the efforts of the U.S. Army Corps of Engineers. Constructing this 8,000-acre body of water took lots of coordination and planning, which made it an ideal location for the world's largest gathering of professionals focused on helping teams deliver products more effectively through agile methodologies: Agile2024.
Over 850 Agile practitioners descended on the Gaylord Texan to discuss the state of Agile and to learn from one another. This annual event is put on by the Agile Alliance, a group that has been helping further the adoption of Agile best practices since 2001. Sessions ranged from how to run and plan energizer games, which are group activities designed to get everyone working as a single unit, to fairly technical talks on subjects like causal loop diagramming, based on concepts from the influential book The Fifth Discipline.
Agile2024 Open Spaces opening
With over 100 sessions and a whole day devoted to Open Spaces, adding dozens of spontaneous attendee-led discussions, it would be impossible to give a full report of everything that happened in these intense 5 days of learning. Here are just a few highlights from this year's event.
Mob programming
One of the Open Spaces sessions this year was a hands-on mob programming experience. Mob Programming is an extension of pair programming, where "the whole team works on the same thing, at the same time, in the same space, and on the same computer." This session was led by Chris Lucian, Director of Global Software Development at Hunter Industries, who also gave a different awesome presentation called Generate Organization-wide Understanding with Cross Discipline Causal Loop Diagramming later in the event.
It was pretty amazing to watch the wisdom of the crowd at work. A novice volunteer who had never before used ChatGPT shared his screen, and we worked through the creation and execution of a Python project to analyze a data set. At any time, someone in the room could shout out a suggestion on how to progress, and the person at the terminal would try to execute it. We were able to get the application running, and by the end, we had generated multiple visual charts to help us understand the data.
Mobbing a problem can extend far beyond programming and is worth exploring when trying to solve a complex issue quickly, no matter what team you are on. People in the room who regularly use this practice shared success stories where it meant getting instant approvals from the right people. One person said their team successfully got 2 entire feature requests all the way to production in a single day thanks to this method, with zero defects or security issues found.
"ChatGPT is by definition the most average programmer in the world. not the best"
Technical debt is a limited metaphor
Declan Whelan, Agile Coach at LeanIntuit, began his talk "Agile Fitness: Measure and Improve Your Team's Technical Health" by explaining that the term "technical debt" was meant to be a limited metaphor. However, the continued evolution of the term has stretched it too far, which is part of the reason it is hard to communicate about this subject to non-technical teams and leaders.
Originally, Ward Cunningham used the metaphor to explain to non-technical stakeholders why resources needed to be budgeted for refactoring. Part of the issue with the term's use today is that we often identify things as technical debt, which are instead just general code maintenance tasks, like patching, defects and bugs, and operational challenges.
Declan said good examples of technical debt are technical challenges that slow your team down, such as:
- Code smells - Traces in the code that indicate a deeper problem in the application or codebase
- Poor documentation
- Lack of tests
- Slow running tests
- Domain mismatch: When business terms, such as product or feature names, are not directly used in the code, it can be hard to follow the logic.
- Poor design choices
Declan said a better approach is to think in terms of "tech health." He defined this as "Management of a software development system that helps ensure effective, long-term delivery of value." Fortunately, there is a lot of research into this field, as it directly correlates with DORA metrics. Instead of focusing on tackling the symptoms of tech debt, we should strive to achieve better overall code health.
He also made the interesting point that Continuous Integration was not meant to be a set of tools. It was a way to get together often to release code together, sometimes dozens of times a day; tools just make the process easier. If we are striving to release products and features faster, then focusing on how to improve the health of our code as part of the process will actually speed things up as tests will more frequently pass, and the time needed for refactoring will be reduced.
Agile Fitness: Measure and Improve Your Team's Technical Health from Declan Whelan
Shadow IT is expensive and potentially dangerous
In his session, "Full of SaaS and TOTALLY SECURE!" Garrett Gross, Head of Product Success at Nudge Security, made us aware of the security pitfalls of businesses running and building applications outside the purview of IT and the security teams. In 2021, Gartner estimated that 33% of all cyber attacks would be on data stored in shadow IT applications. Given that their recent estimate was that a full 50% of tech budgets are spent outside of IT, this seems like a conservative estimate.
We can not simply block everything on our networks, as business users have to get their work done. 67% of the people responding to his recent survey said they would find workarounds if access to their favorite tools were blocked outright.
The key is to allow them to use the tools they need but in a safer way. Garret said the best way to do this was to "nudge" them to better practices. For example, if your marketing team is going to evaluate a new CRM tool or platform, it is a good idea to nudge them to use test data first, only using real customer data once the tool is adopted formally. Reminding people periodically about security threats and how other companies have been breached also helped reduce security issues overall.
Garrett also suggested using automated questionnaires or surveys when a new tool or service is detected. He said people are very receptive to doing things securely when they are promoted to explain the tool's value briefly and are reminded of best practices like Single Sign-On (SSO) and Multifactor Authentication (MFA).
Which one of these lines is a lie? (Spoiler: All 3 of them)
Meetings should focus on reaching agreements, not checking boxes
Have you ever been in a meeting and thought, "This should have just been an email?" You are not alone. But with a little rethinking about why we have meetings at all, we can actually make our meetings a bit more actionable and use them to get more work done. This was the premise of the session "Product operations in the real world: meetings are good, actually," from Chris Butler, Chaotic Good Product Manager at GitHub.
The main motivation for a meeting should be to get to an agreement on a topic. Chris said that when in a meeting, you should think about what everyone around the table wants and feels. If we focus on creating mutual expectations and not on creating bullet lists, we can better decide and clarify what is actually needed. Keeping the focus on the transformation of people and ideas keeps us from wasting time on meetings for the sake of meeting.
Chronos vs. Kairos
He also introduced us to the concepts of Chronos time and Kairos time.
Chronos comes from the ancient Greek idea of calendar time. It is good to think about calendar time for weekly or monthly planning meetings and to establish a rhythm for ongoing work. Ideally, these meetings should focus on what has changed since the last one and how to address any issues involved.
Kairos, on the other hand, is framing time based on narratives or epics. These types of meetings should appear based on needs or thresholds. For example, he suggested scheduling pre-mortem meetings before a project kicks off, where everyone agrees on what they don't want to happen and how to avoid those traps. If the project is interrupted by an issue, anyone should be able to call an escalation meeting to address the blocking concern.
Chris Butler - "Product operations in the real world: meetings are good, actually"
Security in our workflows
One of the biggest recurring themes across all sessions is that we all want to get more done and do it in a safe and sustainable way. Agile is a great framework for reaching this goal. Your author was able to give a session on scaling security by embracing Security Champions programs. If we can empower everyone to speak up about security risks they spot early in any process, we can truly achieve 'shifting left' in a holistic and impactful way. This does not break the process or even slow it down, though it might feel like it is slowing down some steps. Ultimately, when the security team is brought in from the design and planning stage, later tests will pass with flying colors, allowing us to ship more products faster.
It was an amazing experience to have so many conversations with folks running Agile practices inside some of the world's largest organizations. Understanding how our products are delivered and the processes that drive their ongoing delivery means we can find ways to insert security earlier and more reliably into those processes. No matter what you are doing, you can likely benefit from spending some time thinking about Agile methodologies and team thinking. If you are looking for some great ideas on what topic to research, check out the full agenda from Agile2024!
Top comments (0)