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

managing borderline roles in the scrum team

Expand Messages
  • Alberto Brandolini
    Hi all A recurring hotspot for me and some colleagues involved in agile processes is how to manage roles that do not fit in the development team . Scrum is
    Message 1 of 9 , Sep 30, 2009
      Hi all

      A recurring hotspot for me and some colleagues involved in agile processes is "how to manage roles that do not fit in the development team".
      Scrum is explicit in talking about the cross-functional team, it might not be an easy path, but it provides clear benefit.

      Unfortunately not all key roles reside within the organization. A typical example I've bumped into is the "design expert" or the "user interaction expert". They're quite often independent professionals, external contractors, with their own schedule constraints (and their personal ability to respect them). As a general trend, looks external contributions by many fields is increasing, but this often puts the whole process in jeopardy (deadlines, outbound dependencies and so on).

      Has anybody explored this area in depth?

      Thanks in advance,

      Alberto

      --
      Alberto Brandolini
      Phone: +39-347-6005027
      E-mail: alberto.brandolini@...
      Web page; http://albertobrandolini.wikidot.com
      Blog: http://ziobrando.blogspot.com
      Linkedin page: http://www.linkedin.com/in/brando
    • Peter Stevens (cal)
      Hi Alberto, Have had this situation on a number of occasions. The problem is you can t expect externals (to the team) to commit the way a team member does. I
      Message 2 of 9 , Sep 30, 2009
        Hi Alberto,

        Have had this situation on a number of occasions. The problem is you can't expect externals (to the team) to commit the way a team member does.

        I have seen the best results when the team keeps the responsibility for 'done', but draws on the experience, know-how, support, whatever of the external consultant to achieve done.

        This works really well if you have a junior in the team who needs help from a senior outside the team. It has the effect of pairing them and helping the jr raise his competency level quickly.

        In other cases, the team has needed, say business know-how, which is only available from an external, but doesn't need/intend to build up that know within the team. Here again, we have a responsible person inside the team (once even the Scrum Master, which is sub-optimal, but was necessary due to the skills of the people involved), and we use the sprint planning/review cycle to plan (budget) and review this work as well. It worked well. Not sure if that's the only way or even the best way to do it, but it worked well enough. We used this kind of support more for long term issues, like creating a business vision for the next release, not really for development related activities.

        Cheers,
        Peter

        Alberto Brandolini wrote:
         

        Hi all

        A recurring hotspot for me and some colleagues involved in agile processes is "how to manage roles that do not fit in the development team".
        Scrum is explicit in talking about the cross-functional team, it might not be an easy path, but it provides clear benefit.

        Unfortunately not all key roles reside within the organization. A typical example I've bumped into is the "design expert" or the "user interaction expert". They're quite often independent professionals, external contractors, with their own schedule constraints (and their personal ability to respect them). As a general trend, looks external contributions by many fields is increasing, but this often puts the whole process in jeopardy (deadlines, outbound dependencies and so on).

        Has anybody explored this area in depth?

        Thanks in advance,

        Alberto

        --
        Alberto Brandolini
        Phone: +39-347-6005027
        E-mail: alberto.brandolini@ gmail.com
        Web page; http://albertobrand olini.wikidot. com
        Blog: http://ziobrando. blogspot. com
        Linkedin page: http://www.linkedin .com/in/brando


      • Alberto Brandolini
        Hi Peter, Thanks for the answer, It helped me focus a little better. If I have the chance to have the professional within the team, we are probably in the
        Message 3 of 9 , Sep 30, 2009
          Hi Peter,

          Thanks for the answer, It helped me focus a little better.

          If I have the chance to have the professional within the team, we are probably in the "sweet area" of the problem.
          Pairing is a very effective way to reduce dependencies. It allows junior grow rapidly to a sufficient level, leaving the expert jobs for the specialist. The expert should also be happy to work only on the interesting stuff, not the boring part. So far so good.

          This anyway changes the specialist role a bit. Pairing and mentoring might not be part of a typical deal. Moreover this will make him/her lose a bit of the commercial grip. I think this is definitely a good goal to aim for, but the specialist might not think the same.
          (I personally prefer A LOT to work with the type of professionals that like to share part of their skills and focus on the next step, but not all specialists are the same).

          Often anyway, "creative" specialists might not be located with your team: they might have different tools in their office (a large screen workstation, or ...whatever) and might find it difficult to be creative/productive if asked/forced to work with the development team, or simply prefer to work from their office. They also are very likely to have a different methodology from yours (and often simply none). This looks like a lot less manageable scenario.
          A real world situation was "the team is missing the deadline because the web designer didn't finish his part", and the external expert isn't "that" committed because this was just an intermediate release, and/or because he's overbooked, with some other project in "red zone".
          We might argue that this is somewhat non-professional, but this happens. And might impact the speed of a jelled team a lot.

          Keeping the done responsibility on the team helps, we don't want to be responsible for a "half product" :-) like inspecting, adapting and re-planning. But some B-plans (like finding another specialist) might not be available or out of scope.

          To me, looks like the bottom like is something like: "If there are common values, you're likely to succeed also with outbound roles, if there is no common ground, ...expect problems along the way". There's probably some more zen-ish sentence to express that, somewhere. Also, the more I think about it, the more it looks like the answer is something like "let the problem emerge (daily scrum and/or retrospective) and let the team decide how to solve it", but even in this case suggestions are welcome. :-)

          Thanks again

          Alberto



          2009/9/30 Peter Stevens (cal) <peterstev@...>
           

          Hi Alberto,

          Have had this situation on a number of occasions. The problem is you can't expect externals (to the team) to commit the way a team member does.

          I have seen the best results when the team keeps the responsibility for 'done', but draws on the experience, know-how, support, whatever of the external consultant to achieve done.

          This works really well if you have a junior in the team who needs help from a senior outside the team. It has the effect of pairing them and helping the jr raise his competency level quickly.

          In other cases, the team has needed, say business know-how, which is only available from an external, but doesn't need/intend to build up that know within the team. Here again, we have a responsible person inside the team (once even the Scrum Master, which is sub-optimal, but was necessary due to the skills of the people involved), and we use the sprint planning/review cycle to plan (budget) and review this work as well. It worked well. Not sure if that's the only way or even the best way to do it, but it worked well enough. We used this kind of support more for long term issues, like creating a business vision for the next release, not really for development related activities.

          Cheers,
          Peter



          Alberto Brandolini wrote:
           

          Hi all

          A recurring hotspot for me and some colleagues involved in agile processes is "how to manage roles that do not fit in the development team".
          Scrum is explicit in talking about the cross-functional team, it might not be an easy path, but it provides clear benefit.

          Unfortunately not all key roles reside within the organization. A typical example I've bumped into is the "design expert" or the "user interaction expert". They're quite often independent professionals, external contractors, with their own schedule constraints (and their personal ability to respect them). As a general trend, looks external contributions by many fields is increasing, but this often puts the whole process in jeopardy (deadlines, outbound dependencies and so on).

          Has anybody explored this area in depth?

          Thanks in advance,

          Alberto

          --
          Alberto Brandolini
          Phone: +39-347-6005027
          E-mail: alberto.brandolini@...
          Web page; http://albertobrandolini.wikidot.com
          Blog: http://ziobrando.blogspot.com
          Linkedin page: http://www.linkedin.com/in/brando





          --
          Alberto Brandolini
          Phone: +39-347-6005027
          E-mail: alberto.brandolini@...
          Web page; http://albertobrandolini.wikidot.com
          Blog: http://ziobrando.blogspot.com
          Linkedin page: http://www.linkedin.com/in/brando
        • Peter Stevens (cal)
          Hi Alberto, I agree, some gurus like to be pulled in 5 different directions at once, it makes them feel important. But let us assume every team used this
          Message 4 of 9 , Sep 30, 2009
            Hi Alberto,

            I agree, some gurus like to be pulled in 5 different directions at once, it makes them feel important. But let us assume every team used this approach. Sooner or later, all the relevant juniors would get to the point that they don't need the guru on a day to day basis. This is a good thing, even for the guru, although it may take him a while to realize this.

            What will happen to the guru? Will he lose his job because he is redundant? Nonsense. He will be able to focus on the critical project or new technology development where his guru-skills are absolutely essential. I've seen it happen.

            As for the rest, I think it's a matter of recognizing there are some things you don't have control over and can't integrate into the team. So you strive for transparency and a good working relationship between P-O, responsible "pig" and the external consultant. And maybe you examine what alternatives you have if your initial solution isn't working the way you planned (escalation, alternative sources, etc.)

            Cheers,

            Peter

            Alberto Brandolini wrote:
             

            Hi Peter,

            Thanks for the answer, It helped me focus a little better.

            If I have the chance to have the professional within the team, we are probably in the "sweet area" of the problem.
            Pairing is a very effective way to reduce dependencies. It allows junior grow rapidly to a sufficient level, leaving the expert jobs for the specialist. The expert should also be happy to work only on the interesting stuff, not the boring part. So far so good.

            This anyway changes the specialist role a bit. Pairing and mentoring might not be part of a typical deal. Moreover this will make him/her lose a bit of the commercial grip. I think this is definitely a good goal to aim for, but the specialist might not think the same.
            (I personally prefer A LOT to work with the type of professionals that like to share part of their skills and focus on the next step, but not all specialists are the same).

            Often anyway, "creative" specialists might not be located with your team: they might have different tools in their office (a large screen workstation, or ...whatever) and might find it difficult to be creative/productive if asked/forced to work with the development team, or simply prefer to work from their office. They also are very likely to have a different methodology from yours (and often simply none). This looks like a lot less manageable scenario.
            A real world situation was "the team is missing the deadline because the web designer didn't finish his part", and the external expert isn't "that" committed because this was just an intermediate release, and/or because he's overbooked, with some other project in "red zone".
            We might argue that this is somewhat non-professional, but this happens. And might impact the speed of a jelled team a lot.

            Keeping the done responsibility on the team helps, we don't want to be responsible for a "half product" :-) like inspecting, adapting and re-planning. But some B-plans (like finding another specialist) might not be available or out of scope.

            To me, looks like the bottom like is something like: "If there are common values, you're likely to succeed also with outbound roles, if there is no common ground, ...expect problems along the way". There's probably some more zen-ish sentence to express that, somewhere. Also, the more I think about it, the more it looks like the answer is something like "let the problem emerge (daily scrum and/or retrospective) and let the team decide how to solve it", but even in this case suggestions are welcome. :-)

            Thanks again

            Alberto



            2009/9/30 Peter Stevens (cal) <peterstev@gmail. com>
             

            Hi Alberto,

            Have had this situation on a number of occasions. The problem is you can't expect externals (to the team) to commit the way a team member does.

            I have seen the best results when the team keeps the responsibility for 'done', but draws on the experience, know-how, support, whatever of the external consultant to achieve done.

            This works really well if you have a junior in the team who needs help from a senior outside the team. It has the effect of pairing them and helping the jr raise his competency level quickly.

            In other cases, the team has needed, say business know-how, which is only available from an external, but doesn't need/intend to build up that know within the team. Here again, we have a responsible person inside the team (once even the Scrum Master, which is sub-optimal, but was necessary due to the skills of the people involved), and we use the sprint planning/review cycle to plan (budget) and review this work as well. It worked well. Not sure if that's the only way or even the best way to do it, but it worked well enough. We used this kind of support more for long term issues, like creating a business vision for the next release, not really for development related activities.

            Cheers,
            Peter



            Alberto Brandolini wrote:
             

            Hi all

            A recurring hotspot for me and some colleagues involved in agile processes is "how to manage roles that do not fit in the development team".
            Scrum is explicit in talking about the cross-functional team, it might not be an easy path, but it provides clear benefit.

            Unfortunately not all key roles reside within the organization. A typical example I've bumped into is the "design expert" or the "user interaction expert". They're quite often independent professionals, external contractors, with their own schedule constraints (and their personal ability to respect them). As a general trend, looks external contributions by many fields is increasing, but this often puts the whole process in jeopardy (deadlines, outbound dependencies and so on).

            Has anybody explored this area in depth?

            Thanks in advance,

            Alberto

            --
            Alberto Brandolini
            Phone: +39-347-6005027
            E-mail: alberto.brandolini@ gmail.com
            Web page; http://albertobrand olini.wikidot. com
            Blog: http://ziobrando. blogspot. com
            Linkedin page: http://www.linkedin .com/in/brando





            --
            Alberto Brandolini
            Phone: +39-347-6005027
            E-mail: alberto.brandolini@ gmail.com
            Web page; http://albertobrand olini.wikidot. com
            Blog: http://ziobrando. blogspot. com
            Linkedin page: http://www.linkedin .com/in/brando

          • JackM
            I wrote a blog on my blog site about the various roles - it s a series. You can find part 1 at
            Message 5 of 9 , Sep 30, 2009
              I wrote a blog on my blog site about the various roles - it's a series. You can find part 1 at http://blog.agilebuddy.com/2009/07/coping-with-change-on-scrum-projects-part-i.html

              However I did not cover User Interaction roles specifically. However, to me they're no different to a developer who has work to do and that work should be represented as stories on the backlog (or tasks depending on how you are managing things).

              Jack
              blog.agilebuddy.com
              twitter.com/agilebuddy
              www.agilebuddy.com

              --- In scrumdevelopment@yahoogroups.com, Alberto Brandolini <alberto.brandolini@...> wrote:
              >
              > Hi all
              >
              > A recurring hotspot for me and some colleagues involved in agile processes
              > is "how to manage roles that do not fit in the development team".
              > Scrum is explicit in talking about the cross-functional team, it might not
              > be an easy path, but it provides clear benefit.
              >
              > Unfortunately not all key roles reside within the organization. A typical
              > example I've bumped into is the "design expert" or the "user interaction
              > expert". They're quite often independent professionals, external
              > contractors, with their own schedule constraints (and their personal ability
              > to respect them). As a general trend, looks external contributions by many
              > fields is increasing, but this often puts the whole process in jeopardy
              > (deadlines, outbound dependencies and so on).
              >
              > Has anybody explored this area in depth?
              >
              > Thanks in advance,
              >
              > Alberto
              >
              > --
              > Alberto Brandolini
              > Phone: +39-347-6005027
              > E-mail: alberto.brandolini@...
              > Web page; http://albertobrandolini.wikidot.com
              > Blog: http://ziobrando.blogspot.com
              > Linkedin page: http://www.linkedin.com/in/brando
              >
            • Alberto Brandolini
              Hi Jack, and thanks for the link :-) Just to clarify, User Interaction specialist is just an example. I agree with you that they re not that different from
              Message 6 of 9 , Sep 30, 2009
                Hi Jack,

                and thanks for the link :-)

                Just to clarify, User Interaction specialist is just an example. I agree with you that they're not that different from developers in the way they should manage their work. Anyway my question was not specific to the role (Graphic Designer, Security Expert, or the Domain Expert himself might fit into the problem).
                As consultant, I might find myself on both sides of the fence: I might be in the position to help teams to deal with their process and their specialists, while in some other situation I might end up being the scarcely available specialist.

                Also, I do agree not to treat borderline roles as exceptions. But in many situations I can't expect these roles
                - to be part of my wonderfully jelled team
                - to show up every morning for the Daily Scrum.
                ...they're definitely not pigs.

                So the question boils down to "how do you manage external specialists?"

                Peter's suggestion (if I got it right) is to use a team member as a proxy for the external expert. This way the status would still be visible to other team members and the proxy would have the responsibility to say "The Expert didn't deliver anything yesterday" or "he delivered story XXX" which is a lot better than "Does anybody know what The Expert is doing?". The team member would have the duty to ping the expert to provide the necessary information to the daily scrum.

                This would make the "inspect" part feasible. I guess the "adapt" part would be more context specific, the team should be able to find its own way out if the situation becomes problematic. Given that alternative solutions might require extra time to be implemented, transparency and early warnings are essential.

                I am "thinking loud", ...please correct me if I am wrong. :-)

                thanks again

                Alberto

                2009/9/30 JackM <jack@...>
                 

                I wrote a blog on my blog site about the various roles - it's a series. You can find part 1 at http://blog.agilebuddy.com/2009/07/coping-with-change-on-scrum-projects-part-i.html

                However I did not cover User Interaction roles specifically. However, to me they're no different to a developer who has work to do and that work should be represented as stories on the backlog (or tasks depending on how you are managing things).

                Jack
                blog.agilebuddy.com
                twitter.com/agilebuddy
                www.agilebuddy.com



                --- In scrumdevelopment@yahoogroups.com, Alberto Brandolini <alberto.brandolini@...> wrote:
                >
                > Hi all
                >
                > A recurring hotspot for me and some colleagues involved in agile processes
                > is "how to manage roles that do not fit in the development team".
                > Scrum is explicit in talking about the cross-functional team, it might not
                > be an easy path, but it provides clear benefit.
                >
                > Unfortunately not all key roles reside within the organization. A typical
                > example I've bumped into is the "design expert" or the "user interaction
                > expert". They're quite often independent professionals, external
                > contractors, with their own schedule constraints (and their personal ability
                > to respect them). As a general trend, looks external contributions by many
                > fields is increasing, but this often puts the whole process in jeopardy
                > (deadlines, outbound dependencies and so on).
                >
                > Has anybody explored this area in depth?
                >
                > Thanks in advance,
                >
                > Alberto
                >
                > --
                > Alberto Brandolini
                > Phone: +39-347-6005027
                > E-mail: alberto.brandolini@...



                --
                Alberto Brandolini
                Phone: +39-347-6005027
                E-mail: alberto.brandolini@...
                Web page; http://albertobrandolini.wikidot.com
                Blog: http://ziobrando.blogspot.com
                Linkedin page: http://www.linkedin.com/in/brando
              • sschuermann303
                Hi ... I can only give you a guess, but i think you have cost of 150% or 100% plus compared to other tasks. We have nailed down this on each task with external
                Message 7 of 9 , Sep 30, 2009
                  Hi

                  > Has anybody explored this area in depth?

                  I can only give you a guess, but i think you have cost of 150% or 100% plus compared to other tasks.
                  We have nailed down this on each task with external dependencies (Marked with red marker). We even have it in the DOD.


                  S.

                  p.s. more a muscle thing (in terms of going to someone and check back) than a brain thing (in terms of beeing more complex)




                  --- In scrumdevelopment@yahoogroups.com, Alberto Brandolini <alberto.brandolini@...> wrote:
                  >
                  > Hi all
                  >
                  > A recurring hotspot for me and some colleagues involved in agile processes
                  > is "how to manage roles that do not fit in the development team".
                  > Scrum is explicit in talking about the cross-functional team, it might not
                  > be an easy path, but it provides clear benefit.
                  >
                  > Unfortunately not all key roles reside within the organization. A typical
                  > example I've bumped into is the "design expert" or the "user interaction
                  > expert". They're quite often independent professionals, external
                  > contractors, with their own schedule constraints (and their personal ability
                  > to respect them). As a general trend, looks external contributions by many
                  > fields is increasing, but this often puts the whole process in jeopardy
                  > (deadlines, outbound dependencies and so on).
                  >
                  > Has anybody explored this area in depth?
                  >
                  > Thanks in advance,
                  >
                  > Alberto
                  >
                  > --
                  > Alberto Brandolini
                  > Phone: +39-347-6005027
                  > E-mail: alberto.brandolini@...
                  > Web page; http://albertobrandolini.wikidot.com
                  > Blog: http://ziobrando.blogspot.com
                  > Linkedin page: http://www.linkedin.com/in/brando
                  >
                • Alberto Brandolini
                  2009/9/30 sschuermann303 ... Hi, my figures are even a little worse. I ve seen specialist management happening when restructuring a
                  Message 8 of 9 , Sep 30, 2009
                    2009/9/30 sschuermann303 <sschuermann303@...>
                     

                    Hi


                    > Has anybody explored this area in depth?

                    I can only give you a guess, but i think you have cost of 150% or 100% plus compared to other tasks.









                    Hi, my figures are even a little worse. I've seen "specialist management" happening when restructuring a house, and the effect on the schedule is devastating (especially the combined effect of different specialists). So, if I have a chance, I would choose not to depend on the specialist, or to use him basically to improve the team skills.
                     
                    We have nailed down this on each task with external dependencies (Marked with red marker). We even have it in the DOD.



                    I like this one.
                     
                    Thanks

                    Alberto

                    S.

                    p.s. more a muscle thing (in terms of going to someone and check back) than a brain thing (in terms of beeing more complex)






                    it is ...not really the fun area, unless you like muscles. :-)

                    --- In scrumdevelopment@yahoogroups.com, Alberto Brandolini <alberto.brandolini@...> wrote:
                    >
                    > Hi all
                    >
                    > A recurring hotspot for me and some colleagues involved in agile processes
                    > is "how to manage roles that do not fit in the development team".
                    > Scrum is explicit in talking about the cross-functional team, it might not
                    > be an easy path, but it provides clear benefit.
                    >
                    > Unfortunately not all key roles reside within the organization. A typical
                    > example I've bumped into is the "design expert" or the "user interaction
                    > expert". They're quite often independent professionals, external
                    > contractors, with their own schedule constraints (and their personal ability
                    > to respect them). As a general trend, looks external contributions by many
                    > fields is increasing, but this often puts the whole process in jeopardy
                    > (deadlines, outbound dependencies and so on).
                    >
                    > Has anybody explored this area in depth?
                    >
                    > Thanks in advance,
                    >
                    > Alberto
                    >
                    > --
                    > Alberto Brandolini
                    > Phone: +39-347-6005027
                    > E-mail: alberto.brandolini@...



                    --
                    Alberto Brandolini
                    Phone: +39-347-6005027
                    E-mail: alberto.brandolini@...
                    Web page; http://albertobrandolini.wikidot.com
                    Blog: http://ziobrando.blogspot.com
                    Linkedin page: http://www.linkedin.com/in/brando
                  • JackM
                    So all very good questions. And yes there are always edge conditions and so all you can do is do your best. So for example, if they can t physically be in the
                    Message 9 of 9 , Sep 30, 2009
                      So all very good questions. And yes there are always edge conditions and so all you can do is do your best.

                      So for example, if they can't physically be in the daily standup, perhaps you can skype them in.

                      Perhaps you can use the proxy approach.

                      It's never simple and straight forward is it :-)

                      Jack
                      blog.agilebuddy.com
                      twitter.com/agilebuddy
                      www.agilebuddy.com

                      --- In scrumdevelopment@yahoogroups.com, Alberto Brandolini <alberto.brandolini@...> wrote:
                      >
                      > Hi Jack,
                      >
                      > and thanks for the link :-)
                      >
                      > Just to clarify, User Interaction specialist is just an example. I agree
                      > with you that they're not that different from developers in the way they
                      > should manage their work. Anyway my question was not specific to the role
                      > (Graphic Designer, Security Expert, or the Domain Expert himself might fit
                      > into the problem).
                      > As consultant, I might find myself on both sides of the fence: I might be in
                      > the position to help teams to deal with their process and their specialists,
                      > while in some other situation I might end up being the scarcely available
                      > specialist.
                      >
                      > Also, I do agree not to treat borderline roles as exceptions. But in many
                      > situations I can't expect these roles
                      > - to be part of my wonderfully jelled team
                      > - to show up every morning for the Daily Scrum.
                      > ...they're definitely not pigs.
                      >
                      > So the question boils down to "how do you manage external specialists?"
                      >
                      > Peter's suggestion (if I got it right) is to use a team member as a proxy
                      > for the external expert. This way the status would still be visible to other
                      > team members and the proxy would have the responsibility to say "The Expert
                      > didn't deliver anything yesterday" or "he delivered story XXX" which is a
                      > lot better than "Does anybody know what The Expert is doing?". The team
                      > member would have the duty to ping the expert to provide the necessary
                      > information to the daily scrum.
                      >
                      > This would make the "inspect" part feasible. I guess the "adapt" part would
                      > be more context specific, the team should be able to find its own way out if
                      > the situation becomes problematic. Given that alternative solutions might
                      > require extra time to be implemented, transparency and early warnings are
                      > essential.
                      >
                      > I am "thinking loud", ...please correct me if I am wrong. :-)
                      >
                      > thanks again
                      >
                      > Alberto
                      >
                      > 2009/9/30 JackM <jack@...>
                      >
                      > >
                      > >
                      > > I wrote a blog on my blog site about the various roles - it's a series. You
                      > > can find part 1 at
                      > > http://blog.agilebuddy.com/2009/07/coping-with-change-on-scrum-projects-part-i.html
                      > >
                      > > However I did not cover User Interaction roles specifically. However, to me
                      > > they're no different to a developer who has work to do and that work should
                      > > be represented as stories on the backlog (or tasks depending on how you are
                      > > managing things).
                      > >
                      > > Jack
                      > > blog.agilebuddy.com
                      > > twitter.com/agilebuddy
                      > > www.agilebuddy.com
                      > >
                      > >
                      > > --- In scrumdevelopment@yahoogroups.com<scrumdevelopment%40yahoogroups.com>,
                      > > Alberto Brandolini <alberto.brandolini@> wrote:
                      > > >
                      > > > Hi all
                      > > >
                      > > > A recurring hotspot for me and some colleagues involved in agile
                      > > processes
                      > > > is "how to manage roles that do not fit in the development team".
                      > > > Scrum is explicit in talking about the cross-functional team, it might
                      > > not
                      > > > be an easy path, but it provides clear benefit.
                      > > >
                      > > > Unfortunately not all key roles reside within the organization. A typical
                      > > > example I've bumped into is the "design expert" or the "user interaction
                      > > > expert". They're quite often independent professionals, external
                      > > > contractors, with their own schedule constraints (and their personal
                      > > ability
                      > > > to respect them). As a general trend, looks external contributions by
                      > > many
                      > > > fields is increasing, but this often puts the whole process in jeopardy
                      > > > (deadlines, outbound dependencies and so on).
                      > > >
                      > > > Has anybody explored this area in depth?
                      > > >
                      > > > Thanks in advance,
                      > > >
                      > > > Alberto
                      > > >
                      > > > --
                      > > > Alberto Brandolini
                      > > > Phone: +39-347-6005027
                      > > > E-mail: alberto.brandolini@
                      > > > Web page; http://albertobrandolini.wikidot.com
                      > > > Blog: http://ziobrando.blogspot.com
                      > > > Linkedin page: http://www.linkedin.com/in/brando
                      > > >
                      > >
                      > >
                      > >
                      >
                      >
                      >
                      > --
                      > Alberto Brandolini
                      > Phone: +39-347-6005027
                      > E-mail: alberto.brandolini@...
                      > Web page; http://albertobrandolini.wikidot.com
                      > Blog: http://ziobrando.blogspot.com
                      > Linkedin page: http://www.linkedin.com/in/brando
                      >
                    Your message has been successfully submitted and would be delivered to recipients shortly.