Meeting notes from 9/27 - What is an "Agile Architect"

[Matt Roberts]

Guys:

Here are my notes from last month's meeting...hope this is helpful!

Matt Roberts

What is an “Agile Architect” to live up to the Agile Manifesto?
- Works at a company experienced significant growth post-acquisition.
Transitioned to being an “Agile Shop”. Ivory tower group of
architects, but now they fan out across the organization, but still
try to collaborate. Being hands-on helps him stay agile. His role:
broad of a design perspective as he can. Look for major technologies
for teams to go in. Try to keep the technological vision for the
team. He works with multiple teams to analysze the overall process—
bring in continuous delivery, better . Discussion about success
criteria.
- Work at a small place where everything was just-in-time, and there
was no ivory tower. More scrabbled together stuff—accidental
architecture. Team is averse to process that “slows them down”. More
subversive—getting in good software engineering practices. People
building too many things that are disparate and don’t work together.
Complete opposite of a bigger company. What management has—don’t have
any formal definition from management.
- Does anyone have success criteria from their managers? Bigger
companies—architects are outside of the hands-on development team,
there is some type of a wall between the teams and architects.
- Other organization, the architect is “supposed to be my boss’s swiss
army knife” idea->go make it happen. We’re always careful to make
sure that it can happen, but it isn’t easy. 3 – 4 scrum teams.
Important to keep skills fresh. When we first started, 3 – 4 months
to get going. Now we put in a few Sprint 0s where they come up with a
plan of action for the technology to be delivered. We run into more
enterprise issues—lots of siloed development groups where we find out
what they’re developing. The right hand doesn’t know what the left
hand is doing. We found out that the index finger and ring fingers
didn’t know what they were doing. By providing oversight and enabling
communication, they can bring up options for reusability. Taken about
7 years for them to think about universal reuse.
- Boss determines success criteria as not having conversations with
him.
- Roadblocks: Corporate politics
- Do you have to put requirements into the backlog?
o I will own the technology, but the Product Owner will own the
business requirements
- Do you have to horse trade between groups?
o Yes, all the time.
- Architects need to have a holistic view to know what’s going on so
you can know what you need to know
o 30 minute technical Scrum of Scrums
o Sitting in the requirements meetings
o Coordination / firefighting was a big part of my role
-How much control do you have over what gets done?
o Doesn’t that come down to credibility?
o Politics and personal behavior vs. desire to support the whole
company.
-How to sell ideas
o Get cross-team pollination
o Prioritization of the backlog, make sure other team members are in
there from various teams
o Cross Product Owner pollination
- So much is politics, but so much is organizational alignment