Agile Architecture and Program Myths

Johanna Rothman, known as the "Pragmatic Manager," offers frank advice for your challenging problems. She consults with leaders and teams to help them learn about practical and possible options. They can then decide how to adapt their product development. Her most recent book is "Project Lifecycles: How to Reduce Risks, Release Successful Products, and Increase Agility." See www.jrothman.com for all her books.

  Agile   Applications Delivery   Information Technology   Quality   Requirements Management   Strategy   Testing/Test Management  

I’ve been developing an agile architecture workshop with Rebecca Wirfs-Brock. Aside from more Murphy’s Law moments than a small project deserves, we’ve encountered a number of agile architecture and program myths. Here are three for your reading pleasure. (Just in case you aren’t sure, all of these are false--they are myths.)

“We don’t need no stinkin’ architects!”
If I have a large and complex program (say more than five teams) and the product includes firmware or hardware, I like guided evolution with program architects. Why? Because the cost of having unknown architecture for too long presents too high a risk. By “guided evolution”, I mean the architects might do some initial wayfinding, prototyping and exploration (or even lead all the teams in the initial wayfinding, prototyping and exploration) so that the alternatives for the program are clearer.

I once worked with a team of all junior people--60 of them--and they knew they did not have the experience to work on the product. They knew they were missing key experience and they did not know what they were missing. They wanted an architect--not to dictate, but to help show them where to explore.

On the other hand, if you have a small program (say of fewer than five teams) and are working on a software-only product, maybe the risk of unknown …

Please log in or sign up below to read the rest of the article.