Dante can be Agile too
[I recently gave a talk for the monthly SEI Agile Collaboration Meeting. The Agile Collaboration Meeting brings together upwards of 50 or so agile practitioners from throughout the federal and DoD space including civilian contractors. This post is a summary of the talk I gave at the September meeting.]
When you do a search for pictures of "unrequited love" one of the first images that comes up is this 1884 painting by Henry Holiday titled "Dante and Beatrice." As Beatrice and Dante were Italians it is extremely important that you pronounce her name in your mind correctly – Bee-a-tree-che – using the Italian pronunciation. In this painting you see Dante, the poet of the Divine Comedy among many other works, chilling on a bridge as he is snubbed by a posse of three women. Beatrice is the one in yellow completely ignoring Dante, who probably went out of his way to be in the right place at the right time so he could see her.
In real life, Dante was obsessed with Beatrice. They met when they were children and their families cruised in many of the same social and professional circles. Allegedly it was love at first sight for Dante, then age 9. Both Dante and Beatrice married other people and apparently met only one other time before Beatrice died at the young age of 24. Dante wrote of Beatrice as "his savior" and she was a prominent character in his Vita Nova (a collection of poems professing his love for both the actual and a metaphorical Beatrice) and Divine Comedy (in which she escorts Dante through Heaven).
I propose that there is an unrequited love between the software architecture and agile communities; software architecture is the Dante to an agile Beatrice who simply ignores him. Certainly if this were true there would be some observable facts to either support or refute this idea.
The Agile conference is about 10x larger than SATURN both in terms of size and number of submissions. That being said both conferences have a similar peer review process in which experts from the community review and recommend submissions for inclusion in the program and both conferences are focused on practice opposed to academic research.
My hypothesis is that the software architecture community "loves" agile more than the agile community "loves" software architecture. The implication being that architectures "love" for agile is not returned, or unrequited. I would expect this to be evident in the session topics presented at each conference.
I looked at the schedules for all Agile and SATURN conferences since 2011. For each I used "expert judgment" to determine, based on the title, abstract, and speaker, whether the topic might be relevant in a different community. In the Agile schedules I was looking for software architecture talks. In the SATURN schedules I was looking for agile topics.
I'll fully admit that a single data point of "expert judgment" is not the most rigorous test, but it's a start. Am I an expert? I have been a regular speaker and attendee at various agile and software development and design conferences since 2009. I've attended both SATURN and Agile twice in this time frame. I've helped with the review committee for Agile experience reports since 2012 and SATURN since 2013. I was the technical chair for SATURN in 2014 and I am a technical co-chair for SATURN 2015. I also have a Master in Software Engineering from Carnegie Mellon and have studied and practiced both agile and software architecture fairly extensively in my career as a software engineer so far. It's not perfect, but I have enough perspective for the analysis I hope.
For the Agile conference I was looking for topics that were directly related to software architecture. The basic rubric was anything related to the following topics (and I tried to be really liberal in what I included).
For the SATURN conference I was looking for topics that were directly related to agile software development methods. I tended to be a little stricter on the SATURN sessions mostly because I felt that "agile" was a generally broader topic than architecture.
Again, the basic question I asked is, "Would this session work at the other conference?" If yes, it was a +1 for that community's love of the other.
Looking at the percentages paints a completely different picture. Close to a quarter – 22% – of the talks at SATURN are agile-related while barely 5% of talks at Agile deal with software architecture related topics. The Agile Conference consistently had about 145 sessions in the schedule while SATURN had about 35 sessions in 2011 and 2012 and 45 sessions in 2012 and 2014. Using these approximate totals with the previous raw counts table gives the following percentage of sessions that might fit in at the other conference.
This seems like pretty overwhelming evidence in support of the hypothesis. As a side note, this result is definitely dependent on the proxy used. For example, I haven't done the analysis but my experience with the XP conference in Europe and the European Agile community in general is that they have a much greater focus on architecture and design than in the US.
Another interesting data point in support of the hypothesis is the SATURN "Architecture in Practice" Best Presentation award. Interestingly, 4 out of 5 of the awards have gone to presentations on agile or lean topics since the award was introduced in 2010.
There really isn't an equivalent award at the Agile Conference that spans across nearly all sessions like it does at SATURN, but this is still an interesting data point. The SATURN "Architecture in Practice" award is "awarded to the presentation that best describes experiences, methods, and lessons learned from the implementation of architecture-centric practices." It's a peer voted award in which the attendees decide the winner via voting cards turned in just before the final keynote at the conference.
The hypothesis is generally supported (with plenty of caveats and room for debate)... but the more interesting question might be: Why does this unrequited love exists in the first place?
To understand this question we have to understand a little more about how software is developed and the roles that agility and architecture play in software development.
Consider a continuum of knowledge. If I were to graph this (see below), the higher on the continuum you are, the more vision-oriented thinking you're doing. Meanwhile the lower on the continuum the more detail-oriented you think. An easy way to look at this is that the CEO and product management types are dealing with very coarse grained abstractions at the conceptual idea level toward the top, while programmers are dealing with much finer grained abstractions at the detailed level toward the bottom.
At some point to build some software you have to cross over a theoretical "realization boundary" in which your ideas are translated into reality. A vision eventually becomes code. An interesting implication of this continuum is that the higher up you are (idea stuff) the easier it is to change while the lower down (concrete stuff) the more difficult it is to change. So in some ways, the foundation of what will become reality is built upon the stuff that is easiest to change.
This shouldn't be too surprising, but given that the stuff of dreams (the vision for a software system) essentially form the foundation for what eventually gets built, you create a situation where you almost have a house built on sand. The visionary leader lives in a world that is easy to change and for reasons both silly and mission critical, this means that the software we build must be easily changeable too. Miss the boat on this and you risk the ire of your visionary at best, becoming irrelevant and missing business opportunities at worst.
It's almost as if we've created a house built on sand. And indeed a hot and valuable topic that comes up often is creating pliable, malleable architectures so you can respond to change more easily.
A central focus of software architecture is in understanding how to transition the "realization boundary" so that the vision can become real software. This makes sense because software architects are required to live in both the vision-oriented and detail-oriented worlds. It is the responsibility of the architect to chaperon the vision from the minds of stakeholders to the fingers of the programmers.
To characterize very broadly, Agile generally does a great job dealing with either vision-oriented stuff or detail-oriented stuff, but rarely addresses crossing this realization boundary. It's like that comic about the mathematician who does some hand waving -- "a miracle appears here" -- in the middle of a complex proof to arrive at a solution.
The insights surfaced by this vision-to-detail model is interesting, but it still doesn't explain exactly why this might be happening. If embracing change is the point, and if software architecture strives to support agility, then why is architecture's love still unrequited?
The answer in this case may come down to the nature of agile and architecture. Agile software development promotes preserving choice while software architecture promotes preserving structure. In many ways there is a natural tension in these two ideas, even when you are trying to preserve structure that preserves choice (head spinningly meta, I know).
Ultimately, for any team, a lot of things have to go "just right" for a team to be agile. It's more than just the methods they use, it comes down to culture and perhaps even grit. As an agile software architect, I believe that having a solid understanding of software architecture design is one of the more important and interesting things required for everything to go "just right" so a team can be agile. There are other philosophies as well, and the best part is that they all can work in the right circumstances.
And what's better than attending? Presenting! The submissions system is open now and proposals are being reviewed and accepted on a continuous basis through January 16, 2015. Submit early to improve your chances of acceptance. Submit as many talks as you want.
SATURN is a great conference for agile architects and I hope to see you in Baltimore this April!
When you do a search for pictures of "unrequited love" one of the first images that comes up is this 1884 painting by Henry Holiday titled "Dante and Beatrice." As Beatrice and Dante were Italians it is extremely important that you pronounce her name in your mind correctly – Bee-a-tree-che – using the Italian pronunciation. In this painting you see Dante, the poet of the Divine Comedy among many other works, chilling on a bridge as he is snubbed by a posse of three women. Beatrice is the one in yellow completely ignoring Dante, who probably went out of his way to be in the right place at the right time so he could see her.
In real life, Dante was obsessed with Beatrice. They met when they were children and their families cruised in many of the same social and professional circles. Allegedly it was love at first sight for Dante, then age 9. Both Dante and Beatrice married other people and apparently met only one other time before Beatrice died at the young age of 24. Dante wrote of Beatrice as "his savior" and she was a prominent character in his Vita Nova (a collection of poems professing his love for both the actual and a metaphorical Beatrice) and Divine Comedy (in which she escorts Dante through Heaven).
I propose that there is an unrequited love between the software architecture and agile communities; software architecture is the Dante to an agile Beatrice who simply ignores him. Certainly if this were true there would be some observable facts to either support or refute this idea.
 |
| Dante and Beatrice, painting by Henry Holiday (1884) |
Hypothesis: The Software Architecture Community "Loves" Agile more than the Agile Community "Loves" Software Architecture
To test this hypothesis I will examine submissions from popular agile and software architecture conferences. The two proxies I will use are the SATURN conference representing the software architecture community, and the national Agile conference (sometimes called "The Big Agile Conference") representing the agile community. Both conferences are about 10 years old and are practitioner focused events that attract a good mix of working professionals and thought leaders.The Agile conference is about 10x larger than SATURN both in terms of size and number of submissions. That being said both conferences have a similar peer review process in which experts from the community review and recommend submissions for inclusion in the program and both conferences are focused on practice opposed to academic research.
My hypothesis is that the software architecture community "loves" agile more than the agile community "loves" software architecture. The implication being that architectures "love" for agile is not returned, or unrequited. I would expect this to be evident in the session topics presented at each conference.
Testing Method: Conference Sessions Analysis
Love for a topic might be shown by the number of talks that are accepted on that topic at each conference. For example, the presence of a software architecture related talk at the Agile conference would indicate a +1 for Agile's love of software architecture.I looked at the schedules for all Agile and SATURN conferences since 2011. For each I used "expert judgment" to determine, based on the title, abstract, and speaker, whether the topic might be relevant in a different community. In the Agile schedules I was looking for software architecture talks. In the SATURN schedules I was looking for agile topics.
I'll fully admit that a single data point of "expert judgment" is not the most rigorous test, but it's a start. Am I an expert? I have been a regular speaker and attendee at various agile and software development and design conferences since 2009. I've attended both SATURN and Agile twice in this time frame. I've helped with the review committee for Agile experience reports since 2012 and SATURN since 2013. I was the technical chair for SATURN in 2014 and I am a technical co-chair for SATURN 2015. I also have a Master in Software Engineering from Carnegie Mellon and have studied and practiced both agile and software architecture fairly extensively in my career as a software engineer so far. It's not perfect, but I have enough perspective for the analysis I hope.
For the Agile conference I was looking for topics that were directly related to software architecture. The basic rubric was anything related to the following topics (and I tried to be really liberal in what I included).
- Software architecture – include methods, notations, design, and lessons learned kinds of talks
- Technology – how things work and why and when you'd use them
- Technical debt
- Modeling or enterprise architecture
- Anything that dealt with requirements beyond just user stores, features, and functional requirements – I was looking for broader thought about system quality attributes.
For the SATURN conference I was looking for topics that were directly related to agile software development methods. I tended to be a little stricter on the SATURN sessions mostly because I felt that "agile" was a generally broader topic than architecture.
- Lightweight or lean methods – things that might not have come out and said "I'm agile" but were definitely in the spirit of agility.
- Architecture in agile context – for example talking about an agile team or experience
- Continuous delivery – both technology and value
- Technical debt
Again, the basic question I asked is, "Would this session work at the other conference?" If yes, it was a +1 for that community's love of the other.
Results of the Analysis
Looking at raw session counts, the two conferences seem about even in the time frame I examined with about 30 sessions at the Agile Conference that would likely work well at SATURN and about 35 sessions at SATURN that would likely do well at the Agile conference. I know for a fact that at least a few of the sessions definitely fit in this category since there are few repeat presenters including myself, Rebecca Wirfs-Brock, Andy Hunt, and Joe Justice among others.| Agile | SATURN | |
|---|---|---|
| 2011 | 10 | 7 |
| 2012 | 6 | 8 |
| 2013 | 9 | 9 |
| 2014 | 5 | 11 |
| Total | 30 | 35 |
Looking at the percentages paints a completely different picture. Close to a quarter – 22% – of the talks at SATURN are agile-related while barely 5% of talks at Agile deal with software architecture related topics. The Agile Conference consistently had about 145 sessions in the schedule while SATURN had about 35 sessions in 2011 and 2012 and 45 sessions in 2012 and 2014. Using these approximate totals with the previous raw counts table gives the following percentage of sessions that might fit in at the other conference.
| Agile | SATURN | |
|---|---|---|
| 2011 | 7% | 21% |
| 2012 | 4% | 18% |
| 2013 | 6% | 26% |
| 2014 | 3% | 24% |
| Total | 5% | 22% |
This seems like pretty overwhelming evidence in support of the hypothesis. As a side note, this result is definitely dependent on the proxy used. For example, I haven't done the analysis but my experience with the XP conference in Europe and the European Agile community in general is that they have a much greater focus on architecture and design than in the US.
Another interesting data point in support of the hypothesis is the SATURN "Architecture in Practice" Best Presentation award. Interestingly, 4 out of 5 of the awards have gone to presentations on agile or lean topics since the award was introduced in 2010.
There really isn't an equivalent award at the Agile Conference that spans across nearly all sessions like it does at SATURN, but this is still an interesting data point. The SATURN "Architecture in Practice" award is "awarded to the presentation that best describes experiences, methods, and lessons learned from the implementation of architecture-centric practices." It's a peer voted award in which the attendees decide the winner via voting cards turned in just before the final keynote at the conference.
The hypothesis is generally supported (with plenty of caveats and room for debate)... but the more interesting question might be: Why does this unrequited love exists in the first place?
From whence doth this apparent unrequited love arise?
To understand this question we have to understand a little more about how software is developed and the roles that agility and architecture play in software development.
Consider a continuum of knowledge. If I were to graph this (see below), the higher on the continuum you are, the more vision-oriented thinking you're doing. Meanwhile the lower on the continuum the more detail-oriented you think. An easy way to look at this is that the CEO and product management types are dealing with very coarse grained abstractions at the conceptual idea level toward the top, while programmers are dealing with much finer grained abstractions at the detailed level toward the bottom.
 |
| Ideas are easier to change and must eventually become something more detailed and concrete which in turn becomes more difficult to change. Kind of "duh" but the model makes some interesting implications a little more obvious. |
At some point to build some software you have to cross over a theoretical "realization boundary" in which your ideas are translated into reality. A vision eventually becomes code. An interesting implication of this continuum is that the higher up you are (idea stuff) the easier it is to change while the lower down (concrete stuff) the more difficult it is to change. So in some ways, the foundation of what will become reality is built upon the stuff that is easiest to change.
This shouldn't be too surprising, but given that the stuff of dreams (the vision for a software system) essentially form the foundation for what eventually gets built, you create a situation where you almost have a house built on sand. The visionary leader lives in a world that is easy to change and for reasons both silly and mission critical, this means that the software we build must be easily changeable too. Miss the boat on this and you risk the ire of your visionary at best, becoming irrelevant and missing business opportunities at worst.
 |
| A "visionary leader" (CEO or Product Management or others for example) can change their minds easily for a variety of silly and very legitimate reasons. Can your architecture stand up to the change? |
Embracing Change is the name of the game
Software is built easily changeable premises and I will argue that as frustrating as this can be, it's actually a really, really good thing. It seems then that the implication of all of this is that enabling agility is the whole point of software architecture. The key to this lies in understanding how to cross that "realization boundary".A central focus of software architecture is in understanding how to transition the "realization boundary" so that the vision can become real software. This makes sense because software architects are required to live in both the vision-oriented and detail-oriented worlds. It is the responsibility of the architect to chaperon the vision from the minds of stakeholders to the fingers of the programmers.
To characterize very broadly, Agile generally does a great job dealing with either vision-oriented stuff or detail-oriented stuff, but rarely addresses crossing this realization boundary. It's like that comic about the mathematician who does some hand waving -- "a miracle appears here" -- in the middle of a complex proof to arrive at a solution.
The insights surfaced by this vision-to-detail model is interesting, but it still doesn't explain exactly why this might be happening. If embracing change is the point, and if software architecture strives to support agility, then why is architecture's love still unrequited?
 |
| Dante (Software Architecture): "Hi, Agile, I'm ready to embrace change!" Beatrice (Agile): *sigh* "It's that software architecture again... he's just so... structured." /eyeroll |
The answer in this case may come down to the nature of agile and architecture. Agile software development promotes preserving choice while software architecture promotes preserving structure. In many ways there is a natural tension in these two ideas, even when you are trying to preserve structure that preserves choice (head spinningly meta, I know).
Ultimately, for any team, a lot of things have to go "just right" for a team to be agile. It's more than just the methods they use, it comes down to culture and perhaps even grit. As an agile software architect, I believe that having a solid understanding of software architecture design is one of the more important and interesting things required for everything to go "just right" so a team can be agile. There are other philosophies as well, and the best part is that they all can work in the right circumstances.
SATURN 2015 is an Great Conference for Agile Architects
I've said it before and here it is again, XP is a great conference. The "big" Agile conference is pretty good too. But SATURN is probably the best conference I've seen for software architects. If you are a software architect or interested in software architecture and anyway involved with an agile project, then SATURN is probably a better learning and networking event for you than the Agile conference. For these topics, the signal to noise ratio is very good. The conference itself is relatively small which means more meaningful network and greater engagement. There is just an all around higher density of software architecture information.And what's better than attending? Presenting! The submissions system is open now and proposals are being reviewed and accepted on a continuous basis through January 16, 2015. Submit early to improve your chances of acceptance. Submit as many talks as you want.
SATURN is a great conference for agile architects and I hope to see you in Baltimore this April!
Comments
Post a Comment