Re: Role of Application Architect on Scrum Teams

I agree with Steve s comments -- my teams use a designated architect in each Scrum team with a chief architect responsible at a department level. All of the

Message 1 of 10
, Sep 28, 2004

0 Attachment

I agree with Steve's comments -- my teams use a designated architect
in each Scrum team with a "chief" architect responsible at a
department level. All of the component architects work on a team with
the chief architect to ensure that the standards, patterns, and
overall architectural concepts are applied appropriately and, when
necessary, challenged if a new paradigm is discovered.

mike_schenk@yahoo.com

Grant, I also agree with Steven. Have a Scrum of Scrums. We have been doing as he suggested for over a year now (even though we haven t been using Scrum that

Message 2 of 10
, Sep 28, 2004

0 Attachment

Grant,

I also agree with Steven. Have a "Scrum of Scrums." We have been
doing as he suggested for over a year now (even though we haven't
been using Scrum that long) and it has worked quite well.

A risk in having a specified application architect is that you might
introduce unproductive conflict to the Scrum team(s). A Scrum team
needs the freedom to do whatever is necessary to meet their sprint
goal. Their overriding goal is always to provide working software
that meets their customers' needs. If a standard architecture and
recyclable components are not valuable to the customer, then building
them should not be valuable to the team. If an application architect
is there to enforce those standards, he can become an obstacle to the
team.

I've been in that architect's position where a team has found a
workable solution to a customer problem but I can see a more abstract
solution that would allow it to work for other projects. The team has
already completed their solution and it meets their customer's need,
so who is going to take the time to expand that solution? The team
has no incentive to do so, and I don't have the time.

It can also become quickly overwhelming for one application architect
to keep different projects aligned. Even with two or three small
teams (<5) there is so much design and code produced so quickly,
(because the teams are empowered to solve their own problems), the
architect can have a difficult time keeping up. If the teams wait for
the architect's approval he again becomes an obstacle.

For us the best way of producing recyclable components and consistent
architecture is to have lots of open communication across the various
teams.

We have the "designated architects" meet at least once a week to
describe in general what the teams are working on. This gives us a
chance to coordinate dependencies, recognize problems another team
has already solved, offer suggestions, recognize common "design
themes", make "core" architectural decisions, etc. It is also common
for us to call in the other team architects for a half-hour
discussion or so whenever we're considering a significant
architectural change. We have no controlling authority, but the best
solutions turn into the "standards" because the solution is carried
back to each team in the architects' heads.

Another thing that has helped us is to hold frequent "brown-bag"
lunches where the entire development staff is invited and someone
will "show and tell" about some bit of code. This gives the whole
staff some idea of what else has been done on other projects that can
be reused, copied, extended or otherwise leveraged.

Another suggestion from Ken Schwaber's book, if this works for you,
is to create an "architecture" Scrum team made up of your very best
developers. They would do a sprint or two to establish the core
shared pieces and standard architecture. Everyone on that
architecture team will gain a large amount of tacit knowledge about
the standard architecture. Then split up the members of that team
into the other teams doing the regular day-to-day work. This should
promote lots of inter-team communication when issues about the
standard architecture come up.

This has been my experience. I hope the information is useful to you.

Mike

Mike Cohn

Much is going to depend on the personality of the architect you hire. Can he or she work effectively across multiple teams in a matrixed manner, with no real

Message 3 of 10
, Sep 29, 2004

0 Attachment

Much is going to depend on the personality of the architect you hire. Can he
or she work effectively across multiple teams in a matrixed manner, with no
real boss-like authoring? If so and the architect can lead toward a vision
through her personality, character and the respect she gets from everyone
else then I say put her on one team. That team might be a bit more
infrastructurally-oriented than other teams but perhaps not. Have her attend
other team's Scrums (quite feasible if there aren't too many teams) and the
Scrum of Scrums.

One thing I'm always opposed to--because I've never seen it work, in Scrum
or not--is the detached architect who never codes. I've seen too many
architects who sit on high and throw down their architectures for the lowly
programmers to code. Avoid architects who won't get their fingers dirty or
who view coding as beneath them, especially in Scrum.

I was wondering if anyone has any experience or thoughts on how an
application architect that works across different teams has been
used in a SCRUM development environment. We are in a situation
where we are thinking about creating an application architect
position in which we hope we can better align the architecture and
coding standards among different teams so that the company begins to
make headway into establishing a more standardized architectures for
different applications we host and to be able to create "recyclable"
components that can be reused by any team. Have application
architects been able to work effectively with different SCRUM teams?
Seems that one of the key elements in SCRUM is that the TEAM is
really empowered to make there own decisions to keep the project
moving along? Does that mean that the application architect would
really have to be a member of more than one SCRUM team to help keep
all of the team's architectures aligned?

I m the Application Architect for our Systems Development division, working with ~12 concurrent teams of roughly 5 - 12 members. The division is organized

Message 4 of 10
, Sep 29, 2004

0 Attachment

I'm the Application Architect for our Systems Development division,
working with ~12 concurrent teams of roughly 5 - 12 members. The
division is organized along tier lines, but the teams are
cross-functional, consisting of members from each tier (as necessary).
Each tier manager/architect is responsible for their piece of the
puzzle, while I try to look out for the overall picture.

I also serve as the primary process engineer/methodologist, trying to
make Scrum work in a large group.

--- In scrumdevelopment@yahoogroups.com, mike_schenk@y... wrote:
> Grant,
>
> I also agree with Steven. Have a "Scrum of Scrums." We have been
> doing as he suggested for over a year now (even though we haven't
> been using Scrum that long) and it has worked quite well.

We have a SoS, but it tens to focus more on cross-team impediments,
e.g. competition for scarce resources. We rarely get to talk about
larger architectural issues in the SoS.

>
> A risk in having a specified application architect is that you
might
> introduce unproductive conflict to the Scrum team(s). A Scrum team
> needs the freedom to do whatever is necessary to meet their sprint
> goal. Their overriding goal is always to provide working software
> that meets their customers' needs. If a standard architecture and
> recyclable components are not valuable to the customer, then
building
> them should not be valuable to the team. If an application
architect
> is there to enforce those standards, he can become an obstacle to
the
> team.

Yes, this has happened. My job is to try to balance the short-term
goals of the sprint with the long-term stability and extensibility of
the system. This is not an easy task, and certainly one that is not
accomplished by dictate. Generally speaking, I have to be a consensus
builder. If I can convince the team that a more general solution can
be built within the sprint, great. However, if it going to be a bigger
effort, we may simply add a non-functional feature to the product
backlog. At some point, the need for the feature may become great
enough to make it to the top of the list, at which point it would be
assigned to a team.

>
> I've been in that architect's position where a team has found a
> workable solution to a customer problem but I can see a more
abstract
> solution that would allow it to work for other projects. The team
has
> already completed their solution and it meets their customer's
need,
> so who is going to take the time to expand that solution? The team
> has no incentive to do so, and I don't have the time.

The key is to work with the team before they complete the feature. If
the more abstract solution can be substituted with minimal impact on
the team, and just as importantly, with buy-in from the team, then the
abstract solution is chosen. If not, it goes on the backlog for
possible future consideration.

>
> It can also become quickly overwhelming for one application
architect
> to keep different projects aligned.

Agreed!!! :-)

> Even with two or three small
> teams (<5) there is so much design and code produced so quickly,
> (because the teams are empowered to solve their own problems), the
> architect can have a difficult time keeping up. If the teams wait
for
> the architect's approval he again becomes an obstacle.

Thus, one must choose wisely. When our project started, there was a
single team of 6 staff members. There are now over 75. In the
beginning, I was involved in nearly ever decision. Now I have to trust
that the teams will seek assistance when they're faced with a tough
choice. As you mentioned above, I try identify more abstract designs
that may have greater potential for reuse/stability down the road.

I've tried very hard to avoid the concept of "approval". I view myself
more as a mentor. As a "chicken", I can make suggestions, but not
directly determine the course of action. Of course, there are
definitely times when I, and other architects, had to dig in our heals
if we felt that the team(s) was heading down a dead-end path.

In general, it's a tough balancing act. With a small system and a
single team, everyone can get there hands around the entire problem
space. In a larger system, members of each team may be unaware of
similar/duplicative work being performed by other teams.

>
> For us the best way of producing recyclable components and
consistent
> architecture is to have lots of open communication across the
various
> teams.

Of course. But with large organizations, this can be difficult. There
are days when I don't think the teams are doing a good job
communicating within the team itself, nevermind between teams :-(
The role of the architects/tier managers/senior engineers is to aid in
spreading the word.

>
> We have the "designated architects" meet at least once a week to
> describe in general what the teams are working on. This gives us a
> chance to coordinate dependencies, recognize problems another team
> has already solved, offer suggestions, recognize common "design
> themes", make "core" architectural decisions, etc. It is also
common
> for us to call in the other team architects for a half-hour
> discussion or so whenever we're considering a significant
> architectural change. We have no controlling authority, but the
best
> solutions turn into the "standards" because the solution is carried
> back to each team in the architects' heads.

We have basically the same thing.

>
> Another thing that has helped us is to hold frequent "brown-bag"
> lunches where the entire development staff is invited and someone
> will "show and tell" about some bit of code. This gives the whole
> staff some idea of what else has been done on other projects that
can
> be reused, copied, extended or otherwise leveraged.

Sounds great. We've had a few of these ourselves, although not as many
as I'd like.

>
> Another suggestion from Ken Schwaber's book, if this works for you,
> is to create an "architecture" Scrum team made up of your very best
> developers. They would do a sprint or two to establish the core
> shared pieces and standard architecture.

Yes, this was performed when the project was started. We built a
proof-of-concept, defined a technical architecture, and laid the
groundwork for future development.

> Everyone on that
> architecture team will gain a large amount of tacit knowledge about
> the standard architecture. Then split up the members of that team
> into the other teams doing the regular day-to-day work. This should
> promote lots of inter-team communication when issues about the
> standard architecture come up.
>
> This has been my experience. I hope the information is useful to
you.

It sounds like we've shared many of the same experiences.

Mark

>
> Mike

woynam

... hire. Can he ... with no ... vision ... everyone ... her attend ... and the ... Agreed. ... Scrum ... many ... the lowly ... dirty or ... Hey, I resemble

> else then I say put her on one team. That team might be a bit more
> infrastructurally-oriented than other teams but perhaps not. Have

her attend

> other team's Scrums (quite feasible if there aren't too many teams)

and the

> Scrum of Scrums.

Agreed.

>
> One thing I'm always opposed to--because I've never seen it work, in

Scrum

> or not--is the detached architect who never codes. I've seen too

many

> architects who sit on high and throw down their architectures for

the lowly

> programmers to code. Avoid architects who won't get their fingers

dirty or

> who view coding as beneath them, especially in Scrum.

Hey, I resemble that remark! :-)

It's not that I don't want to code. Heck, some days I'd love to put
all the other problem on the back burner and get my hands on a juicy
coding problem. But with a large system, there's plenty of things I
can be doing besides coding, including:

- Working with business analysts and customer liaisons to determine
the feasibility/scope of new features.
- Work on integrating legacy systems into our new platform, often by
leading high-level design sessions that focus on our service-based
architecture
- Working with the infrastructure team to identify improvements in
our core application platform, including the evaluation of third-party
products
- Promoting and teaching Scrum across the organization, including
groups that haven't been exposed to Scrum
- Working to improve our development environments and engineering
practices, e.g. promotion of test-driven development
- Joining teams for design sessions/reviews
- Joining teams for code reviews

In my personal time, I teach a course at a local university, which
allows me to spend some time slinging code, and working with other
technologies.

>
> I was wondering if anyone has any experience or thoughts on how an
> application architect that works across different teams has been
> used in a SCRUM development environment. We are in a situation
> where we are thinking about creating an application architect
> position in which we hope we can better align the architecture and
> coding standards among different teams so that the company begins

to

> make headway into establishing a more standardized architectures

for

> different applications we host and to be able to create

"recyclable"

> components that can be reused by any team. Have application
> architects been able to work effectively with different SCRUM

teams?

> Seems that one of the key elements in SCRUM is that the TEAM is
> really empowered to make there own decisions to keep the project
> moving along? Does that mean that the application architect would
> really have to be a member of more than one SCRUM team to help keep
> all of the team's architectures aligned?
>
>
>
>
> To Post a message, send it to: scrumdevelopment@e...
> To Unsubscribe, send a blank message to:
> scrumdevelopment-unsubscribe@e...
> Yahoo! Groups Links

Mike Cohn

My point was to avoid architects who view coding as beneath them. They may not have time to do it or do it much. That sounds more like your situation. --Mike

Message 6 of 10
, Sep 29, 2004

0 Attachment

My point was to avoid architects who view coding as beneath them. They may
not have time to do it or do it much. That sounds more like your situation.

> else then I say put her on one team. That team might be a bit more
> infrastructurally-oriented than other teams but perhaps not. Have

her attend

> other team's Scrums (quite feasible if there aren't too many teams)

and the

> Scrum of Scrums.

Agreed.

>
> One thing I'm always opposed to--because I've never seen it work, in

Scrum

> or not--is the detached architect who never codes. I've seen too

many

> architects who sit on high and throw down their architectures for

the lowly

> programmers to code. Avoid architects who won't get their fingers

dirty or

> who view coding as beneath them, especially in Scrum.

Hey, I resemble that remark! :-)

It's not that I don't want to code. Heck, some days I'd love to put
all the other problem on the back burner and get my hands on a juicy
coding problem. But with a large system, there's plenty of things I
can be doing besides coding, including:

- Working with business analysts and customer liaisons to determine
the feasibility/scope of new features.
- Work on integrating legacy systems into our new platform, often by
leading high-level design sessions that focus on our service-based
architecture
- Working with the infrastructure team to identify improvements in
our core application platform, including the evaluation of third-party
products
- Promoting and teaching Scrum across the organization, including
groups that haven't been exposed to Scrum
- Working to improve our development environments and engineering
practices, e.g. promotion of test-driven development
- Joining teams for design sessions/reviews
- Joining teams for code reviews

In my personal time, I teach a course at a local university, which
allows me to spend some time slinging code, and working with other
technologies.

>
> I was wondering if anyone has any experience or thoughts on how an
> application architect that works across different teams has been
> used in a SCRUM development environment. We are in a situation
> where we are thinking about creating an application architect
> position in which we hope we can better align the architecture and
> coding standards among different teams so that the company begins

to

> make headway into establishing a more standardized architectures

for

> different applications we host and to be able to create

"recyclable"

> components that can be reused by any team. Have application
> architects been able to work effectively with different SCRUM

teams?

> Seems that one of the key elements in SCRUM is that the TEAM is
> really empowered to make there own decisions to keep the project
> moving along? Does that mean that the application architect would
> really have to be a member of more than one SCRUM team to help keep
> all of the team's architectures aligned?
>
>
>
>
> To Post a message, send it to: scrumdevelopment@e...
> To Unsubscribe, send a blank message to:
> scrumdevelopment-unsubscribe@e...
> Yahoo! Groups Links

Mark, From here it looks like you are taking on way too much responsibility for the long term good of your organization. If you were to share these

Message 7 of 10
, Sep 30, 2004

0 Attachment

Mark,

From here it looks like you are taking on way too much responsibility for the long
term good of your organization.

If you were to share these responsiblities with a part-time team of developers who
also spent a large part of their time working in their own Scrum teams, then:
1. The big picture knowledge would be directly experienced by more people, and
thereby more effectively shared with the developement teams.
2. These other people might contribute ideas that had not occurred to you.
3. The skill level of your developers would have a greater opportunity to grow.
4. The organization could survive your loss a lot more easily.
5. You would have time to stay more closely in touch with the code base and the
developers by spending maybe a day a week coding in one of the Scrum teams.

Aren't these among the reasons Scrum works better than just having a small group
of gurus hand down a finished design for the coders to blindly implement?

It's not that I don't want to code. Heck, some days I'd love to put
all the other problem on the back burner and get my hands on a juicy
coding problem. But with a large system, there's plenty of things I
can be doing besides coding, including:

- Working with business analysts and customer liaisons to determine
the feasibility/scope of new features.
- Work on integrating legacy systems into our new platform, often by
leading high-level design sessions that focus on our service-based
architecture
- Working with the infrastructure team to identify improvements in
our core application platform, including the evaluation of third-party
products
- Promoting and teaching Scrum across the organization, including
groups that haven't been exposed to Scrum
- Working to improve our development environments and engineering
practices, e.g. promotion of test-driven development
- Joining teams for design sessions/reviews
- Joining teams for code reviews

In my personal time, I teach a course at a local university, which
allows me to spend some time slinging code, and working with other
technologies.

Mark

woynam

I hope I didn t give you the impression that I m the only one working in these areas. I get a lot of help from the whole team. In many ways I simply act as a

Message 8 of 10
, Sep 30, 2004

0 Attachment

I hope I didn't give you the impression that I'm the only one working
in these areas. I get a lot of help from the whole team. In many ways
I simply act as a coordinator. I don't have a direct staff, and I
don't really want one. I believe that these ultimately leads to where
Mike was pointing: the Office of the Architect and his Minions.

Rather, I can only accomplish things by a) convincing others that the
work is worthwhile and necessary, b) getting the item/issue/feature on
the product backlog, and c) working with the teams once with item has
been assigned to a sprint.

> term good of your organization.
>
> If you were to share these responsiblities with a part-time team of

developers who

> also spent a large part of their time working in their own Scrum

teams, then:

> 1. The big picture knowledge would be directly experienced by more

people, and

> thereby more effectively shared with the developement teams.
> 2. These other people might contribute ideas that had not occurred

to you.

> 3. The skill level of your developers would have a greater

opportunity to grow.

> 4. The organization could survive your loss a lot more easily.

Oh, I'm sure there's no way they could live without me. ;-)

> 5. You would have time to stay more closely in touch with the code

base and the

> developers by spending maybe a day a week coding in one of the Scrum

teams.

>
> Aren't these among the reasons Scrum works better than just having a

small group

> of gurus hand down a finished design for the coders to blindly

implement?

No, we don't hand down the finished design. The teams are responsible
for the ultimate design. The tier managers (architects), senior
engineers, and myself typically spend time upfront with the customers
and business analysts discussing the feasibility of certain features.
At this level, we're primarily focused on the high-level architecture
of the system. Also, since we're migrating to a new platform, we try
to identify what aspects of the overall features will be performed on
each of the platforms.

From these meetings come the initial feature estimates, which feed
into the product backlog. At this point we have a basic idea of how
the feature is going to work, and the affected systems/components.

This information is conveyed to the team(s) during the sprint kickoff.
The team is responsible for turning the idea into a finished product.
They can certainly point out the folly of our initial high-level
designs, and recommend alternatives. However, the core of the detailed
design still remains within the team.

>
>
> It's not that I don't want to code. Heck, some days I'd love to put
> all the other problem on the back burner and get my hands on a

juicy

> coding problem. But with a large system, there's plenty of things I
> can be doing besides coding, including:
>
> - Working with business analysts and customer liaisons to

determine

> the feasibility/scope of new features.
> - Work on integrating legacy systems into our new platform,

often by

> leading high-level design sessions that focus on our service-based
> architecture
> - Working with the infrastructure team to identify improvements

in

> our core application platform, including the evaluation of

third-party

> products
> - Promoting and teaching Scrum across the organization, including
> groups that haven't been exposed to Scrum
> - Working to improve our development environments and engineering
> practices, e.g. promotion of test-driven development
> - Joining teams for design sessions/reviews
> - Joining teams for code reviews
>
> In my personal time, I teach a course at a local university, which
> allows me to spend some time slinging code, and working with other
> technologies.
>
> Mark

Your message has been successfully submitted and would be delivered to recipients shortly.