Agile Zone is brought to you in partnership with:

Simon lives in Jersey (Channel Islands) and works as an independent consultant, specialising in software architecture, technical leadership and the balance with agility. Simon regularly speaks at international software development conferences and provides consulting/training to software teams at organisations across Europe, ranging from small startups through to global blue chip companies. He is the founder of "Coding the Architecture" (a website about pragmatic, hands-on software architecture) and the author of "Software Architecture for Developers" (an e-book that is being published incrementally through Leanpub). He still likes to write code too, primarily in .NET and Java. Simon is a DZone MVB and is not an employee of DZone and has posted 36 posts at DZone. You can read more from them at their website. View Full User Profile

Moving Fast Requires Good Communication

12.16.2012
| 3224 views |
  • submit to reddit

But we've lost the ability to visualize our software

If you're working on an agile software development team at the moment, take a look around at your environment. Whether it's physical or virtual, there's likely to be a story wall or Kanban board in order to visualize the work remaining to be started, in progress and done.

Kanban board

We're adept at visualizing our software development process

Why? Put simply, it's a fantastic way of introducing transparency into software projects because anybody can see, at a glance, a snapshot of the current progress at a high-level. Couple this with value stream mapping and you can start to design some pretty fancy looking Kanban boards to reflect that way that your team works. In a nutshell, we've become pretty adept at visualising our software development process.

But we've forgotten how to visualize the software that we're building

However, it seems we may have forgotten how to visualize the actual software that we're building. I'm not talking about post-project documentation here (that's a story for another day), I'm talking about communicating "the big picture". Why is this important? Well, if you want to ensure that everybody is contributing to the same end-goal, you need to be able to communicate the vision of what it is you're building. And if you want agility and the ability to move fast, you need to do this effectively and efficiently. You can argue about whether notations such as UML offer an effective way to communicate software architecture or not, but that's often irrelevant as a starting point because many teams have already thrown out UML or simply don't know it. What's the result? Usually boxes and lines diagrams like the sketches below.

Architecture sketches

Boxes and lines diagrams *can* work very well, but there are many pitfalls associated with sketching software architecture in this way. My approach is to use a collection of simple diagrams, each showing a different level of abstraction.

Effective architecture sketches

All of my guidance around doing this is going to be enhanced and included in my software architecture e-book


Published at DZone with permission of Simon Brown, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)