Archive for September, 2007

Elementary Lessons in Vision and Teaming

Have you read The Goal? It is (still) a pivotal book in the Lean movement. I’ve been telling architects that The Wheel on the School (a children’s story by Meindert deJong) is the hidden jewel of that genre—namely novelization of business fundamentals. I believe it could be a pivotal book in the networked, collaborative, dynamic teaming movement. Is there such a movement? In software development, we see it instantiated in Agile development and Visual Architecting.

I so like The Wheel on the School! The team was chartered: wonder about storks. The team went off, and in their individual styles, wondered. They created a shared vision. Then they each went off in different directions, like the spokes of a wheel, but with a common vision unifying their search for a solution. The whole village got pulled into the creation of the solution, at different points. The team told vivid vision stories to motivate and inspire various people along the way. More and more people got drawn into creating the solution; taking risks, doing what it takes. The core team, working like cogs, pulled in teams of teams. Sometimes all working together, sometimes as smaller teams. Fluid, dynamic, ever-changing teams. Through action, they made the vision real. People changed; changed their self-concept, changed the communities concept of them. In changing how they viewed themselves, in changing how they viewed others, they built the team. A team needs diversity and a team is transformative; or it can be. They made their vision real: they wondered, they created a shared vision, and they set the wheels of action in motion. 

This is Kotter’s 8 steps of leading change in one delightful story you can even share with your kids. Or have them teach you. An open mind. A willingness to wonder. A willingness to think outside the box of convention. If you want to create, to lead, and you don’t relate to this book, please do tell me! The first 3 chapters on creating a shared vision will either have your attention, or you’ll be lost in translation. Not so much to invest then. And, if you find it useful, by all means tell us what lessons you found radiating from this gem of book.

While I’m recommending books for leaders, I also really like  Stephen Denning’s The Leader’s Guide to Storytelling: Mastering the Art and Discipline of Business Narrative, Jossey-Bass, April 22, 2005.  I see he has a follow-up book due out in October called The Secret Language of Leadership, (2007). 

Comments

Architecture and the Agile Quest

If you’re interested in Agile and Architecture, here’s an interesting read, including the comments: The Demise of the Gantt Chart in Agile Software Projects, by Tate Stuntz on July 31, 2007. I have to agree with David Christiansen: “I’m not convinced there is such a thing as a methodology or process that can produce good architecture.People create great architecture, just like it is people that create great software systems. But are there things we can do to create better architectures, and better software systems? Of course I believe there are! That’s where process comes in.

In manufacturing we learned that if we inspect quality in at the end, the cost of quality (a term that refers to the cost of poor quality that leaks through the inspection process, as well as the cost of removing found defects) is much, much higher than if we find potential quality problems at the source, to ensure they aren’t inserted. 

Architecture defects, those that have diffuse impact across the system, are so expensive they are hard to recover from when they are only discovered once the architecture is hard-cast in code. Hard-cast, I say, because though we think software is pliable while we are writing code, the volume of it quickly amasses, and with it sunk cost and sunk time. And we don’t, as an industry, understand sunk cost and sunk time terribly well! It is a huge reset to go back and rework the system to accommodate an architectural change of any significance. Because we perceive software as highly mutable, we think we can recover if we scramble, but our accommodations to the code make it ever more immutable as the structure erodes to the point where it is hard and unpredictable to change.

More expensive still, have to be products that are defective in concept, set to miss the market. Getting the product or application concept right–the value propositions that will deliver customer advantage and delight–is not a feel-our-way-as-we-build kind of thing. It is a strategic matter. Or at least, get the strategy wrong, and all the tweaks in the world are going succeed only by amazing luck and sheer heroics.

And yet, it seems to be asking for suspension of disbelief to ask for time on a project where all that is being produced is models, diagrams, stories, even if this work is toward a minimalist set of strategic decisions. Putting features in front of users, why, that is what creating software is all about. That is where we can see progress.

Still, if progress is moving towards a better sense of what our customers value, across use contexts, and all that decision space complexity, then we can make a lot of progress quickly and cheaply with models (and mock-ups and proof-of-concept/prototypes). And by exploring how those features play out over our posited architecture structures, we can refactor early, cheaply, while all we are changing is models and descriptions.

To help people create great architectures, our process needs to:

  • lead us to work in an integrative, collaborative way (without becoming a “committee”)

  • explore and visualize value opportunities and value delivery mechanisms, to establish architecturally significant requirements and architecture strategy

  • learn quickly through iterative cycles.

Yes, this is an agile process, if we make models recognized citizens of the software world, with full rights to authenticity and budget! In all we do, we have to find a good balance. Our models should not be belabored, certainly not early on, by putting in too much detail or trying to make them look pretty too early in a tool where pretty is hard to do once, let alone with changes.

We also need to open up our “agile” concept of customer. I highly recommend  Hidden in Plain Sight. I’ve also written about delight (key to customer advantage) various places in my architects/architecting/architecture journal notes (e.g., Vitruvius and delightcircle of excellence and (skipping the first paragraph) Zappos demonstrates that IT Does Matter).

What we are trying to do is surface and understand value propositions that users and other stakeholders find compelling. And find and improve the structures (architectural components and mechanisms) that will support the system through the sprints leading up to the first release, and beyond.

 

Comments

Agile Architecting

The Agile Manifesto articulates the following core values:

  • Individuals and interactions over processes and tools

  • Working software over comprehensive documentation

  • Customer collaboration over contract negotiation

  • Responding to change over following a plan

In essence, informal, iterative, adaptive processes that rely on the collaboration of empowered individuals are strongly favored over formal, bureacratic process and its accoutrements (plans, contracts, comprehensive documentation).  If we overlay these values with values for enabling dynamic teaming, value delivery and risk management, we have the value-set that underlies the Visual Architecting Process.

Short iterative cycles, early involvement of stakeholders, and visualization, allow for quick learning, early direction setting and iterative direction correction and refinement. But this learning is done with models as long as they are effective, reducing the cost of change as the architectural design is explored, refined and elaborated. Along the way, the architecture is documented, both to aid the architects in thinking through approaches and alternatives, and as a communication tool to get input and feedback from a broad set of stakeholders.

The process promotes early discovery of opportunity to innovate and differentiate, and builds alignment and motivation through a strong, shared vision and high-level system design that identifies system building blocks that, for large systems, become the units of agile development, allowing further innovation and experiment, with generally lower cost of changelowered by isolating the impact of change.

This process then, allows us to integrate the best of agile software practices along with other practices used to get complex products created in reduced timenamely, allowing more people to be effective, productive and creatively engaged in building the system, because they have clear commitments to and from the system via the system design, and, yes, its documentation.

Embrace agile development and refactoring. Just start with models, work with all of the agile philosophies while the team is using models and document with sketches (visual and verbal) of the overall system and the key architectural mechanisms. Some of our lessons are learned the hard way, through discovery that necessitates refactoring at the code level. Others can be discovered by modeling the system and refactoring at the conceptual architectural element (module, component, service) level. Others are more apparent; we have after-all, some experience building software systems!  Yes, the ground is constantly shifting under our feet–the competitive landscape, and the technological landscape, keep changing, sometimes in revolutionary ways. But at the same time, dominant designs emerge that see us through periods of system evolution.

Naturally, I’ve defended (just enough) architecture documentation various places:

This piece is intended to plead the case for documentation within an agile culture

Also related:

On Agile and Documentation

and while I wouldn’t toss the proverbial baby out with the bathwater:

Colm Smyth has a series of posts titled “Debugging Extreme Programming–Agile not Fragile” that is architect-friendly; see, for example, Refactoring, On-site Customer and Metaphor.

 

 

 

Comments (2)