change the build system to be able to build in under a week. It took another six months to get the build down to two days, but by then, they only needed five people to build. Now, they had ten people available to rearchitect the entire build system so it could take one hour. When I last checked, they were down to six hours without needing anyone to babysit the build, and they still had some work to do.
I also see a lot of technical debt in test automation. If you have a large program, you must have automated regression tests, as well as exploratory tests. You don’t have the time to run lots of manual tests every two weeks.
One of the problems I’ve seen is that the testers wait for the perfect test automation system. I have never seen one perfect test automation system, just as I have never seen one perfect framework for a system. That’s why we need test architects, as well as development architects. Different kinds of testing require different kinds of test automation and different kinds of test automation systems.
The way I like to develop test automation is to build something small, see if it works, and refactor it as I proceed. Now, I’m no architect. I am sure there is a better way to do this, which is why I like to pair every so often with an architect who will say, “JR, if you do it this way, it will be 1,000 times faster.”
How Distributed Is Your Program?
The more distributed the program—that is, the more sites involved— the more you need people to communicate with each other about the architecture, the lower-level design, and how the whole system works together. And, the more distributed the program, the more difficult it is to have those conversations. If you have an architect on a feature team or an architect for a few feature teams, those conversations are more likely to occur, because that person is responsible for them.
Do You Need a Defined Agile Architect Role?
I hope you still think the answer is, “It depends.” Maybe it even depends on more factors than I’ve discussed here. Consider how you can use agile architects to create more ease for everyone in your program and reduce technical risk if:
- You have a program of more than three teams, with fewer opportunities to make decisions about architecture and refactoring and with more pressure for an earlier release date or lots of people
- You are early in your agile transformation
- You have more technical debt than you would like
- You have a distributed program
Your program manager, developers, and testers will thank you.
Pages
About the author
Johanna Rothman, known as the “Pragmatic Manager,” helps organizational leaders see problems and risks in their product development. She helps them recognize potential “gotchas,” seize opportunities, and remove impediments. Johanna was the Agile 2009 conference chair. She is the technical editor for Agile Connection and the author of these books:
- Manage Your Job Search
- Hiring Geeks That Fit
- Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects
- The 2008 Jolt Productivity award-winning Manage It! Your Guide to Modern, Pragmatic Project Management
- Behind Closed Doors: Secrets of Great Management
- Hiring the Best Knowledge Workers, Techies & Nerds: The Secrets and Science of Hiring Technical People
Johanna is working on a book about agile program management. She writes columns for Stickyminds.com and projectmanagementcom and blogs on her website, jrothman.com, as well on createadaptablelife.com.
