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

Size of team a barrier to SCRUM and Agile

Expand Messages
  • Mike Frymyer
    I am a project manager and I work for an IT department that has 5 developers. Those 5 developers are working on 4 - 5 projects at any given time. They are also
    Message 1 of 24 , Jan 13, 2012
    • 0 Attachment
      I am a project manager and I work for an IT department that has 5 developers. Those 5 developers are working on 4 - 5 projects at any given time. They are also responsible for support and maintenance.
       
      My CIO is very frustrated with the fact that they are unable to provide goo levels of efforts for their work. This leads to late deliverables. He is also pushing us very hard toward Agile methods thinking that will fix all of our problems.
       
      A typical development timeframe for the vast majority of our products is between 40 and 400 hours. This is for .NET and Business Objects reporting.
       
      I have taken the SCRUMMaster classes and from all that I see you need to have dedicated teams to a specific work effort. This is due in large part that a developer needs to be present at all times; such as during the User Story definition and then decomposing the User Stories into more detailed requirements during the development or SPRINT.
       
      I have been trying to capture the detailed requirements for the backlog to eliminate the need tp have a developer spend time with the customer, but my boss says I am taking too long on the requirements (usually about 30 hours in as coompressed a time span as schedules will allow).
       
      I am looking for suggestions on what I may be doing wrong and how I might be able to utilize Agile without a dedicated development team to each effort.

      Mike
    • RonJeffries
      Hello Mike, It is time for some tough love here ... ... How s that working for you? My guess: horribly. There s a reason: Suppose each project would require
      Message 2 of 24 , Jan 18, 2012
      • 0 Attachment
        Hello Mike,

        It is time for some tough love here ...

        On Jan 13, 2012, at 10:26 AM, Mike Frymyer wrote:

        I am a project manager and I work for an IT department that has 5 developers. Those 5 developers are working on 4 - 5 projects at any given time. They are also responsible for support and maintenance.

        How's that working for you? My guess: horribly. There's a reason:

        Suppose each project would require five weeks. Assuming perfect task switching, your delivery plans look like this:

        1234512345123451234512345SHIP

        But you won't get perfect task switching. There will be overhead and mistakes. It looks more like this:

        1.2.3.4.5.1.2.3.4.5.1.2.3.4.5.1.2.3.4.5.1.2.3.4.5.SxHxIxPx

        If you work on one thing at a time it would look like this:
        1111122222333334444455555
         xxxxxSHIP  SHIP  SHIP  SHIP  SHIP
         
        My CIO is very frustrated with the fact that they are unable to provide goo levels of efforts for their work. This leads to late deliverables. He is also pushing us very hard toward Agile methods thinking that will fix all of our problems.

        BULL. There are no late deliverables due to "inability to provide good levels of effort". There is only bad product management. The team should be assumed to be working as effectively as they can under the (let's face it, not very bright) conditions they've been put under. Once you learn to manage that flow, you can work to improve it. You do this by removing impediments, not by applying more pressure or adding in more work.

        The problem of MANAGEMENT is to select work in such a way as to get the best possible product by the desired delivery date. This will be a lot easier for everyone if the team only works on one thing at a time. Since it will also have lower overhead and produce fewer errors while delivering much sooner, it only has one downside: it will require some managers to make some decisions, which by the way is their job.
         
        A typical development timeframe for the vast majority of our products is between 40 and 400 hours. This is for .NET and Business Objects reporting.

        OK ... How do you get these numbers? Are they estimated by the sales department? By the CIO? By you? By the developers? 
         
        I have taken the SCRUMMaster classes and from all that I see you need to have dedicated teams to a specific work effort. This is due in large part that a developer needs to be present at all times; such as during the User Story definition and then decomposing the User Stories into more detailed requirements during the development or SPRINT.

        A developer present at all times? Do you perhaps mean a Product Owner? Tell me about your Product Owners, who must be business-side people, fully empowered to decide what goes into the product, and what does not. Did you notice in your ScrumMaster training that the Product Owner is solely responsible for the delivery of the best possible product by the deadline?
         
        I have been trying to capture the detailed requirements for the backlog to eliminate the need tp have a developer spend time with the customer, but my boss says I am taking too long on the requirements (usually about 30 hours in as coompressed a time span as schedules will allow).

        You are a project manager. This is not a Scrum role as far as I am aware. Perhaps you are trying to take on the Product Owner role? If so, have you had Product Owner training?

        It also sounds to me as if no one in management is on board with doing Scrum, much less understands what it means. Am I getting the wrong impression here?
         
        I am looking for suggestions on what I may be doing wrong and how I might be able to utilize Agile without a dedicated development team to each effort.

        If you are going to spread your teams over multiple projects, that is such a bad idea, that I implore you, as one of the authors of the Agile manifesto, to call your process anything else but not Agile.

        Ron Jeffries
        www.XProgramming.com
        There's no word for accountability in Finnish. Accountability is something that is left when responsibility has been subtracted. 
        --Pasi Sahlberg

      • Wouter Lagerweij
        Hi Mike, Agile isn t as much about fixing all your problems, as it is about making them very visible. I think that that is already the case for you:-) This is
        Message 3 of 24 , Jan 18, 2012
        • 0 Attachment
          Hi Mike,

          Agile isn't as much about fixing all your problems, as it is about making them very visible. I think that that is already the case for you:-) This is good.

          I don't know exactly what you mean by 'unable to provide good levels of efforts for their work'. I assume you are talking about accuracy of estimates? As you might have heard on your Scrum Master training, accuracy of estimates is not really expected. But one very good way to improve developers' understanding of what they are supposed to develop, is to make sure that they can talk directly to their customers.

          A way to handle multiple project/stakeholders and one team is to create a single backlog for the team, with stories in it from each project/stakeholder. Make sure that those 400 hrs requirements are split into smaller pieces, though, otherwise some projects will never get any work done on them. And make sure that you then get real priorities set for that backlog: the team should work as a team on whichever item is on top. And only one item can be on top. Since your CIO is in favour of Agile, he should be able to support you in this towards your stakeholders.

          If your requirements are split-up into small enough pieces, they won't take 30 hours to prepare, especially if you share the preparation with the development team. Just to re-iterate: this is NOT wasted time! Most of the time for development is in understanding what needs to be made, or in recovering from not understanding.

          good luck,

          Wouter

          On Fri, Jan 13, 2012 at 4:26 PM, Mike Frymyer <mfrymyer@...> wrote:
           

          I am a project manager and I work for an IT department that has 5 developers. Those 5 developers are working on 4 - 5 projects at any given time. They are also responsible for support and maintenance.
           
          My CIO is very frustrated with the fact that they are unable to provide goo levels of efforts for their work. This leads to late deliverables. He is also pushing us very hard toward Agile methods thinking that will fix all of our problems.
           
          A typical development timeframe for the vast majority of our products is between 40 and 400 hours. This is for .NET and Business Objects reporting.
           
          I have taken the SCRUMMaster classes and from all that I see you need to have dedicated teams to a specific work effort. This is due in large part that a developer needs to be present at all times; such as during the User Story definition and then decomposing the User Stories into more detailed requirements during the development or SPRINT.
           
          I have been trying to capture the detailed requirements for the backlog to eliminate the need tp have a developer spend time with the customer, but my boss says I am taking too long on the requirements (usually about 30 hours in as coompressed a time span as schedules will allow).
           
          I am looking for suggestions on what I may be doing wrong and how I might be able to utilize Agile without a dedicated development team to each effort.

          Mike




          --
          Wouter Lagerweij         | wouter@...
        • woynam
          Well, why don t you start with working on a single project at a time. I m fairly confident that context switching is reducing your productivity. You re also
          Message 4 of 24 , Jan 18, 2012
          • 0 Attachment
            Well, why don't you start with working on a single project at a time. I'm fairly confident that context switching is reducing your productivity. You're also guaranteeing that all but one project will be delivered later than they would if you serialized the development.

            What is a "good level of effort"? It sounds like the team is pulled in 5 directions at once. Can't the CIO prioritize? Surely *one* of the projects has to have a higher priority than the others, no?

            If the CIO can't prioritize, then how are the team members supposed to prioritize the work?

            Mark

            --- In scrumdevelopment@yahoogroups.com, Mike Frymyer <mfrymyer@...> wrote:
            >
            > I am a project manager and I work for an IT department that has 5
            > developers. Those 5 developers are working on 4 - 5 projects at any given
            > time. They are also responsible for support and maintenance.
            >
            > My CIO is very frustrated with the fact that they are unable to provide goo
            > levels of efforts for their work. This leads to late deliverables. He is
            > also pushing us very hard toward Agile methods thinking that will fix all
            > of our problems.
            >
            > A typical development timeframe for the vast majority of our products is
            > between 40 and 400 hours. This is for .NET and Business Objects reporting.
            >
            > I have taken the SCRUMMaster classes and from all that I see you need to
            > have dedicated teams to a specific work effort. This is due in large part
            > that a developer needs to be present at all times; such as during the User
            > Story definition and then decomposing the User Stories into more
            > detailed requirements during the development or SPRINT.
            >
            > I have been trying to capture the detailed requirements for the backlog to
            > eliminate the need tp have a developer spend time with the customer, but my
            > boss says I am taking too long on the requirements (usually about 30 hours
            > in as coompressed a time span as schedules will allow).
            >
            > I am looking for suggestions on what I may be doing wrong and how I might
            > be able to utilize Agile without a dedicated development team to each
            > effort.
            >
            > Mike
            >
          • Michael Vizdos
            AND. Good stuff so far... to reiterate the tough conversation you are going to have to have with the CIO and other stakeholders: Prioritize the projects or
            Message 5 of 24 , Jan 18, 2012
            • 0 Attachment
              AND.

              Good stuff so far... to reiterate the tough conversation you are going to have to have with the CIO and other stakeholders:

              Prioritize the projects or work.

              1
              2
              3
              4
              5

              not

              11111

              or any other permutation of that.

              1
              2
              3
              4
              5

              This is hard.  That's the job of the CIO or someone outside the team -- prioritize the work and then give the team what they need to get it done.  

              Let us know if you need help having that conversation!

              Thank you,

              - Mike Vizdos

               And now all of the different the ways you can connect with me:

                www.michaelvizdos.com
                www.implementingscrum.com
               @mvizdos on twitter
               www.facebook.com/vizdosenterprises
               A  member of www.AgileRenovation.com


              On Wed, Jan 18, 2012 at 3:23 PM, woynam <woyna@...> wrote:
               


              Well, why don't you start with working on a single project at a time. I'm fairly confident that context switching is reducing your productivity. You're also guaranteeing that all but one project will be delivered later than they would if you serialized the development.

              What is a "good level of effort"? It sounds like the team is pulled in 5 directions at once. Can't the CIO prioritize? Surely *one* of the projects has to have a higher priority than the others, no?

              If the CIO can't prioritize, then how are the team members supposed to prioritize the work?

              Mark



              --- In scrumdevelopment@yahoogroups.com, Mike Frymyer <mfrymyer@...> wrote:
              >
              > I am a project manager and I work for an IT department that has 5
              > developers. Those 5 developers are working on 4 - 5 projects at any given
              > time. They are also responsible for support and maintenance.
              >
              > My CIO is very frustrated with the fact that they are unable to provide goo
              > levels of efforts for their work. This leads to late deliverables. He is
              > also pushing us very hard toward Agile methods thinking that will fix all
              > of our problems.
              >
              > A typical development timeframe for the vast majority of our products is
              > between 40 and 400 hours. This is for .NET and Business Objects reporting.
              >
              > I have taken the SCRUMMaster classes and from all that I see you need to
              > have dedicated teams to a specific work effort. This is due in large part
              > that a developer needs to be present at all times; such as during the User
              > Story definition and then decomposing the User Stories into more
              > detailed requirements during the development or SPRINT.
              >
              > I have been trying to capture the detailed requirements for the backlog to
              > eliminate the need tp have a developer spend time with the customer, but my
              > boss says I am taking too long on the requirements (usually about 30 hours
              > in as coompressed a time span as schedules will allow).
              >
              > I am looking for suggestions on what I may be doing wrong and how I might
              > be able to utilize Agile without a dedicated development team to each
              > effort.
              >
              > Mike
              >


            • Malcolm Anderson
              Mike Ron has made some very good observations. Your company has some systemic issues that are not going to be quick-fixed. There are ways to do multi-threaded
              Message 6 of 24 , Jan 18, 2012
              • 0 Attachment
                Mike

                Ron has made some very good observations.

                Your company has some systemic issues that are not going to be quick-fixed. 

                There are ways to do multi-threaded development, but you need to understand that your task switching is going to cost your development team about 15% effectiveness for each additional project over the first one.

                That translates to between 60% - 75% of your development effectiveness is being lost by working on so many projects simultaniously.

                Good luck

                Malcolm

                --

                Malcolm Anderson
                Scrum Coach & Agile Engineer
                http://www.PragmaticAgility.com/blog








                On Fri, Jan 13, 2012 at 7:26 AM, Mike Frymyer <mfrymyer@...> wrote:
                 

                I am a project manager and I work for an IT department that has 5 developers. Those 5 developers are working on 4 - 5 projects at any given time. They are also responsible for support and maintenance.
                 
                My CIO is very frustrated with the fact that they are unable to provide goo levels of efforts for their work. This leads to late deliverables. He is also pushing us very hard toward Agile methods thinking that will fix all of our problems.
                 
                A typical development timeframe for the vast majority of our products is between 40 and 400 hours. This is for .NET and Business Objects reporting.
                 
                I have taken the SCRUMMaster classes and from all that I see you need to have dedicated teams to a specific work effort. This is due in large part that a developer needs to be present at all times; such as during the User Story definition and then decomposing the User Stories into more detailed requirements during the development or SPRINT.
                 
                I have been trying to capture the detailed requirements for the backlog to eliminate the need tp have a developer spend time with the customer, but my boss says I am taking too long on the requirements (usually about 30 hours in as coompressed a time span as schedules will allow).
                 
                I am looking for suggestions on what I may be doing wrong and how I might be able to utilize Agile without a dedicated development team to each effort.

                Mike




              • Malcolm Anderson
                Mike One other question. What is your release schedule? I m guessing that it s more than bi-monthly with no bi-weekly releases to the CIO. Malcolm -- Malcolm
                Message 7 of 24 , Jan 18, 2012
                • 0 Attachment
                  Mike

                  One other question.

                  What is your release schedule? 

                  I'm guessing that it's more than bi-monthly with no bi-weekly releases to the CIO.

                  Malcolm

                  --

                  Malcolm Anderson
                  Scrum Coach & Agile Engineer
                  http://www.PragmaticAgility.com/blog



                  On Fri, Jan 13, 2012 at 7:26 AM, Mike Frymyer <mfrymyer@...> wrote:
                   

                  I am a project manager and I work for an IT department that has 5 developers. Those 5 developers are working on 4 - 5 projects at any given time. They are also responsible for support and maintenance.
                   
                  My CIO is very frustrated with the fact that they are unable to provide goo levels of efforts for their work. This leads to late deliverables. He is also pushing us very hard toward Agile methods thinking that will fix all of our problems.
                   
                  A typical development timeframe for the vast majority of our products is between 40 and 400 hours. This is for .NET and Business Objects reporting.
                   
                  I have taken the SCRUMMaster classes and from all that I see you need to have dedicated teams to a specific work effort. This is due in large part that a developer needs to be present at all times; such as during the User Story definition and then decomposing the User Stories into more detailed requirements during the development or SPRINT.
                   
                  I have been trying to capture the detailed requirements for the backlog to eliminate the need tp have a developer spend time with the customer, but my boss says I am taking too long on the requirements (usually about 30 hours in as coompressed a time span as schedules will allow).
                   
                  I am looking for suggestions on what I may be doing wrong and how I might be able to utilize Agile without a dedicated development team to each effort.

                  Mike




                • Ram Srinivasan
                  Ron: Great Answer. Lot of us (including me) are in the same boat as Mike. Question. How do you manage new development, along with maintaining existing
                  Message 8 of 24 , Jan 18, 2012
                  • 0 Attachment
                    Ron:

                    Great Answer. Lot of us (including me) are in the same boat as  Mike. 

                    Question.

                    How do you manage new development, along with maintaining existing application/products, especially if the team is small, given that this team has actually developed the( now deployed)  "cash cow" application. My answer is along the lines of have a batman (http://jamesshore.com/Agile-Book/iteration_planning.html ), but if there are multiple products to maintain (including hot fixes), it really becomes difficult. How do you handle such circumstances ?

                    Thanks,
                    Ram

                    On Wed, Jan 18, 2012 at 2:28 PM, RonJeffries <ronjeffries@...> wrote:
                     

                    Hello Mike,


                    It is time for some tough love here ...

                    On Jan 13, 2012, at 10:26 AM, Mike Frymyer wrote:

                    I am a project manager and I work for an IT department that has 5 developers. Those 5 developers are working on 4 - 5 projects at any given time. They are also responsible for support and maintenance.

                    How's that working for you? My guess: horribly. There's a reason:

                    Suppose each project would require five weeks. Assuming perfect task switching, your delivery plans look like this:

                    1234512345123451234512345SHIP

                    But you won't get perfect task switching. There will be overhead and mistakes. It looks more like this:

                    1.2.3.4.5.1.2.3.4.5.1.2.3.4.5.1.2.3.4.5.1.2.3.4.5.SxHxIxPx

                    If you work on one thing at a time it would look like this:
                    1111122222333334444455555
                     xxxxxSHIP  SHIP  SHIP  SHIP  SHIP
                     
                    My CIO is very frustrated with the fact that they are unable to provide goo levels of efforts for their work. This leads to late deliverables. He is also pushing us very hard toward Agile methods thinking that will fix all of our problems.

                    BULL. There are no late deliverables due to "inability to provide good levels of effort". There is only bad product management. The team should be assumed to be working as effectively as they can under the (let's face it, not very bright) conditions they've been put under. Once you learn to manage that flow, you can work to improve it. You do this by removing impediments, not by applying more pressure or adding in more work.

                    The problem of MANAGEMENT is to select work in such a way as to get the best possible product by the desired delivery date. This will be a lot easier for everyone if the team only works on one thing at a time. Since it will also have lower overhead and produce fewer errors while delivering much sooner, it only has one downside: it will require some managers to make some decisions, which by the way is their job.

                     
                    A typical development timeframe for the vast majority of our products is between 40 and 400 hours. This is for .NET and Business Objects reporting.

                    OK ... How do you get these numbers? Are they estimated by the sales department? By the CIO? By you? By the developers? 

                     
                    I have taken the SCRUMMaster classes and from all that I see you need to have dedicated teams to a specific work effort. This is due in large part that a developer needs to be present at all times; such as during the User Story definition and then decomposing the User Stories into more detailed requirements during the development or SPRINT.

                    A developer present at all times? Do you perhaps mean a Product Owner? Tell me about your Product Owners, who must be business-side people, fully empowered to decide what goes into the product, and what does not. Did you notice in your ScrumMaster training that the Product Owner is solely responsible for the delivery of the best possible product by the deadline?

                     
                    I have been trying to capture the detailed requirements for the backlog to eliminate the need tp have a developer spend time with the customer, but my boss says I am taking too long on the requirements (usually about 30 hours in as coompressed a time span as schedules will allow).

                    You are a project manager. This is not a Scrum role as far as I am aware. Perhaps you are trying to take on the Product Owner role? If so, have you had Product Owner training?

                    It also sounds to me as if no one in management is on board with doing Scrum, much less understands what it means. Am I getting the wrong impression here?

                     
                    I am looking for suggestions on what I may be doing wrong and how I might be able to utilize Agile without a dedicated development team to each effort.

                    If you are going to spread your teams over multiple projects, that is such a bad idea, that I implore you, as one of the authors of the Agile manifesto, to call your process anything else but not Agile.

                    Ron Jeffries
                    www.XProgramming.com
                    There's no word for accountability in Finnish. Accountability is something that is left when responsibility has been subtracted. 
                    --Pasi Sahlberg


                  • JackM
                    What many managers don t understand is that one of the most wasteful things is multi-tasking. In lean thinking they call this a transportation cost or a
                    Message 9 of 24 , Jan 20, 2012
                    • 0 Attachment
                      What many managers don't understand is that one of the most wasteful things is multi-tasking. In lean thinking they call this a transportation cost or a switching cost. Every time the developer drops what he or she is doing and picks up on something new, he has to relearn what he did and takes time to pick up where he left off. It's not a very efficient way to work. All of the experts will agree on this.

                      Now it's not always possible in companies to have dedicated focused teams, I understand that. Never the less Scrum Masters should strive to get to this point. There are charts in Mary Popendiecks book that indicated the effects of multi-tasking as well as sheduling teams to capacity.

                      Now how to deliver this message to your manager is a different story. Perhaps get him to read Mary Poppendiek's book on Lean and in particular the 7 wastes in software development.

                      Hope this helps
                      Jack
                      www.agilebuddy.com

                      --- In scrumdevelopment@yahoogroups.com, Mike Frymyer <mfrymyer@...> wrote:
                      >
                      > I am a project manager and I work for an IT department that has 5
                      > developers. Those 5 developers are working on 4 - 5 projects at any given
                      > time. They are also responsible for support and maintenance.
                      >
                      > My CIO is very frustrated with the fact that they are unable to provide goo
                      > levels of efforts for their work. This leads to late deliverables. He is
                      > also pushing us very hard toward Agile methods thinking that will fix all
                      > of our problems.
                      >
                      > A typical development timeframe for the vast majority of our products is
                      > between 40 and 400 hours. This is for .NET and Business Objects reporting.
                      >
                      > I have taken the SCRUMMaster classes and from all that I see you need to
                      > have dedicated teams to a specific work effort. This is due in large part
                      > that a developer needs to be present at all times; such as during the User
                      > Story definition and then decomposing the User Stories into more
                      > detailed requirements during the development or SPRINT.
                      >
                      > I have been trying to capture the detailed requirements for the backlog to
                      > eliminate the need tp have a developer spend time with the customer, but my
                      > boss says I am taking too long on the requirements (usually about 30 hours
                      > in as coompressed a time span as schedules will allow).
                      >
                      > I am looking for suggestions on what I may be doing wrong and how I might
                      > be able to utilize Agile without a dedicated development team to each
                      > effort.
                      >
                      > Mike
                      >
                    • Abhilash
                      Mike I have few suggestions. Scrum doesn t ask or prescribes a very detailed requirement document. There should be sufficient knowledge within the team
                      Message 10 of 24 , Jan 22, 2012
                      • 0 Attachment
                        Mike I have few suggestions.
                        Scrum doesn't ask or prescribes a very detailed requirement document. There should be sufficient knowledge within the team to start the work. The backlog creation and adding the just sufficient details in the PBI's is the job of Product Owner; PO can create a rough  draft and then team can comment on it. Any doubts/queries will be redirected back to customers.  A scrummaster or agile PM should ensure this interactions should happen between PO, feature team & end customers. Scrum is all about agility and discussion so please dont prevent this flow. I used to be in the same boat, creating everything for the team but it didnt help the ultimate goal of self organizing team; now i have stepped back & team is doing a great job.

                        I agree stopping a task in between and jumping to new is very bad & such multitasking should be avoided. If there are couple of projects tasks from all projects can be added to sprint. They just have to be prioritized. We know the teams velocity and any task more than the velocity wouldnt be done. if the team is handling 5 projects then there may be a case that the sprint will be full with the tasks of first two projects. If the tasks of other projects are to be done then we need more resources or team will have to drop task from project 1 or 2 from the sprint :) ( before or during sprint planning & not during the actual execution of the sprint).
                        Regards
                        Abhilash



                        From: JackM <jack@...>
                        To: scrumdevelopment@yahoogroups.com
                        Sent: Saturday, 21 January 2012 4:53 AM
                        Subject: [scrumdevelopment] Re: Size of team a barrier to SCRUM and Agile

                        What many managers don't understand is that one of the most wasteful things is multi-tasking. In lean thinking they call this a transportation cost or a switching cost. Every time the developer drops what he or she is doing and picks up on something new, he has to relearn what he did and takes time to pick up where he left off. It's not a very efficient way to work. All of the experts will agree on this.

                        Now it's not always possible in companies to have dedicated focused teams, I understand that. Never the less Scrum Masters should strive to get to this point. There are charts in Mary Popendiecks book that indicated the effects of multi-tasking as well as sheduling teams to capacity.

                        Now how to deliver this message to your manager is a different story. Perhaps get him to read Mary Poppendiek's book on Lean and in particular the 7 wastes in software development.

                        Hope this helps
                        Jack
                        www.agilebuddy.com

                        --- In scrumdevelopment@yahoogroups.com, Mike Frymyer <mfrymyer@...> wrote:
                        >
                        > I am a project manager and I work for an IT department that has 5
                        > developers. Those 5 developers are working on 4 - 5 projects at any given
                        > time. They are also responsible for support and maintenance.
                        >
                        > My CIO is very frustrated with the fact that they are unable to provide goo
                        > levels of efforts for their work. This leads to late deliverables. He is
                        > also pushing us very hard toward Agile methods thinking that will fix all
                        > of our problems.
                        >
                        > A typical development timeframe for the vast majority of our products is
                        > between 40 and 400 hours. This is for .NET and Business Objects reporting.
                        >
                        > I have taken the SCRUMMaster classes and from all that I see you need to
                        > have
                        dedicated teams to a specific work effort. This is due in large part
                        > that a developer needs to be present at all times; such as during the User
                        > Story definition and then decomposing the User Stories into more
                        > detailed requirements during the development or SPRINT.
                        >
                        > I have been trying to capture the detailed requirements for the backlog to
                        > eliminate the need tp have a developer spend time with the customer, but my
                        > boss says I am taking too long on the requirements (usually about 30 hours
                        > in as coompressed a time span as schedules will allow).
                        >
                        > I am looking for suggestions on what I may be doing wrong and how I might
                        > be able to utilize Agile without a dedicated development team to each
                        > effort.
                        >
                        > Mike
                        >




                        ------------------------------------

                        To Post a message, send it to:  scrumdevelopment@...
                        To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links

                        <*> To visit your group on the web, go to:
                            http://groups.yahoo.com/group/scrumdevelopment/

                        <*> Your email settings:
                            Individual Email | Traditional

                        <*> To change settings online go to:
                            http://groups.yahoo.com/group/scrumdevelopment/join
                            (Yahoo! ID required)

                        <*> To change settings via email:
                            scrumdevelopment-digest@yahoogroups.com
                            scrumdevelopment-fullfeatured@yahoogroups.com

                        <*> To unsubscribe from this group, send an email to:
                            scrumdevelopment-unsubscribe@yahoogroups.com

                        <*> Your use of Yahoo! Groups is subject to:
                            http://docs.yahoo.com/info/terms/



                      • scrumnoob
                        I introduced Scrum to a company that had challenges around developers never finish anything I dont know where the work is getting done what are the
                        Message 11 of 24 , Jan 25, 2012
                        • 0 Attachment
                          I introduced Scrum to a company that had challenges around "developers never finish anything" "I dont know where the work is getting done" "what are the developers doing with their time"

                          One of the problems was context switching and constant re-prioritization.

                          After some difficult conversations around priorities for the next 10 days, the team worked in 2 week sprint on some stuff that didnt change. Guess what? 2 weeks later they could release some changes and make a difference for _some_ customers.

                          I promised the owner he would see his most important stuff delivered in 10 days. I sent him a photo of the scrum board each day. I promised him he could prioritise all the product backlog stuff has much as he wanted in the meantime. All he had to do was leave the team alone for 10 days.

                          Guess what? It worked. The owner was delighted with the approach and started to trust his stuff would "just get done".

                          It wasnt easy at the start though, and as mentioned involved some tough love. The key for me was I understood the owners problems/frustrations and I told him how we could remove them.

                          Loved the "tough love" post BTW.


                          --- In scrumdevelopment@yahoogroups.com, Mike Frymyer <mfrymyer@...> wrote:
                          >
                          > I am a project manager and I work for an IT department that has 5
                          > developers. Those 5 developers are working on 4 - 5 projects at any given
                          > time. They are also responsible for support and maintenance.
                          >
                          > My CIO is very frustrated with the fact that they are unable to provide goo
                          > levels of efforts for their work. This leads to late deliverables. He is
                          > also pushing us very hard toward Agile methods thinking that will fix all
                          > of our problems.
                          >
                          > A typical development timeframe for the vast majority of our products is
                          > between 40 and 400 hours. This is for .NET and Business Objects reporting.
                          >
                          > I have taken the SCRUMMaster classes and from all that I see you need to
                          > have dedicated teams to a specific work effort. This is due in large part
                          > that a developer needs to be present at all times; such as during the User
                          > Story definition and then decomposing the User Stories into more
                          > detailed requirements during the development or SPRINT.
                          >
                          > I have been trying to capture the detailed requirements for the backlog to
                          > eliminate the need tp have a developer spend time with the customer, but my
                          > boss says I am taking too long on the requirements (usually about 30 hours
                          > in as coompressed a time span as schedules will allow).
                          >
                          > I am looking for suggestions on what I may be doing wrong and how I might
                          > be able to utilize Agile without a dedicated development team to each
                          > effort.
                          >
                          > Mike
                          >
                        • Seyit Caglar Abbasoglu
                          Some interesting stuff about multi-tasking http://www.codinghorror.com/blog/2006/09/the-multi-tasking-myth.html It seems Human can not multi-task complex jobs.
                          Message 12 of 24 , Jan 26, 2012
                          • 0 Attachment
                            Some interesting stuff about multi-tasking

                            http://www.codinghorror.com/blog/2006/09/the-multi-tasking-myth.html

                            It seems Human can not multi-task complex jobs. She can only context switch, and it's really costly.

                            The last statement is pretty effective :

                            " Whenever possible, avoid interruptions and avoid working on more than one project at the same time. If it's unavoidable, be brutally honest with yourself-- and your stakeholders-- about how much you can actually get done under multi-tasking conditions. It's probably less than you think."

                            Perhaps your CIO should know about this.
                          • woynam
                            Even if you *could* multitask without any overhead cost, it would *still* wind up costing the business in lost value. Ron and several others have posted
                            Message 13 of 24 , Jan 26, 2012
                            • 0 Attachment
                              Even if you *could* multitask without any overhead cost, it would *still* wind up costing the business in lost value.

                              Ron and several others have posted examples *numerous* times that demonstrate that implementing multiple projects in parallel *guarantees* that all but one project will be delivered later than if the projects had been addressed serially.

                              A project delivered later is *lost value*. Are businesses aware of this? If not, why? You need to have a conversation with the business that clearly explains that they can have Project A in 2 weeks, or they can have it in 12 weeks. In possible world can they have 6 projects in 2 weeks, but we can certainly give them 6 projects in 12 weeks, with the corresponding loss in value.

                              Why on earth is this so difficult for people to comprehend?

                              Mark


                              --- In scrumdevelopment@yahoogroups.com, Seyit Caglar Abbasoglu <scabbasoglu@...> wrote:
                              >
                              > Some interesting stuff about multi-tasking
                              >
                              > http://www.codinghorror.com/blog/2006/09/the-multi-tasking-myth.html
                              >
                              > It seems Human can not multi-task complex jobs. She can only context
                              > switch, and it's really costly.
                              >
                              > The last statement is pretty effective :
                              >
                              > " Whenever possible, avoid interruptions and avoid working on more than one
                              > project at the same time. If it's unavoidable, *be brutally honest with
                              > yourself-- and your stakeholders-- about how much you can actually get done
                              > under multi-tasking conditions.* It's probably less than you think."
                              >
                              > Perhaps your CIO should know about this.
                              >
                            • Paul Hudson
                              ... It s a trust/confidence/risk issue. The owners feel happier seeing some progress, even if rationally they can see doing projects one at a time delivers
                              Message 14 of 24 , Jan 26, 2012
                              • 0 Attachment
                                On 26 January 2012 15:16, woynam <woyna@...> wrote:


                                Why on earth is this so difficult for people to comprehend?

                                Mark



                                It's a trust/confidence/risk issue. The owners feel happier seeing some progress, even if rationally they can see doing projects one at a time delivers things earlier.

                                Take an extreme example - 25  projects each taking one month. It takes a lot of faith in your company's systems and organisations to let 23 other projects and two years come and go before yours even starts....

                                Paul
                                 
                              • woynam
                                Sure, but it doesn t take a rocket scientist to see that if you work on the 25 projects in parallel that will *all* take over 2 years to complete.
                                Message 15 of 24 , Jan 26, 2012
                                • 0 Attachment
                                  Sure, but it doesn't take a rocket scientist to see that if you work on the 25 projects in parallel that will *all* take over 2 years to complete.

                                  Organizational politics is certainly at play. I don't care if my project takes 2 years as long as *your* project also takes 2 years.

                                  Sheesh.

                                  Mark


                                  --- In scrumdevelopment@yahoogroups.com, Paul Hudson <phudson@...> wrote:
                                  >
                                  > On 26 January 2012 15:16, woynam <woyna@...> wrote:
                                  >
                                  > > **
                                  > >
                                  > >
                                  > > Why on earth is this so difficult for people to comprehend?
                                  > >
                                  > > Mark
                                  > >
                                  > >
                                  > It's a trust/confidence/risk issue. The owners feel happier seeing some
                                  > progress, even if rationally they can see doing projects one at a time
                                  > delivers things earlier.
                                  >
                                  > Take an extreme example - 25 projects each taking one month. It takes a
                                  > lot of faith in your company's systems and organisations to let 23 other
                                  > projects and two years come and go before yours even starts....
                                  >
                                  > Paul
                                  >
                                • Ram Srinivasan
                                  ... Because it is much easier to *not* prioritize projects and features based on value, and still justify to their bosses that they are doing the right thing.
                                  Message 16 of 24 , Jan 26, 2012
                                  • 0 Attachment
                                    Why on earth is this so difficult for people to comprehend?  

                                    Because it is much easier to *not* prioritize projects and features based on value, and still justify to their bosses that they are doing the right thing. 

                                    Because it is much easier to say that the resources ( Yes, I don't like being called a resource ) are 100% utilized (or almost near 100%)  than to look into cycle times, ROI and other factors to justify only working on one project at a time. 

                                    Ram


                                    On Thu, Jan 26, 2012 at 10:16 AM, woynam <woyna@...> wrote:
                                     


                                    Even if you *could* multitask without any overhead cost, it would *still* wind up costing the business in lost value.

                                    Ron and several others have posted examples *numerous* times that demonstrate that implementing multiple projects in parallel *guarantees* that all but one project will be delivered later than if the projects had been addressed serially.

                                    A project delivered later is *lost value*. Are businesses aware of this? If not, why? You need to have a conversation with the business that clearly explains that they can have Project A in 2 weeks, or they can have it in 12 weeks. In possible world can they have 6 projects in 2 weeks, but we can certainly give them 6 projects in 12 weeks, with the corresponding loss in value.

                                    Why on earth is this so difficult for people to comprehend?

                                    Mark



                                    --- In scrumdevelopment@yahoogroups.com, Seyit Caglar Abbasoglu <scabbasoglu@...> wrote:
                                    >
                                    > Some interesting stuff about multi-tasking
                                    >
                                    > http://www.codinghorror.com/blog/2006/09/the-multi-tasking-myth.html
                                    >
                                    > It seems Human can not multi-task complex jobs. She can only context
                                    > switch, and it's really costly.
                                    >
                                    > The last statement is pretty effective :
                                    >
                                    > " Whenever possible, avoid interruptions and avoid working on more than one
                                    > project at the same time. If it's unavoidable, *be brutally honest with

                                    > yourself-- and your stakeholders-- about how much you can actually get done
                                    > under multi-tasking conditions.* It's probably less than you think."

                                    >
                                    > Perhaps your CIO should know about this.
                                    >


                                  • Paul Hudson
                                    But other projects might get cancelled, or I might get my stuff early or I might throw my toys out the pram, pull some strings, bribe the developers ... ,..
                                    Message 17 of 24 , Jan 26, 2012
                                    • 0 Attachment
                                      But other projects might get cancelled, or I might get my stuff early or I might throw my toys out the pram, pull some strings, bribe the developers :), and get my project earlier...

                                      ,.. all wishful/irrational thoughts, for sure, but politics and gut feel matter.

                                      > Organizational politics is certainly at play. I don't care if my project takes 2 years as long as *your* project also takes 2 years.

                                      It does just feel "wrong" that the other guy gets his in 1 month and I have to wait 2 years. It's reasonable and rational and best for the organisation, but I think it would take a very selfless owner to just go with it...

                                      Paul

                                      On 26 January 2012 15:52, woynam <woyna@...> wrote:
                                       


                                      Sure, but it doesn't take a rocket scientist to see that if you work on the 25 projects in parallel that will *all* take over 2 years to complete.

                                      Organizational politics is certainly at play. I don't care if my project takes 2 years as long as *your* project also takes 2 years.

                                      Sheesh.

                                      Mark

                                      --- In scrumdevelopment@yahoogroups.com, Paul Hudson <phudson@...> wrote:
                                      >
                                      > On 26 January 2012 15:16, woynam <woyna@...> wrote:
                                      >
                                      > > **


                                      > >
                                      > >
                                      > > Why on earth is this so difficult for people to comprehend?
                                      > >
                                      > > Mark
                                      > >
                                      > >
                                      > It's a trust/confidence/risk issue. The owners feel happier seeing some
                                      > progress, even if rationally they can see doing projects one at a time
                                      > delivers things earlier.
                                      >
                                      > Take an extreme example - 25 projects each taking one month. It takes a
                                      > lot of faith in your company's systems and organisations to let 23 other
                                      > projects and two years come and go before yours even starts....
                                      >
                                      > Paul
                                      >


                                    • Malcolm Anderson
                                      Why on earth is this so difficult for people to comprehend? Mark, It all comes down to Anything I Don t Understand Is Easy To Do
                                      Message 18 of 24 , Jan 26, 2012
                                      • 0 Attachment
                                        "Why on earth is this so difficult for people to comprehend? "

                                        Mark,

                                        It all comes down to "Anything I Don't Understand Is Easy To Do"
                                        http://search.dilbert.com/comic/Understand%20Easy

                                        To most managers, "Development" is a magic black box that they don't understand. 
                                        All they want is for the magic box to move faster.

                                        The trick is leading a manager type to comprehension without letting them think that you think they're an idiot.

                                        This is even trickier when you don't think they're an idiot, they'll often think you do anyway.

                                        Malcolm

                                        ps

                                        In large companies, the magic black box called "Development" includes any manager who used to be a developer, tester, or anything else remotely technical.
                                        This extends to scrum trainers and coaches.




                                        On Thu, Jan 26, 2012 at 7:16 AM, woynam <woyna@...> wrote:
                                         


                                        Even if you *could* multitask without any overhead cost, it would *still* wind up costing the business in lost value.

                                        Ron and several others have posted examples *numerous* times that demonstrate that implementing multiple projects in parallel *guarantees* that all but one project will be delivered later than if the projects had been addressed serially.

                                        A project delivered later is *lost value*. Are businesses aware of this? If not, why? You need to have a conversation with the business that clearly explains that they can have Project A in 2 weeks, or they can have it in 12 weeks. In possible world can they have 6 projects in 2 weeks, but we can certainly give them 6 projects in 12 weeks, with the corresponding loss in value.

                                        Why on earth is this so difficult for people to comprehend?

                                        Mark



                                        --- In scrumdevelopment@yahoogroups.com, Seyit Caglar Abbasoglu <scabbasoglu@...> wrote:
                                        >
                                        > Some interesting stuff about multi-tasking
                                        >
                                        > http://www.codinghorror.com/blog/2006/09/the-multi-tasking-myth.html
                                        >
                                        > It seems Human can not multi-task complex jobs. She can only context
                                        > switch, and it's really costly.
                                        >
                                        > The last statement is pretty effective :
                                        >
                                        > " Whenever possible, avoid interruptions and avoid working on more than one
                                        > project at the same time. If it's unavoidable, *be brutally honest with

                                        > yourself-- and your stakeholders-- about how much you can actually get done
                                        > under multi-tasking conditions.* It's probably less than you think."

                                        >
                                        > Perhaps your CIO should know about this.
                                        >
                                        --

                                        Malcolm Anderson
                                        Scrum Coach & Agile Engineer
                                        http://www.PragmaticAgility.com/blog

                                      • devesh.kumar@thomsonreuters.com
                                        Hi All I am looking for Webinars for which I can claim PDU for PMI-ACP. Let me know if you such webinars. Best Regards Devesh
                                        Message 19 of 24 , Jan 26, 2012
                                        • 0 Attachment

                                          Hi All

                                           

                                          I am looking for Webinars for which I can claim PDU for PMI-ACP.

                                          Let me know if you such webinars.

                                           

                                          Best Regards

                                          Devesh

                                           

                                        • Steve Ropa
                                          Malcolm, This is an awesome answer. I would also say it goes in the other direction, in that many developers seem to think that management is somehow an easy
                                          Message 20 of 24 , Jan 27, 2012
                                          • 0 Attachment

                                            Malcolm,

                                             

                                            This is an awesome answer.  I would also say it goes in the other direction, in that many developers seem to think that management is somehow an easy refuge for the semi-competent.  I have struggled for years with the culture in our world(development I mean, not just agile) that once someone becomes a manager they somehow get a lobotomy, or become power mad. 

                                             

                                            I would also say that your ps describes the toughest situation.  The manager who used to be a developer is part of the development black box to the rest of management, and part of the management black box to those in development. 

                                            From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Malcolm Anderson
                                            Sent: Thursday, January 26, 2012 3:20 PM
                                            To: scrumdevelopment@yahoogroups.com
                                            Subject: Re: [scrumdevelopment] Re: Size of team a barrier to SCRUM and Agile

                                             

                                             

                                            "Why on earth is this so difficult for people to comprehend? "

                                            Mark,

                                            It all comes down to "Anything I Don't Understand Is Easy To Do"
                                            http://search.dilbert.com/comic/Understand%20Easy

                                            To most managers, "Development" is a magic black box that they don't understand. 
                                            All they want is for the magic box to move faster.

                                            The trick is leading a manager type to comprehension without letting them think that you think they're an idiot.

                                            This is even trickier when you don't think they're an idiot, they'll often think you do anyway.

                                            Malcolm

                                            ps

                                            In large companies, the magic black box called "Development" includes any manager who used to be a developer, tester, or anything else remotely technical.
                                            This extends to scrum trainers and coaches.



                                            On Thu, Jan 26, 2012 at 7:16 AM, woynam <woyna@...> wrote:

                                             


                                            Even if you *could* multitask without any overhead cost, it would *still* wind up costing the business in lost value.

                                            Ron and several others have posted examples *numerous* times that demonstrate that implementing multiple projects in parallel *guarantees* that all but one project will be delivered later than if the projects had been addressed serially.

                                            A project delivered later is *lost value*. Are businesses aware of this? If not, why? You need to have a conversation with the business that clearly explains that they can have Project A in 2 weeks, or they can have it in 12 weeks. In possible world can they have 6 projects in 2 weeks, but we can certainly give them 6 projects in 12 weeks, with the corresponding loss in value.

                                            Why on earth is this so difficult for people to comprehend?

                                            Mark



                                            --- In scrumdevelopment@yahoogroups.com, Seyit Caglar Abbasoglu <scabbasoglu@...> wrote:
                                            >
                                            > Some interesting stuff about multi-tasking
                                            >
                                            > http://www.codinghorror.com/blog/2006/09/the-multi-tasking-myth.html
                                            >
                                            > It seems Human can not multi-task complex jobs. She can only context
                                            > switch, and it's really costly.
                                            >
                                            > The last statement is pretty effective :
                                            >
                                            > " Whenever possible, avoid interruptions and avoid working on more than one

                                            > project at the same time. If it's unavoidable, *be brutally honest with


                                            > yourself-- and your stakeholders-- about how much you can actually get done

                                            > under multi-tasking conditions.* It's probably less than you think."


                                            >
                                            > Perhaps your CIO should know about this.
                                            >

                                            --

                                            Malcolm Anderson
                                            Scrum Coach & Agile Engineer
                                            http://www.PragmaticAgility.com/blog

                                          • Malcolm Anderson
                                            Steve, Thank you, I had missed the reciprocal rejection criteria. I m working on an article about these two groups, and you just helped me understand that
                                            Message 21 of 24 , Jan 27, 2012
                                            • 0 Attachment
                                              Steve,

                                              Thank you, I had missed the reciprocal "rejection" criteria.

                                              I'm working on an article about these two groups, and you just helped me understand that there is a 3rd group that is viewed by both management and development as, "part of the other group"

                                              Brilliant

                                              Thanks

                                              Malcolm

                                               

                                              On Fri, Jan 27, 2012 at 9:20 AM, Steve Ropa <theropas@...> wrote:
                                               

                                              Malcolm,

                                               

                                              This is an awesome answer.  I would also say it goes in the other direction, in that many developers seem to think that management is somehow an easy refuge for the semi-competent.  I have struggled for years with the culture in our world(development I mean, not just agile) that once someone becomes a manager they somehow get a lobotomy, or become power mad. 

                                               

                                              I would also say that your ps describes the toughest situation.  The manager who used to be a developer is part of the development black box to the rest of management, and part of the management black box to those in development. 

                                              From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Malcolm Anderson
                                              Sent: Thursday, January 26, 2012 3:20 PM
                                              To: scrumdevelopment@yahoogroups.com
                                              Subject: Re: [scrumdevelopment] Re: Size of team a barrier to SCRUM and Agile

                                               

                                               

                                              "Why on earth is this so difficult for people to comprehend? "

                                              Mark,

                                              It all comes down to "Anything I Don't Understand Is Easy To Do"
                                              http://search.dilbert.com/comic/Understand%20Easy

                                              To most managers, "Development" is a magic black box that they don't understand. 
                                              All they want is for the magic box to move faster.

                                              The trick is leading a manager type to comprehension without letting them think that you think they're an idiot.

                                              This is even trickier when you don't think they're an idiot, they'll often think you do anyway.

                                              Malcolm

                                              ps

                                              In large companies, the magic black box called "Development" includes any manager who used to be a developer, tester, or anything else remotely technical.
                                              This extends to scrum trainers and coaches.



                                              On Thu, Jan 26, 2012 at 7:16 AM, woynam <woyna@...> wrote:

                                               


                                              Even if you *could* multitask without any overhead cost, it would *still* wind up costing the business in lost value.

                                              Ron and several others have posted examples *numerous* times that demonstrate that implementing multiple projects in parallel *guarantees* that all but one project will be delivered later than if the projects had been addressed serially.

                                              A project delivered later is *lost value*. Are businesses aware of this? If not, why? You need to have a conversation with the business that clearly explains that they can have Project A in 2 weeks, or they can have it in 12 weeks. In possible world can they have 6 projects in 2 weeks, but we can certainly give them 6 projects in 12 weeks, with the corresponding loss in value.

                                              Why on earth is this so difficult for people to comprehend?

                                              Mark



                                              --- In scrumdevelopment@yahoogroups.com, Seyit Caglar Abbasoglu <scabbasoglu@...> wrote:
                                              >
                                              > Some interesting stuff about multi-tasking
                                              >
                                              > http://www.codinghorror.com/blog/2006/09/the-multi-tasking-myth.html
                                              >
                                              > It seems Human can not multi-task complex jobs. She can only context
                                              > switch, and it's really costly.
                                              >
                                              > The last statement is pretty effective :
                                              >
                                              > " Whenever possible, avoid interruptions and avoid working on more than one

                                              > project at the same time. If it's unavoidable, *be brutally honest with


                                              > yourself-- and your stakeholders-- about how much you can actually get done

                                              > under multi-tasking conditions.* It's probably less than you think."


                                              >
                                              > Perhaps your CIO should know about this.
                                              >

                                              --

                                              Malcolm Anderson
                                              Scrum Coach & Agile Engineer
                                              http://www.PragmaticAgility.com/blog




                                              --

                                              Malcolm Anderson
                                              Scrum Coach & Agile Engineer
                                              http://www.PragmaticAgility.com/blog

                                            • Joshua Partogi
                                              Go ask in the PMI mailing list. You will get a better answer. This is a Scrum mailing list. ... -- @jpartogi
                                              Message 22 of 24 , Feb 1, 2012
                                              • 0 Attachment
                                                Go ask in the PMI mailing list. You will get a better answer. This is a Scrum mailing list.

                                                On Fri, Jan 27, 2012 at 6:00 AM, <devesh.kumar@...> wrote:
                                                 

                                                Hi All

                                                 

                                                I am looking for Webinars for which I can claim PDU for PMI-ACP.

                                                Let me know if you such webinars.

                                                 

                                                Best Regards

                                                Devesh

                                                 


                                                --
                                                @jpartogi
                                              • Ram Srinivasan
                                                You can join the agile community of practice, and look under webinar, we have a few ones there Ram
                                                Message 23 of 24 , Feb 1, 2012
                                                • 0 Attachment

                                                  You can join the agile community of practice, and look under webinar, we have a few ones there

                                                  Ram

                                                  On Feb 1, 2012 7:46 PM, "Joshua Partogi" <joshua.java@...> wrote:
                                                   

                                                  Go ask in the PMI mailing list. You will get a better answer. This is a Scrum mailing list.

                                                  On Fri, Jan 27, 2012 at 6:00 AM, <devesh.kumar@...> wrote:
                                                   

                                                  Hi All

                                                   

                                                  I am looking for Webinars for which I can claim PDU for PMI-ACP.

                                                  Let me know if you such webinars.

                                                   

                                                  Best Regards

                                                  Devesh

                                                   


                                                  --
                                                  @jpartogi
                                                • Wouter Lagerweij
                                                  Hi Ram, I ve used the Batman (we ironically called it Developer of the week ) approach. It worked well in a situation where there was a limited influx of
                                                  Message 24 of 24 , Feb 1, 2012
                                                  • 0 Attachment
                                                    Hi Ram, 

                                                    I've used the 'Batman' (we ironically called it 'Developer of the week') approach. It worked well in a situation where there was a limited influx of emergencies. 
                                                    For a situation where there were a lot of emergencies (meaning the quality level was quite low) we put together a separate team that focused only on fixing those issues, and doing structural improvements to bring the quality level up. 

                                                    'maintenance' can mean fixing defects, but to some it can also mean implementing new functionality. If there's a lot of new functionality necessary for the existing, deployed application, then even with limited defects you can still get to a situation where there's no time to work on the new product. That's OK. But as Scrum Master, in that situation it helps to make things very visible. Present a little overview of what has been worked on for different projects at each Sprint Review, for instance. Preferably with a little historical data as well. Ensure that you measure actual velocity on the 'main project', and use that for any release planning. Transparency.

                                                    Wouter

                                                    On Thu, Jan 19, 2012 at 6:29 AM, Ram Srinivasan <vasan.ram@...> wrote:
                                                     

                                                    Ron:


                                                    Great Answer. Lot of us (including me) are in the same boat as  Mike. 

                                                    Question.

                                                    How do you manage new development, along with maintaining existing application/products, especially if the team is small, given that this team has actually developed the( now deployed)  "cash cow" application. My answer is along the lines of have a batman (http://jamesshore.com/Agile-Book/iteration_planning.html ), but if there are multiple products to maintain (including hot fixes), it really becomes difficult. How do you handle such circumstances ?

                                                    Thanks,
                                                    Ram

                                                    On Wed, Jan 18, 2012 at 2:28 PM, RonJeffries <ronjeffries@...> wrote:
                                                     

                                                    Hello Mike,


                                                    It is time for some tough love here ...

                                                    On Jan 13, 2012, at 10:26 AM, Mike Frymyer wrote:

                                                    I am a project manager and I work for an IT department that has 5 developers. Those 5 developers are working on 4 - 5 projects at any given time. They are also responsible for support and maintenance.

                                                    How's that working for you? My guess: horribly. There's a reason:

                                                    Suppose each project would require five weeks. Assuming perfect task switching, your delivery plans look like this:

                                                    1234512345123451234512345SHIP

                                                    But you won't get perfect task switching. There will be overhead and mistakes. It looks more like this:

                                                    1.2.3.4.5.1.2.3.4.5.1.2.3.4.5.1.2.3.4.5.1.2.3.4.5.SxHxIxPx

                                                    If you work on one thing at a time it would look like this:
                                                    1111122222333334444455555
                                                     xxxxxSHIP  SHIP  SHIP  SHIP  SHIP
                                                     
                                                    My CIO is very frustrated with the fact that they are unable to provide goo levels of efforts for their work. This leads to late deliverables. He is also pushing us very hard toward Agile methods thinking that will fix all of our problems.

                                                    BULL. There are no late deliverables due to "inability to provide good levels of effort". There is only bad product management. The team should be assumed to be working as effectively as they can under the (let's face it, not very bright) conditions they've been put under. Once you learn to manage that flow, you can work to improve it. You do this by removing impediments, not by applying more pressure or adding in more work.

                                                    The problem of MANAGEMENT is to select work in such a way as to get the best possible product by the desired delivery date. This will be a lot easier for everyone if the team only works on one thing at a time. Since it will also have lower overhead and produce fewer errors while delivering much sooner, it only has one downside: it will require some managers to make some decisions, which by the way is their job.

                                                     
                                                    A typical development timeframe for the vast majority of our products is between 40 and 400 hours. This is for .NET and Business Objects reporting.

                                                    OK ... How do you get these numbers? Are they estimated by the sales department? By the CIO? By you? By the developers? 

                                                     
                                                    I have taken the SCRUMMaster classes and from all that I see you need to have dedicated teams to a specific work effort. This is due in large part that a developer needs to be present at all times; such as during the User Story definition and then decomposing the User Stories into more detailed requirements during the development or SPRINT.

                                                    A developer present at all times? Do you perhaps mean a Product Owner? Tell me about your Product Owners, who must be business-side people, fully empowered to decide what goes into the product, and what does not. Did you notice in your ScrumMaster training that the Product Owner is solely responsible for the delivery of the best possible product by the deadline?

                                                     
                                                    I have been trying to capture the detailed requirements for the backlog to eliminate the need tp have a developer spend time with the customer, but my boss says I am taking too long on the requirements (usually about 30 hours in as coompressed a time span as schedules will allow).

                                                    You are a project manager. This is not a Scrum role as far as I am aware. Perhaps you are trying to take on the Product Owner role? If so, have you had Product Owner training?

                                                    It also sounds to me as if no one in management is on board with doing Scrum, much less understands what it means. Am I getting the wrong impression here?

                                                     
                                                    I am looking for suggestions on what I may be doing wrong and how I might be able to utilize Agile without a dedicated development team to each effort.

                                                    If you are going to spread your teams over multiple projects, that is such a bad idea, that I implore you, as one of the authors of the Agile manifesto, to call your process anything else but not Agile.

                                                    Ron Jeffries
                                                    www.XProgramming.com
                                                    There's no word for accountability in Finnish. Accountability is something that is left when responsibility has been subtracted. 
                                                    --Pasi Sahlberg





                                                    --
                                                    Wouter Lagerweij         | wouter@...
                                                  Your message has been successfully submitted and would be delivered to recipients shortly.