{"id":12029,"date":"2013-10-25T16:02:22","date_gmt":"2013-10-25T13:02:22","guid":{"rendered":"https:\/\/mozaicworks.com\/?p=5900"},"modified":"2023-09-15T15:08:37","modified_gmt":"2023-09-15T12:08:37","slug":"architecture-at-agile-2013","status":"publish","type":"post","link":"https:\/\/mozaicworks.com\/blog\/architecture-at-agile-2013","title":{"rendered":"Architecture at Agile 2013"},"content":{"rendered":"

(Guest blog post by Rebecca Wirfs-Brock<\/a>, originally appeared on\u00a0her blog<\/a>. Republished with permission.)<\/em><\/p>\n

What a busy, intense week Agile 2013 was! It was a great opportunity to connect with old friends and meet folks who share common interests and energy. I also had a lot of fun spreading the word\/exchanging ideas about two things I\u2019m passionate about: software architecture and quality.<\/span><\/span><\/p>\n

\n

At the conference I presented\u00a0\u201cWhy we need architecture (and architects) on Large-Scale Agile Projects\u201d<\/a>. I\u2019ve presented this talk a few times. This time I added \u201cLarge Scale\u201d to the title and submitted it to the enterprise agile track. I wanted to expose the audience to several ideas: that there are both small team\/project architecture practices and larger project\/program architectural practices that can work together and complement each other, what it means to be an architecture steward, and some practices (like Landing Zones, Architecture Spikes, and Bounded Experiments\/prototyping, and options for making architecture-related tasks visible).<\/p>\n

I spoke with several enthusiastic architects after my talk and throughout the week. They shared how they were developing their architecture. They also asked whether I thought what they were doing was made sense. In general, it did. But I want to be clear: One size doesn\u2019t fit all. Sometimes, depending on risks and the business you are in, you need to invest effort in experimenting\/noodling\/prototyping before committing to certain architectural decisions. Sometimes, it is absolutely a waste of time. It depends on what you perceive as risky\/unknown and how you want to deal with it. The key to being successful is to do what works for you and your organization.<\/p>\n

Nonetheless, in my talk when I spoke about some decisions that are too important to wait until the last moment, someone interrupted to say that I had gotten it wrong: \u201cIt isn\u2019t the last possible moment, but the last responsible moment\u201d.\u00a0I know that.<\/strong>\u00a0Yet I\u2019ve seen and heard too many stories about irresponsible technical decision-making at the last possible moment instead of the last responsible moment. People confuse the two. And they use agile epithets to justify their bad behaviors. Surprise, surprise. The \u201clast responsible moment\u201d can be misinterpreted by some to mean, \u201cI don\u2019t want to decide yet (which may be irresponsible)\u201d. People rarely make good decisions when they are panicked, overworked, stressed out, exhausted or time-crunched.<\/p>\n

Check out my blog posts on the\u00a0Last Responsible Moment<\/a>\u00a0and\u00a0decision-making under stress<\/a>\u00a0if you want to join in on that conversation.<\/p>\n

But I digress. Back to architecture.<\/p>\n

I was happy to see two architecture talks on the Development and Software Craft track. I attended Simon Brown\u2019s \u201cSimple Sketches for Diagramming your Software Architecture\u201d and also had the pleasure of hanging out with Simon to chat about architecture and sketching. Simon presented information on how to draw views of a system\u2019s structure that are relevant to developers, not too fussy or formal, yet convey vital information. This isn\u2019t hardcore technical stuff, but it is surprising how many rough sketches are confusing and not at all helpful. Simon regularly teaches developers to draw practical informative architecture sketches. He collects sample sketches from students before and after they receive his sketching advice. Their improvement is remarkable. If you want to learn more, go to Simon\u2019s website, CodingTheArchitecture.com<\/a><\/p>\n

I shared with Simon the sketching exercises in my\u00a0Agile Architecture<\/a>\u00a0and\u00a0Developing and Communicating Software Architecture<\/a>\u00a0workshops\u2026and pointed him to two books on I\u2019ve drawn on for drawing inspiration: Nancy Duarte\u2019s\u00a0slide:ology<\/em><\/a>\u00a0and Matthew Frederick\u2019s\u00a0101 Things I Learned in Architecture School<\/em><\/a>. It\u2019s all about becoming better communicators.<\/p>\n

Scott Ambler talked about Continuous Architecture & Emergence Design. I was happy to see that he, too, advocated architecture spikes and envisioning (and proving the architecture with evidence\/code). In his abstract he states: \u201cDisciplined agile teams will perform architecture envisioning at the beginning of a project to ensure that they get going in the right direction. They will prove the architecture with working code early in construction so that they know their strategy is viable, evolving appropriately based on their learnings. They will explore new or complex technologies with small architecture spikes. They will explore the details of the architecture on a just-in-time (JIT) basis throughout construction, doing JIT modeling as they go and ideally taking a test-driven-development (TDD) approach at the design level.\u201d<\/p>\n

There are way too many concurrent sessions and too few hours in the day to get to all the talks I\u2019d have liked to attend. I just wished I\u2019d been able to attend Rachel Laycock and Tom Sulston\u2019s talk on the DevOps track, \u201cArchitecture and Collaboration: Cornerstones of Continuous Delivery\u201d\u2026but instead I enjoyed Claire Moss\u2019 \u201cBig Visible Testing\u201d experience report. Choices. Decisions.<\/p>\n

If you\u2019d like to continue the conversation about architecture on agile projects, I\u2019d love to hear from you.<\/p>\n<\/div>\n

\n

Would you like to improve the architecture and design of your project?\u00a0We can help with:<\/em><\/p>\n