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

Re: Role of Application Architect on Scrum Teams

Expand Messages
  • 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 1 of 10 , Sep 30, 2004
      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...>
      > 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
      > 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

      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
      > 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
      > 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
      > 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
      > our core application platform, including the evaluation of
      > 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.