The Question
"What is a developer hoping to get out of an agile conference?" While networking at the 10th annual AgileDC conference, I received this question a few times because I was in the minority there as a developer. To be fair, I had the same thought when I was registering. And well, since the people asked, I thought it might be insightful to share the dev impression of an agile conference in the year 2019.
Please Prepare for Takeoff
Let us start by envisioning we are a team of adventurers with a single destination in mind. We have decided to set out on our journey via a small plane and there is a lot we constantly need to do to stay en route. Our aircraft's instruments are critical for giving us real-time measurements, and there are still calculations that need to be performed when it comes to fuel, distance, speed, etc. in order to arrive at our destination safely.
Depending on your role in the agile process, the starting point for and involvement in this journey might be quite different. While a Product Owner is involved in the initial resource planning and provides a clear roadmap of the path throughout, a Developer is often relied upon for skilled and focused work on critical calculations. The limited scope of a Developer's work coupled with a Scrum Master's prevention of distractions often allows Developers to jump between various objectives.
During this impressive journey, it is easy for a developer to get caught up in the instrument minutia. From time to time, we must hit autopilot and remember where our various roles fit in the grander picture. This was my rationale for attending the conference as a developer.
A Dev in The Aircraft Journey
In-Flight Communications
Of course, the team cannot just exist up in the air without constant communications with air traffic control. The conference's keynote speaker, Sanjiv Augustine of LitheSpeed, kicked things off by describing a solution to channels of communications that teams need to have with their managers and executives. This was touted as being different than the Scrum of Scrums and SAFe ceremonies which may already take place. Instead, what he laid out was utilizing a "team-of-teams" structuring with a shift in the definition of the Product Owner/other existing leadership roles. These reconceptualized roles would let directions flow more freely and speed up the way value is driven at the team level.
As far as the keynote went, I was not the intended audience and it did seem a little favored towards a LitheSpeed product. I did think this was a neat way to connect a ton of agile terms/concepts I was familiar with like Slack, utilization, planned increments, etc. and organizing teams into a network to allow greater business agility seems like a win-win situation. Pretty quickly I could see its implementation would clean up those zombie projects in large organizations which persist.
Turbulence Detected
The second talk I attended attributed shortened cycle time to a technique the team used called the "Andon Cord". The presenters taught this was originally a Toyota innovation designed to empower front-line employees to recognize issues, initiate a stoppage of work, and work together as a team to quickly identify a path forward. The emergency cable strung above assembly lines became a symbol of the Toyota Way, and has widely been copied throughout the auto industry and beyond. Their team replicated the Andon Cord concept by using a Slack "@here" to force halt the team's multi-streamed work so they could together be effective on a single objective that someone couldn't complete by themselves. I have talked previously about the benefits of mob programming to collaborate on a single solution so this concept spoke positively to me.
No Smoking Allowed
Whenever we fly, we observe a shared agreement to not smoke while we are on board. The third session I attended laid out how to develop these Social Contracts to drive culture on our teams. As I have participated in meetings establishing norms several times over my consulting career, the power of this presentation lay in recommendations for when it is appropriate to revisit these social contracts.
For example, most individuals these days no longer smoke cigarettes. Does this invalidate the "no smoking" norm? Smoking should still be prohibited due to safety reasons and could cause major problems if a fire did break out onboard the plane. Something this critical should be understood by everyone. Not only this, but the popular rise in e-cigarettes would suggest as well this constant reminder will still be relevant going forward.
Observing the Signs
Of course also whenever we fly, there will always be that person who ignores the illuminated fasten-seatbelt sign and gets up anyway. Immediately, I am left with questions about their intentions. What I learned in the next workshop on aspects for observing a retrospective was that scrutiny was good, but being unassuming was key. Analyzing and jumping to conclusions can be a powerful ability developers often do very well. Though when it involves another human being, we tend to overlook some important factors: body language, tone of voice, what pronouns were said, how physical space is utilized, collaboration styles, decision making, and the way information is shared.
Retrospectives are one of the ceremonies which requires a ton of empathy. I realized through this exercise that better observing, without judgment, led to asking non-biased questions about these indicators. This crucial action allows for the formation of bonds with each other and as a team.
Quality Keeps Us Airborne
Speaking of biases, one of my favorite talks of the day was presented by Ippon's own Ben Scott on cultivating Software Craftsmanship. To grow developers into craftsmen, the team must establish norms for bettering the project as a whole. For example, some norms might include writing comprehensive tests to cover a multitude of scenarios, mentoring others in areas of expertise by sharing individual informational wealth, and giving constructive reviews for cleaner code.
The PO and SM on the team need to incentivize craftsmanship first over efficiency. Yes, the developers can still deliver many lines of code, but they will not be bullet-proof features. The code can almost be guaranteed to have bugs. Then subsequent sprints will then be spent securing and fixing these previous sprint's errors.
I cannot say that I much considered how this idea of software craftsmanship supplemented the agile development process before this talk, yet once I saw it, this important distinction made so much sense.
Metrics to Clear Up the Clouds
The next presentation on agile metric tracking introduced a transformational process for examining project goals to generate measurement-orientated questions followed up by finding metrics to capture qualitative/quantitative data for answering those questions. There are types of indicators which suss out certain metrics to track. These were called "lagging" and "leading" indicators.
Lagging indicators are output focused, easy to measure yet hard to improve/influence, and confirm certain patterns. These are numbers that show us for instance how much a person weighs or how long it takes to drive from point A to point B. Leading indicators are easier to influence, and can be used to change behavior or the environment at the moment, but require processes/tools to do so. These are numbers that are changing more rapidly like caloric intake/expenditure and current vehicle speed/fuel or if there is traffic on the route causing delays.
While the presentation covered much more, it had previously not crossed my mind where a project's metrics originated. Yet these leading and lagging indicators spoke to me and changed my perspective of tracking data. I even partially took them as inspiration for the aviation theme of this blog post!
The Hot Take The Wheel
Overall, AgileDC 2019 was a fantastic experience and allowed me to take a birds-eye-view of the agile world. So what did the conference lack the most? Might I dare to say: More developers! As I learned, most people are not aware agile originated from developers. But even so, most of us have taken a backseat as a passenger on the agile aircraft and let the process steer. It should be the other way around. Developers or not, more team members need to take control of the agile process and either drive what they are already a part of or launch that which is needed on their projects.
