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

Re: [scrumdevelopment] Scrum works on a team with multiple projects?

Expand Messages
  • Ali H. Moghadam
    You (as the project manager) can still use the same project concepts to deal with government. But your team needs to have a list of prioritised items for each
    Message 1 of 31 , Apr 25, 2013
    • 0 Attachment
      You (as the project manager) can still use the same project concepts to deal with government. But your team needs to have a list of prioritised items for each sprint, and they should be able to self-organise themselves to make these items done. Although it's much more better if the items in each sprint have a shared focus, so that you (and your team) can detect a solid goal for each sprint, not just doing some diffused task. 

      Your team may benefit from retrospectives and daily meetings, even if you are not using Scrum! They are necessary practices for every team, as they will provide the team the communication and feedback they need to find out and remove impediments of their teamwork. 

      All of those practices are good and useful, but you are not agile, until you deliver value continuously. And it is not possible, unless you have a customer who needs and appreciates this continuos value delivery. Big bureaucratic governmental organisations usually are not good customers, I think! They are usually too lazy with slow cumbersome routines for approving everything. But you may still enjoy benefits of sone agile practices internally in your team, without being agile at the end! 


      On Apr 24, 2013, at 3:54 PM, Leonardo Nunes <leonardobn@...> wrote:


      Hey guys, thank you for your opinion. Help me a lot.

      I agree with you. I have to report in a way, with this "little projects" because of function point counting and enterprise indicators per project. The Goverment want to control how many costs with error fixing, new features, separatedly. The contracts are a big problem for us. Its complicated to group this "little projects"... we are tryng here.

      So what i'm thinking to do is work with in a scrum way, using the framework style to build the product, abstracting the concept of project of we are using here. I will group this "little projects" like PBIs in a Product Backlog. But i will not have one big project to manage - with cost and date. Just a style of work will change using scrum, with plannings, retros, grooming, etc... and the little projects will be attended in the sprints of this "big fake project", or a new style way to do the work, better say that.

      This could work, i think, i will try starting today.

      Thank you all.

      2013/4/23 Adam Sroka <adam.sroka@...>

      Just because your management wants you to report about "projects" doesn't mean you have to force your team to work that way. Be a servant leader and give them what they need to build great software. Tell your bosses what they need to know.

      On Apr 23, 2013 4:12 PM, "Ron Jeffries" <ronjeffries@...> wrote:


      On Apr 23, 2013, at 5:25 PM, Markus Gaertner <mgaertne@...> wrote:

      Or change your understanding of "projects" and why you need multiple of them.

      Or accept inferior results. By the way, you're already getting inferior results. With Scrum, they may be better. 

      Ron Jeffries
      I know we always like to say it'll be easier to do it now than it
      will be to do it later. Not likely. I plan to be smarter later than
      I am now, so I think it'll be just as easy later, maybe even easier.
      Why pay now when we can pay later?

      Leonardo Nunes

    • Mark Levison
      Mark - this discussion proves the earlier point. Project says nothing about size and so its unclear how big a thing you re describing. Leonardo s projects were
      Message 31 of 31 , Apr 30, 2013
      • 0 Attachment
        Mark - this discussion proves the earlier point. Project says nothing about size and so its unclear how big a thing you're describing. Leonardo's projects were anything from hours to weeks. Yours are months to a year. Its likely they have little in common.

        I hereby declare the word "project" retired. If I see it used again I will take it out behind the barn and shoot it :-)


        On Tue, Apr 30, 2013 at 10:02 AM, woynam <woyna@...> wrote:

        I never said our teams are context switching between projects. I simply stated that a project is a large epic. As such, it needs to be broken down into smaller features/stories. Our teams usually work on one project, with an average of 4 iterations.

        Thus, projects themselves are not the problem. How you prioritize and execute them is the rub.

        Of course, if one has huge projects, then there will be pressure to work on multiple projects concurrently, as the business side generally doesn't like to hear that their project will be starting in 12 months.

        The key, as usual, is to develop the skills to reduce features down to the smallest possible size that still provides business value.


        --- In scrumdevelopment@yahoogroups.com, Cass Dalton <cassdalton73@...> wrote:
        > It was definitely a bit harsh, and also a bit extremist. But the
        > underlying sentiment is true. It will be very difficult to gain benefits
        > of agile that are normally presented in bullet points in an executive
        > summary if your teams are multi-tasking between heterogeneous projects.
        > One of the values of agile is a focused team. The team is completely
        > focused and united towards a common goal. If the goals of a "team" or even
        > an individual are divergent in any way, it will detract from the normal
        > agile performance gains. Ignoring this means you're using Scrum as a
        > process for the value of the process itself, and not as a process that
        > facilitates cooperation and interaction.
        > On Fri, Apr 26, 2013 at 9:51 AM, woynam <woyna@...> wrote:
        > > **

        > >
        > >
        > >
        > > That's a bit harsh. To me, a project is a very large epic. It should be as
        > > big as it needs to be, but no bigger. It comprises the smallest number of
        > > features/stories that must be built and deployed together to achieve a
        > > business objective.
        > >
        > > Now, there are certainly times where specific features/stories can be
        > > considered nice to have, so one must always try to ensure that the project
        > > represents only necessary features.
        > >
        > > Mark
        > >
        > > --- In scrumdevelopment@yahoogroups.com, "Steve" <steve@> wrote:
        > > >
        > > > Scrum is not about projects - it is about products!!
        > > >
        > > > You and your managers obsession with seeing everything as projects will
        > > stop you ever becoming Agile and you will probably never be able to
        > > implement properly!
        > > >
        > > > --- In scrumdevelopment@yahoogroups.com, Leonardo Nunes <leonardobn@>
        > > wrote:
        > > > >
        > > > > Does Scrum works on a team with multiple projects?
        > > > >
        > > > > On a 1 team with 1 project we have perfect scenario.
        > > > >
        > > > > But in my organization we have 31 development teams. Each team has 20
        > > to 50
        > > > > projects at same time.
        > > > >
        > > > > This happens because each team has a big system to take care, and this
        > > big
        > > > > system has a set of sub-systems. A project is created to make
        > > evolutions or
        > > > > correct erros in each sub-system and i can not make, until now, a
        > > project
        > > > > to make a evolution on a several sub-systems in the same time, this is
        > > a
        > > > > goverment limitation.
        > > > >
        > > > > So my question is - Scrum works in this scenario? How can i deal with
        > > > > several projects on a team? With a team who has 15 projects, i cant do
        > > 15
        > > > > sprint plannings... this is a crazy!
        > > > >
        > > > > Please, help me here guys.
        > > > >
        > > > > Thanks
        > > > >
        > > > > Leo
        > > > >
        > > > > --
        > > > > Leonardo Nunes
        > > > > http://about.me/leonardobn
        > > > >
        > > >
        > >
        > >
        > >

        Mark Levison
        Agile Pain Relief Consulting | Writing
        Proud Sponsor of Agile Tour Gatineau Ottawa Nov 28, Toronto 26 and Montreal 24
      Your message has been successfully submitted and would be delivered to recipients shortly.