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

Re: Role of Application Architect on Scrum Teams

Expand Messages
  • 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 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.

          --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 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
            Message 5 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 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.

                --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 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?

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

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