Re: Role of Application Architect on Scrum Teams
- 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.
--- In firstname.lastname@example.org, Steven Gordon <sagordon@a...>
> Mark,responsibility for the long
> From here it looks like you are taking on way too much
> term good of your organization.developers who
> If you were to share these responsiblities with a part-time team of
> also spent a large part of their time working in their own Scrumteams, then:
> 1. The big picture knowledge would be directly experienced by morepeople, and
> thereby more effectively shared with the developement teams.to you.
> 2. These other people might contribute ideas that had not occurred
> 3. The skill level of your developers would have a greateropportunity 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 codebase and the
> developers by spending maybe a day a week coding in one of the Scrumteams.
> Aren't these among the reasons Scrum works better than just having a
> of gurus hand down a finished design for the coders to blindlyimplement?
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.
> Steven Gordon
> -----Original Message-----
> From: woynam [mailto:woyna@c...]
> Sent: Wednesday, September 29, 2004 9:09 AM
> To: email@example.com
> Subject: [scrumdevelopment] Re: Role of Application Architect on
> 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
> coding problem. But with a large system, there's plenty of things Idetermine
> can be doing besides coding, including:
> - Working with business analysts and customer liaisons to
> the feasibility/scope of new features.often by
> - Work on integrating legacy systems into our new platform,
> leading high-level design sessions that focus on our service-basedin
> - Working with the infrastructure team to identify improvements
> our core application platform, including the evaluation ofthird-party
> - 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