We've been talking to Johanna Rothman, a software development consultant/coach, about her upcoming workshop on...
"Agile Architecture" at the Agile Development Practices Conference. In part one of our series, we talked about the workshop format, and what "Agile architecture" might mean.
With part two, we pick up the conversation, talking about what an "Agile architect" might do, about "architecture debt," and, finally, where to go for more.
SSQ: Historically, technical architects have held decision-making authority for products at the design level, while Agile approaches spread out those decisions. Your abstract speaks of an "Agile architect" role; can I ask what that means in a world of self-organized, self-directed product teams?
Rothman: The architect doesn't hold that authority alone. No sirree. The program architect is the custodian for the program architecture. In the same way the program manager is the custodian for the program level of the risks and status, and the program product owner is the custodian for the program backlog, the program architect is the custodian for the program architecture. The feature teams own their architecture, and they have architects who help guide their parts of the framework, always talking to their peer architects and the program architect. Think conductor, not driver. This is still Agile.
I have not yet seen concurrent programs where the program architect person changes during the course of the program -- I wouldn't expect to. In a phased program, I would expect to see the program architect change over time.
SSQ: Your proposal also promises to help teams manage architectural debt. Tell us about that -- what is architectural debt, and what are some methods to manage it?
Rothman: Here's what Rebecca and I wrote in the workbook: "Architecture debt represents a compromise in the structure and/or implementation of a solution that has significant impacts." The debt is not simply what you owe the system; it impacts the system in many ways. It affects how the system works, it affects your ability to add to the system. You often take the compromise to buy time. That's okay, but know why you are buying time and how much time you are buying. Sometimes, you are not buying nearly enough time for the debt you take on. Sometimes, it's a lot like a balloon mortgage that's due next month.
Some ways to manage it are:
- Acknowledge that unless you actively track debt, you will have it. This is essential in a program.
- Make refactoring a way of life. You are not done unless you have refactored -- none of this nonsense of being too busy to refactor. You build refactoring into your definition of done.
- Make unit tests or TDD a way of life. You are not done unless you have unit tests. Same as #2.
- Thinking hard about where the GUI goes and where the API goes and no building of any intelligence into the GUI. This is not easy, and it's necessary because it allows you to build automated tests under the GUI where they belong.
- Removing duplicate code.
- Defining and using consistent implementation practices, such as common APIs, standards for errors, logging, and whatever else your system needs.
It's easy to build debt in a system. We didn't discuss the easy and obvious ways of not adding more debt, such as easy and fast builds -- we take that for granted.
What we are seeing is that people have done the "easy" parts of Agile: the timeboxes, the builds, the continuous integration. I don't want to discount their work. I bet for many of them those three pieces were not easy! But you can't just do what I think of as the project management pieces without the engineering pieces and remain Agile. You certainly can't use Agile for a program, a collection of interlinked projects and make it work together successfully without the engineering practices.
SSQ: Thank you for participating; it sounds like it's going to be a fascinating time. For those of us who can't get to Las Vegas next month, can you give us some pointers to go for more?
Rothman: Rebecca and I are running the first private workshop in Seoul just before the conference, and then the first public workshop at the conference. We'll be posting the workshop description on our websites, http://www.jrothman.com and http://www.wirfs-brock.com. We expect to iterate!
A former programmer, manager and software executive, Johanna Rothman has spent the past sixteen years as an independent consultant and coach on software development. During that time she's managed to accumulate a collection of kudos -- from a string of keynote speaking engagements, to acting as general conference chair for the Agile 2009 conference, to writing four books, and, perhaps most importantly, leaving a slew of successful clients in her wake.
Dig Deeper on Agile Software Development (Agile, Scrum, Extreme)