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

Re: [scrumdevelopment] experiences on distributed Agile (was ...New Member)

Expand Messages
  • ShriKant Vashishtha
    In real life, managing man-power is an issue which companies deal in projects on regular basis. Theoretically whatever you just mentioned sounds good but
    Message 1 of 4 , Oct 23, 2012
      In real life, managing man-power is an issue which companies deal in projects on regular basis. Theoretically whatever you just mentioned sounds good but during project life-cycle, sometimes you need more people and sometimes you don't need everybody in the team (based on demand-supply model for the incoming work).

      At the same time, many a times organisations start working on new business initiatives which require additional people say 20-30. Depending on the place where you are getting this amount of skilled people onboard remains a big challenge considering the geography and cost involved.

      Outsourcing companies provide this resource-pool. Depending on your need you can add more people or can reduce team size. I am not sure if it has anything to do with Agile. It's pure business - demand-supply rule.

      I completely endorse the idea of having static teams and have them available for incoming features. That's how many companies have done the outsourcing also. However again if some extra work comes, getting extra skilled people is not a problem.

      Business values the velocity and predictability but considering the market we are in, there are business reasons because of which companies have to shrink their teams.

      > So if you can add these people as temporary SME om any existing team > and have them transfer knowledge. 

      It works when you have shortage of work with the existing team and they can take on the additional work. However in many cases, you just need extra man-power in addition to existing team.

      Kind regards,
      On Mon, Oct 22, 2012 at 4:03 PM, Jesse Houwing <jesse.houwing@...> wrote:

      Ability to shrink teams at will basically comes down to cost. You can shrink an in-house team at will as well, it's just more expensive. It's also something you really shouldn't want to do if you value your velocity statistics and predictability.

      The ability to add any type of knowledge in a moments notice sounds great, but it doesn't embed this knowledge with the team. So if you can add these people as temporary SME om any existing team and have them transfer knowledge. In the longer long turn, that will pay out even more than having them do the hard work  quickly. Training you existing team or temporarily adding the knowledge internally also comes down to cost. You can get the same person here, it's just more expensive. But in the end much more effective.

      What you're describing is a kind of throw-away employee or excel cell or 'resource', instead of a person who's career is valued and who's knowledge and experience is fostered in the company. It's something that doesn't really fit the Agile Manifesto, but sure, it works just fine if that's how you want to work :).


      On Mon, Oct 22, 2012 at 8:11 AM, ShriKant Vashishtha <vashishtha.sk@...> wrote:

      Major reasons why people do it are not limited to just cost. Important factors are ability to increase or shrink team-size at will and availability of almost all skills within a notice of 2-4 weeks. As it works even after all problems involved, outsourcing is a thriving business in all times.

      In my experience working with many distributed Agile projects, initially it's costly but in the long run it's cheaper. Costly because initially team requires collocation, setting the practices at work and investment in setting up a good communication infrastructure. However in long run this investment pays the dividend.

      Some resources to look at for distributed Agile

      Kind regards,

      On Mon, Oct 22, 2012 at 5:29 AM, Adam Sroka <adam.sroka@...> wrote:

      On Sun, Oct 21, 2012 at 2:23 PM, Adam Sroka <adam.sroka@...> wrote:
      > Welcome.
      > With regard to distributed teams I think you will find a lot of
      > information in the history of this list. I'll sum up my thinking:
      > 1) It's not a great idea.
      > 2) There are lots of valid reasons why people do it, and it does work,
      > but: it's slower, it's harder to manage, it requires great skill and
      > attention to keep from losing the Agile values, and it's probably more
      > expensive in the long run (even if the labor is cheaper per unit
      > time.)
      > 3) Because you are doing it despite all these things I have a few tips ;-)
      > Get everyone together for long enough to get to know each other at the
      > beginning and periodically thereafter. I know that it's expensive but
      > it will be worth it. Prefer higher bandwidth forms of communication
      > like video conference over lower bandwidth forms like email and
      > instant message ALL THE TIME.

      I forgot to add: keep the tools simple. Figure out how best to work
      together first before investing in something like e.g. Rally, Version
      One, etc. There's nothing wrong with the tools per se, but the idea
      that you can learn Scrum from within them is laughable.

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