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

Re: [scrumdevelopment] Team Consultants

Expand Messages
  • ravindra raghuwanshi
    Hi Eric  In our team we ve consultant as SME & also group of consultant as a different team.  I do not see any issue in this & we ve done many releases
    Message 1 of 13 , Nov 4, 2012
    • 0 Attachment
      Hi Eric 

      In our team we've consultant as SME & also group of consultant as a different team.  I do not see any issue in this & we've done many releases with this team combination.

      Scrum does not talk about employee or consultant , its only talk about team.. which can be any combination...

      Thanks,
      Ravi 


      From: Eric Tiongson <tiongks@...>
      To: "scrumdevelopment@yahoogroups.com" <scrumdevelopment@yahoogroups.com>
      Cc: "scrumdevelopment@yahoogroups.com" <scrumdevelopment@yahoogroups.com>
      Sent: Sunday, November 4, 2012 9:57 AM
      Subject: Re: [scrumdevelopment] Team Consultants

       
      That's exactly what I was thinking, I can't imagine consultants delivering stories by themselves.  Or maybe I can ask consultants to always pair up with one of the core team members.  Some of our teams are not (yet) into pair programming.

      Thanks.

      Sent from my iPad

      On Nov 5, 2012, at 1:17 AM, Michael James <mj4scrum@...> wrote:

       
      If I did that, I'd probably stipulate that those people need to act more as mentors and less as task executors.

      --mj
      (Michael)

      On Nov 4, 2012, at 9:11 AM, Eric Tiongson <tiongks@...> wrote:

       

      /luker-mode off

      I guess we've all been witness to this - too many projects and not enough specialized skills to go around or perhaps there's a small group of people who are always on demand because they are good at making things "work".  For one reason or another you find yourselves seeing people being dragged from one project to another.

      I've been reading on The Scrum Field Guide: Practical Advice for Your First Year and in the book it describes creating a group of Team Consultants that can, in a way, "lend a helping hand" every now and then to core scrum teams.

      There's a blog post regarding this here - http://www.mitchlacey.com/blog/structuring-the-team-in-scrum-agile-projects.  It explains the concept better than I can.

      This is exactly what our CEO and I have been discussing over the past few weeks, he wants a group of team consultants and I'm a bit hesitant.  Call me old-fashioned but I always try (and mostly succeeded) in keeping the same group of people within the project from start to end.

      Have you guys done this, i.e. having Team Consultants within your projects?  I have been a Team Consultant before but the engagements that I've been involved in (as a Team Consultant) are waterfall-ish and I can't quite picture in my head how this kind of arrangement would work with Scrum.


      Regards,

      Eric






    • Cass Dalton
      I agree. I also read that chapter and felt like someone had found the missing piece of my puzzle. My org has tons of heros with years of institutional
      Message 2 of 13 , Nov 4, 2012
      • 0 Attachment

        I agree.  I also read that chapter and felt like someone had found the missing piece of my puzzle.  My org has tons of "heros" with years of institutional knowledge that we rely on.  I always wondered how we would move from a fully matrixed component team culture to a delivery team culture, and the team consultant idea just made sense.  I do agree that the delivery team members still have to own the tasks, but you now don't have to constantly change the team composition from project to project just because you need some experience with a legacy component or you need that "go to" DB guy that is the "only one who can do the job right"

        On Nov 4, 2012 1:03 PM, "Eric Tiongson" <tiongks@...> wrote:
         

        That's exactly what I was thinking, I can't imagine consultants delivering stories by themselves.  Or maybe I can ask consultants to always pair up with one of the core team members.  Some of our teams are not (yet) into pair programming.

        Thanks.

        Sent from my iPad

        On Nov 5, 2012, at 1:17 AM, Michael James <mj4scrum@...> wrote:

         

        If I did that, I'd probably stipulate that those people need to act more as mentors and less as task executors.


        --mj
        (Michael)

        On Nov 4, 2012, at 9:11 AM, Eric Tiongson <tiongks@...> wrote:

         

        /luker-mode off

        I guess we've all been witness to this - too many projects and not enough specialized skills to go around or perhaps there's a small group of people who are always on demand because they are good at making things "work".  For one reason or another you find yourselves seeing people being dragged from one project to another.

        I've been reading on The Scrum Field Guide: Practical Advice for Your First Year and in the book it describes creating a group of Team Consultants that can, in a way, "lend a helping hand" every now and then to core scrum teams.

        There's a blog post regarding this here - http://www.mitchlacey.com/blog/structuring-the-team-in-scrum-agile-projects.  It explains the concept better than I can.

        This is exactly what our CEO and I have been discussing over the past few weeks, he wants a group of team consultants and I'm a bit hesitant.  Call me old-fashioned but I always try (and mostly succeeded) in keeping the same group of people within the project from start to end.

        Have you guys done this, i.e. having Team Consultants within your projects?  I have been a Team Consultant before but the engagements that I've been involved in (as a Team Consultant) are waterfall-ish and I can't quite picture in my head how this kind of arrangement would work with Scrum.


        Regards,

        Eric




      • Michael Mallete
        I think you already have good insights on the matter and would encourage to pursue that. From experience, some worked, some did not. On a recent team I was
        Message 3 of 13 , Nov 5, 2012
        • 0 Attachment
          I think you already have good insights on the matter and would encourage to pursue that.

          From experience, some worked, some did not.

          On a recent team I was involved with, management added a frontend guy to the team in order for them to jump start adding frontend to the project (mainly, the work is API for third party clients). What happened is instead of the team trying to learn from the consultant, the consultant took on all the frontend work. And then moved out. In the end, the team learned nothing and has no skills to work on future frontend work.

          On another team a few months back, the team was informed that there was a stored proc expert available to them. Given that information, the team decided on how to capitalize on that availability. What they did was to work on the db tasks, and asked advice from the stored proc expert afterwards. No one told them to do so. They just figured it out. Now, the team has stored proc capability.

          In the end, I would rather treat consultants as coaches who can accelerate the team's learning. It's for the team to decide how fast they can learn from them. Although I don't discount the possibility of consultants to actually commit some work. But would favor the former almost always.

          salamat,
          mike mallete

          On Mon, Nov 5, 2012 at 1:11 AM, Eric Tiongson <tiongks@...> wrote:
           

          /luker-mode off

          I guess we've all been witness to this - too many projects and not enough specialized skills to go around or perhaps there's a small group of people who are always on demand because they are good at making things "work".  For one reason or another you find yourselves seeing people being dragged from one project to another.

          I've been reading on The Scrum Field Guide: Practical Advice for Your First Year and in the book it describes creating a group of Team Consultants that can, in a way, "lend a helping hand" every now and then to core scrum teams.

          There's a blog post regarding this here - http://www.mitchlacey.com/blog/structuring-the-team-in-scrum-agile-projects.  It explains the concept better than I can.

          This is exactly what our CEO and I have been discussing over the past few weeks, he wants a group of team consultants and I'm a bit hesitant.  Call me old-fashioned but I always try (and mostly succeeded) in keeping the same group of people within the project from start to end.

          Have you guys done this, i.e. having Team Consultants within your projects?  I have been a Team Consultant before but the engagements that I've been involved in (as a Team Consultant) are waterfall-ish and I can't quite picture in my head how this kind of arrangement would work with Scrum.


          Regards,

          Eric



        • Jesse Houwing
          A common heard trick is to give the consultant no keyboard. He can only code-by-proxy . Having a team that is very much used to pair programming and that
          Message 4 of 13 , Nov 5, 2012
          • 0 Attachment
            A common heard trick is to give the consultant no keyboard. He can only 'code-by-proxy'. Having a team that is very much used to pair programming and that loves to learn also makes these kinds of situations a lot easier.

            On Mon, Nov 5, 2012 at 12:25 PM, Michael Mallete <mrmallete@...> wrote:


            I think you already have good insights on the matter and would encourage to pursue that.

            From experience, some worked, some did not.

            On a recent team I was involved with, management added a frontend guy to the team in order for them to jump start adding frontend to the project (mainly, the work is API for third party clients). What happened is instead of the team trying to learn from the consultant, the consultant took on all the frontend work. And then moved out. In the end, the team learned nothing and has no skills to work on future frontend work.

            On another team a few months back, the team was informed that there was a stored proc expert available to them. Given that information, the team decided on how to capitalize on that availability. What they did was to work on the db tasks, and asked advice from the stored proc expert afterwards. No one told them to do so. They just figured it out. Now, the team has stored proc capability.

            In the end, I would rather treat consultants as coaches who can accelerate the team's learning. It's for the team to decide how fast they can learn from them. Although I don't discount the possibility of consultants to actually commit some work. But would favor the former almost always.

            salamat,
            mike mallete


            On Mon, Nov 5, 2012 at 1:11 AM, Eric Tiongson <tiongks@...> wrote:
             

            /luker-mode off

            I guess we've all been witness to this - too many projects and not enough specialized skills to go around or perhaps there's a small group of people who are always on demand because they are good at making things "work".  For one reason or another you find yourselves seeing people being dragged from one project to another.

            I've been reading on The Scrum Field Guide: Practical Advice for Your First Year and in the book it describes creating a group of Team Consultants that can, in a way, "lend a helping hand" every now and then to core scrum teams.

            There's a blog post regarding this here - http://www.mitchlacey.com/blog/structuring-the-team-in-scrum-agile-projects.  It explains the concept better than I can.

            This is exactly what our CEO and I have been discussing over the past few weeks, he wants a group of team consultants and I'm a bit hesitant.  Call me old-fashioned but I always try (and mostly succeeded) in keeping the same group of people within the project from start to end.

            Have you guys done this, i.e. having Team Consultants within your projects?  I have been a Team Consultant before but the engagements that I've been involved in (as a Team Consultant) are waterfall-ish and I can't quite picture in my head how this kind of arrangement would work with Scrum.


            Regards,

            Eric






          • RonJeffries
            Hi Michael, ... The same is true within the team s own skills. If there is only one specialist, there will be queues and idle time waiting for that service.
            Message 5 of 13 , Nov 5, 2012
            • 0 Attachment
              Hi Michael,

              On Nov 5, 2012, at 6:25 AM, Michael Mallete <mrmallete@...> wrote:

              In the end, I would rather treat consultants as coaches who can accelerate the team's learning. It's for the team to decide how fast they can learn from them. Although I don't discount the possibility of consultants to actually commit some work. But would favor the former almost always.

              The same is true within the team's own skills. If there is only one specialist, there will be queues and idle time waiting for that service. Here, too, the team is wise to spread the knowledge.

              Ron Jeffries
              I'm really pissed off by what people are passing off as "agile" these days.
              You may have a red car, but that does not make it a Ferrari.
                -- Steve Hayes

            • Michael Mallete
              Hi Ron, I concur. I always advise team members to at least specialize on two skills as an early target. Eventually moving towards better cross functionality.
              Message 6 of 13 , Nov 5, 2012
              • 0 Attachment
                Hi Ron,

                I concur. I always advise team members to at  least specialize on two skills as an early target. Eventually moving towards better cross functionality.

                salamat,
                mike mallete

                On Monday, November 5, 2012, RonJeffries wrote:
                 

                Hi Michael,


                On Nov 5, 2012, at 6:25 AM, Michael Mallete <mrmallete@...> wrote:

                In the end, I would rather treat consultants as coaches who can accelerate the team's learning. It's for the team to decide how fast they can learn from them. Although I don't discount the possibility of consultants to actually commit some work. But would favor the former almost always.

                The same is true within the team's own skills. If there is only one specialist, there will be queues and idle time waiting for that service. Here, too, the team is wise to spread the knowledge.

                Ron Jeffries
                I'm really pissed off by what people are passing off as "agile" these days.
                You may have a red car, but that does not make it a Ferrari.
                  -- Steve Hayes

              • Dinesh Sharma
                I have used Team Consultants but more as Coaches. For example, one of the team member I added to a new team was very strong on Java and TDD but his main role
                Message 7 of 13 , Nov 5, 2012
                • 0 Attachment
                  I have used Team Consultants but more as Coaches. For example, one of the team member I added to a new team was very strong on Java and TDD but his main role was to help team to adopt TDD and mentor on Java, whenever required. So he wasn't used to all TDD stuff but helping other members to adopt the practice. Similarly I have used good consultants on BDD, Pair Programming for initial helping hand but there were not specialist for technical tasks...
                   
                  Thanks & Regards,
                  Dinesh Sharma
                  Director - Agile Gurukul

                  From: Eric Tiongson <tiongks@...>
                  To: "scrumdevelopment@yahoogroups.com" <scrumdevelopment@yahoogroups.com>
                  Cc: "scrumdevelopment@yahoogroups.com" <scrumdevelopment@yahoogroups.com>
                  Sent: Sunday, 4 November 2012, 17:57
                  Subject: Re: [scrumdevelopment] Team Consultants

                   
                  That's exactly what I was thinking, I can't imagine consultants delivering stories by themselves.  Or maybe I can ask consultants to always pair up with one of the core team members.  Some of our teams are not (yet) into pair programming.

                  Thanks.

                  Sent from my iPad

                  On Nov 5, 2012, at 1:17 AM, Michael James <mj4scrum@...> wrote:

                   
                  If I did that, I'd probably stipulate that those people need to act more as mentors and less as task executors.

                  --mj
                  (Michael)

                  On Nov 4, 2012, at 9:11 AM, Eric Tiongson <tiongks@...> wrote:

                   

                  /luker-mode off

                  I guess we've all been witness to this - too many projects and not enough specialized skills to go around or perhaps there's a small group of people who are always on demand because they are good at making things "work".  For one reason or another you find yourselves seeing people being dragged from one project to another.

                  I've been reading on The Scrum Field Guide: Practical Advice for Your First Year and in the book it describes creating a group of Team Consultants that can, in a way, "lend a helping hand" every now and then to core scrum teams.

                  There's a blog post regarding this here - http://www.mitchlacey.com/blog/structuring-the-team-in-scrum-agile-projects.  It explains the concept better than I can.

                  This is exactly what our CEO and I have been discussing over the past few weeks, he wants a group of team consultants and I'm a bit hesitant.  Call me old-fashioned but I always try (and mostly succeeded) in keeping the same group of people within the project from start to end.

                  Have you guys done this, i.e. having Team Consultants within your projects?  I have been a Team Consultant before but the engagements that I've been involved in (as a Team Consultant) are waterfall-ish and I can't quite picture in my head how this kind of arrangement would work with Scrum.


                  Regards,

                  Eric






                • Mitch Lacey
                  Hi Eric (and the rest on the thread). The model was actually born out of the need to keep the group of the same people on a project from start to end. The
                  Message 8 of 13 , Nov 12, 2012
                  • 0 Attachment

                    Hi Eric (and the rest on the thread).

                     

                    The model was actually born out of the need to keep the group of the same people on a project from start to end. The person in the story (the horse trading sessions) was me. I saw other people in the company mismanaging their projects and I was always on the short end, or at least they tried to put me there, by taking people off my projects to solve their own. I talked to the people I worked with and others and we all agreed that it would be desirable to have consistency between teams – no pulling people off. The issue was what to do with the SME’s like the architects, the designers, the SQL experts and the like – hence the birth of the “team consultant”.

                     

                    The consultant is responsible for helping grow the teams, or act as Mentors like some have said on this thread. I like to have the teams mange the work and their growth – meaning a consultant can do work, but if they do then velocity is artificially inflated. Further, if the team relies on the consultant to just do work, they won’t learn how to do the work on their own. The objective is not to fully wean the team off of consultants, but to limit their time by having the consultant make the team better so they don’t need to be there as much. Some people, like designers or tech writers, will always have a job as a consultant. Others, like architects, may be able to teach people their craft and way of thinking and their time will go down. But don’t worry – as long as companies hire people and others leave, they’ll never be out of work, so to speak. And like you said Eric, pairing is one of the *the* best ways to do this sharing of information.

                     

                    As was said on other posts in this thread, the model does not condone matrixed specialists, it just recognizes these people as consultants, and it does say that a team of consultants is by definition not a team as they are all working in their dedicated specialties on single parts of a whole system at different times, compared to the dedicated team who is working on all parts of a whole system at all times.

                     

                    Does this help?

                     

                    Mitch

                     

                     

                    From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Eric Tiongson
                    Sent: Sunday, November 04, 2012 9:12 AM
                    To: scrumdevelopment@yahoogroups.com
                    Subject: [scrumdevelopment] Team Consultants

                     

                     

                    /luker-mode off

                     

                    I guess we've all been witness to this - too many projects and not enough specialized skills to go around or perhaps there's a small group of people who are always on demand because they are good at making things "work".  For one reason or another you find yourselves seeing people being dragged from one project to another.

                     

                    I've been reading on The Scrum Field Guide: Practical Advice for Your First Year and in the book it describes creating a group of Team Consultants that can, in a way, "lend a helping hand" every now and then to core scrum teams.

                     

                    There's a blog post regarding this here - http://www.mitchlacey.com/blog/structuring-the-team-in-scrum-agile-projects.  It explains the concept better than I can.

                     

                    This is exactly what our CEO and I have been discussing over the past few weeks, he wants a group of team consultants and I'm a bit hesitant.  Call me old-fashioned but I always try (and mostly succeeded) in keeping the same group of people within the project from start to end.

                     

                    Have you guys done this, i.e. having Team Consultants within your projects?  I have been a Team Consultant before but the engagements that I've been involved in (as a Team Consultant) are waterfall-ish and I can't quite picture in my head how this kind of arrangement would work with Scrum.

                     

                     

                    Regards,

                     

                    Eric

                     

                     

                  • Eric Tiongson
                    Thanks, Mitch, Charles, Michael and everyone for the feedback. Your insights are always helpful. :-) Cheers.
                    Message 9 of 13 , Nov 18, 2012
                    • 0 Attachment
                      Thanks, Mitch, Charles, Michael and everyone for the feedback.

                      Your insights are always helpful. :-)

                      Cheers.
                    Your message has been successfully submitted and would be delivered to recipients shortly.