Loading ...
Sorry, an error occurred while loading the content.

RE: [scrumdevelopment] Role of Application Architect on Scrum Teams

Expand Messages
  • Steven Gordon
    I believe a good approach would be to have one member (possibly two) of each SCRUM team be a designated to be a member of the Application Architecture team.
    Message 1 of 10 , Sep 28, 2004
    • 0 Attachment
      I believe a good approach would be to have one member (possibly two) of each SCRUM team
      be a designated to be a member of the Application Architecture team.  This team might meet
      once a week to discuss the architectural goals and nominate various components of their
      SCRUM team's architecture as being worthy of being promoted to being part of the overall
      application architecture.  Otherwise, these architects actively participate in their own SCRUM's
      activities where they actively spread the standards and goal of the application architecture to
      the other members of their team.  Rotating membership in the Application Architecture team
      might work if you have enough senior staff.
       
      Creating a dedicated application architect position is likely to cause a schism and be less
      effective than leveraging your current resources and team structure as suggested above.
       
      Steven Gordon
      -----Original Message-----
      From: Grant [mailto:grantj@...]
      Sent: Tuesday, September 28, 2004 3:20 PM
      To: scrumdevelopment@yahoogroups.com
      Subject: [scrumdevelopment] Role of Application Architect on Scrum Teams

      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?

    • JASchiel
      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 2 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 3 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 4 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.

            --Mike Cohn
            Author of User Stories Applied for Agile Software Development
            www.mountaingoatsoftware.com
            www.userstories.com

            -----Original Message-----
            From: Grant [mailto:grantj@...]
            Sent: Tuesday, September 28, 2004 4:20 PM
            To: scrumdevelopment@yahoogroups.com
            Subject: [scrumdevelopment] Role of Application Architect on Scrum Teams

            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@...
            To Unsubscribe, send a blank message to:
            scrumdevelopment-unsubscribe@...
            Yahoo! Groups Links
          • woynam
            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 5 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
              Message 6 of 10 , Sep 29, 2004
              • 0 Attachment
                --- In scrumdevelopment@yahoogroups.com, "Mike Cohn" <mike@m...>
                wrote:
                > 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.

                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.

                Mark

                >
                > --Mike Cohn
                > Author of User Stories Applied for Agile Software Development
                > www.mountaingoatsoftware.com
                > www.userstories.com
                >
                > -----Original Message-----
                > From: Grant [mailto:grantj@r...]
                > Sent: Tuesday, September 28, 2004 4:20 PM
                > To: scrumdevelopment@yahoogroups.com
                > Subject: [scrumdevelopment] Role of Application Architect on Scrum
                Teams
                >
                > 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 7 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.

                  --Mike Cohn
                  Author of User Stories Applied for Agile Software Development
                  www.mountaingoatsoftware.com
                  www.userstories.com

                  -----Original Message-----
                  From: woynam [mailto:woyna@...]
                  Sent: Wednesday, September 29, 2004 9:09 AM
                  To: scrumdevelopment@yahoogroups.com
                  Subject: [scrumdevelopment] Re: Role of Application Architect on Scrum Teams

                  --- In scrumdevelopment@yahoogroups.com, "Mike Cohn" <mike@m...>
                  wrote:
                  > 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.

                  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.

                  Mark

                  >
                  > --Mike Cohn
                  > Author of User Stories Applied for Agile Software Development
                  > www.mountaingoatsoftware.com
                  > www.userstories.com
                  >
                  > -----Original Message-----
                  > From: Grant [mailto:grantj@r...]
                  > Sent: Tuesday, September 28, 2004 4:20 PM
                  > To: scrumdevelopment@yahoogroups.com
                  > Subject: [scrumdevelopment] Role of Application Architect on Scrum
                  Teams
                  >
                  > 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




                  To Post a message, send it to: scrumdevelopment@...
                  To Unsubscribe, send a blank message to:
                  scrumdevelopment-unsubscribe@...
                  Yahoo! Groups Links
                • Steven Gordon
                  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 8 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?

                    Steven Gordon
                    http://sf.asu.edu/




                    -----Original Message-----
                    From: woynam [mailto:woyna@...]
                    Sent: Wednesday, September 29, 2004 9:09 AM
                    To: scrumdevelopment@yahoogroups.com
                    Subject: [scrumdevelopment] Re: Role of Application Architect on Scrum Teams


                    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 9 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.

                      --- In scrumdevelopment@yahoogroups.com, Steven Gordon <sagordon@a...>
                      wrote:
                      > 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.

                      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.

                      Mark

                      >
                      > Steven Gordon
                      > http://sf.asu.edu/
                      >
                      >
                      >
                      >
                      > -----Original Message-----
                      > From: woynam [mailto:woyna@c...]
                      > Sent: Wednesday, September 29, 2004 9:09 AM
                      > To: scrumdevelopment@yahoogroups.com
                      > Subject: [scrumdevelopment] Re: Role of Application Architect on
                      Scrum Teams
                      >
                      >
                      > 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.