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

Justify full Time Scrum Master? Need help

Expand Messages
  • ag12340@rocketmail.com
    I am new to Scrum. Attended 2 day training. my title: dev manager current process: requirements doc, arch and design, iterative and incremental dev, handoff to
    Message 1 of 16 , Nov 21, 2011
      I am new to Scrum. Attended 2 day training.

      my title: dev manager

      current process: requirements doc, arch and design, iterative and incremental dev, handoff to qa, deploy. We deploy every 3 months.

      Good things: We can go back and change requirements and design. PO and biz owner is very involved and very accessible.

      Team: Cross functional 7 devs. QA is outside.

      My boss is onboard with Scrum. He loves 300% productivity improvement scrum has many studies for and daily meetings.

      He thinks (wants) we should be able to hit 100% productivity improvement in an year (our goal for Scrum) and 40% in 6 months.

      I requested for a full time scrum master. He want justification for extra cost and wants to know why I or some PM cannot do it.

      I said my hiring a full time SM, we will be able to reduce number of developers by 2 (from 7 to 5) in an year and still get more done.

      Is that a good justification? What else can I provide?
    • Dave Rooney
      What is the reason why you think Scrum will help? Are your customers or users clamoring for more content sooner? How large is your outstanding defect list?
      Message 2 of 16 , Nov 26, 2011

        What is the reason why you think Scrum will help?  Are your customers or users clamoring for more content sooner?  How large is your outstanding defect list?

        As for productivity, how do you measure that now?  How would you know it improved?  More importantly, how would your customers/users know you improved?

        On 2011-11-26 3:52 PM, "ag12340@..." <ag12340@...> wrote:
         

        I am new to Scrum. Attended 2 day training.

        my title: dev manager

        current process: requirements doc, arch and design, iterative and incremental dev, handoff to qa, deploy. We deploy every 3 months.

        Good things: We can go back and change requirements and design. PO and biz owner is very involved and very accessible.

        Team: Cross functional 7 devs. QA is outside.

        My boss is onboard with Scrum. He loves 300% productivity improvement scrum has many studies for and daily meetings.

        He thinks (wants) we should be able to hit 100% productivity improvement in an year (our goal for Scrum) and 40% in 6 months.

        I requested for a full time scrum master. He want justification for extra cost and wants to know why I or some PM cannot do it.

        I said my hiring a full time SM, we will be able to reduce number of developers by 2 (from 7 to 5) in an year and still get more done.

        Is that a good justification? What else can I provide?

      • Laurent Bossavit
        ... You have not yet earned the right to make the kind of promises to your management that you report making. Tell yourself this: that in 2 days what you have
        Message 3 of 16 , Nov 26, 2011
          > I am new to Scrum. Attended 2 day training.
          >

          You have not yet earned the right to make the kind of promises to your
          management that you report making.

          Tell yourself this: that in 2 days what you have learned is close to
          nothing; even though you may feel that you learned more in these 2
          days than in all the training you attended before. (The two statements
          are not mutually exclusive.)

          You are hearing contradictory messages from your boss: "onboard with
          Scrum" says one thing, "want justification for extra cost" says the
          opposite. My advice is to first try to resolve such contradictions.

          Do not expect *any* performance improvements in the first year: it is
          possible that you will achieve them, but you have no good reason at
          this time to expect them.

          Performance improvements come from learning, and learning is not a
          predictable phenomenon.

          Focus on learning at first. Improvement will follow, later; insisting
          on improved performance right away will kill learning. In fact, you
          should expect a temporary *decrease* in performance initially:
          learning puts people off-balance.

          Learning is (to a good approximation) finding the questions to ask,
          and finding the answers.

          Start with the question: why?

          Why does your boss want 100% productivity improvement? What will he do
          with it? What if other parts of your organization, including the parts
          that are outside, cannot keep up with an increase in productivity? How
          will an outside QA respond to internal changes?

          Why do you think you need a full time Scrum Master? How do you think
          that having one will change things in your team? *Precisely* what do
          you envision happening as a result of having this role filled?

          Why does your boss think it's unnecessary? What is the worst that will
          happen if you do not have a full time Scrum Master? How long would it
          take you to find a competent Scrum Master? (A good rule of thumb, in
          my experience, is three to six months.) Is there anything important
          that you could do while you are waiting to hire one?

          Cheers,
          Laurent
        • ag12340@rocketmail.com
          ... No. They are ok with 3 months deploy cycle. We do deploy urgent (fast track) requests sooner than 3 months. I am sure once we deliver sooner with Scrum
          Message 4 of 16 , Nov 26, 2011
            >Are your customers or users clamoring for more content sooner?

            No. They are ok with 3 months deploy cycle. We do deploy urgent (fast track) requests sooner than 3 months. I am sure once we deliver sooner with Scrum they would love it.

            >How large is your outstanding defect list?

            Actually quite small. We have very experienced team. Quality and technical debt is not an issue at this point.

            That is actually one of my concerns with Scrum as I heard that with Scrum technical debt increases and quality falls. I am assuming those are experiences of bad teams.

            > As for productivity, how do you measure that now? How would you know it
            > improved? More importantly, how would your customers/users know you
            > improved?
            Good question. We do not measure it now. We plan to use velocity to measure it once we start doing scrum. I was hoping Scrum Master would help me answer some of these questions.



            --- In scrumdevelopment@yahoogroups.com, Dave Rooney <daverooneyca@...> wrote:
            >
            > What is the reason why you think Scrum will help? Are your customers or
            > users clamoring for more content sooner? How large is your outstanding
            > defect list?
            >
            > As for productivity, how do you measure that now? How would you know it
            > improved? More importantly, how would your customers/users know you
            > improved?
            > On 2011-11-26 3:52 PM, "ag12340@..." <ag12340@...>
            > wrote:
            >
            > > **
            > >
            > >
            > > I am new to Scrum. Attended 2 day training.
            > >
            > > my title: dev manager
            > >
            > > current process: requirements doc, arch and design, iterative and
            > > incremental dev, handoff to qa, deploy. We deploy every 3 months.
            > >
            > > Good things: We can go back and change requirements and design. PO and biz
            > > owner is very involved and very accessible.
            > >
            > > Team: Cross functional 7 devs. QA is outside.
            > >
            > > My boss is onboard with Scrum. He loves 300% productivity improvement
            > > scrum has many studies for and daily meetings.
            > >
            > > He thinks (wants) we should be able to hit 100% productivity improvement
            > > in an year (our goal for Scrum) and 40% in 6 months.
            > >
            > > I requested for a full time scrum master. He want justification for extra
            > > cost and wants to know why I or some PM cannot do it.
            > >
            > > I said my hiring a full time SM, we will be able to reduce number of
            > > developers by 2 (from 7 to 5) in an year and still get more done.
            > >
            > > Is that a good justification? What else can I provide?
            > >
            > >
            > >
            >
          • ag12340@rocketmail.com
            What is the worst that will ... A lot of very good questions for me to think about. I attended couple of agile conferences and user groups and there were quite
            Message 5 of 16 , Nov 26, 2011
              What is the worst that will
              > happen if you do not have a full time Scrum Master? How long would it
              > take you to find a competent Scrum Master? (A good rule of thumb, in
              > my experience, is three to six months.) Is there anything important
              > that you could do while you are waiting to hire one?

              A lot of very good questions for me to think about.

              I attended couple of agile conferences and user groups and there were quite a few Scrum master and coaches looking for work. So I guess there is no shortage. Having said that, I still have to define what kind of SM I want to hire. I am thinking of 3-4 yr experienced SM who can code with team as well.



              --- In scrumdevelopment@yahoogroups.com, Laurent Bossavit <lolists@...> wrote:
              >
              > > I am new to Scrum. Attended 2 day training.
              > >
              >
              > You have not yet earned the right to make the kind of promises to your
              > management that you report making.
              >
              > Tell yourself this: that in 2 days what you have learned is close to
              > nothing; even though you may feel that you learned more in these 2
              > days than in all the training you attended before. (The two statements
              > are not mutually exclusive.)
              >
              > You are hearing contradictory messages from your boss: "onboard with
              > Scrum" says one thing, "want justification for extra cost" says the
              > opposite. My advice is to first try to resolve such contradictions.
              >
              > Do not expect *any* performance improvements in the first year: it is
              > possible that you will achieve them, but you have no good reason at
              > this time to expect them.
              >
              > Performance improvements come from learning, and learning is not a
              > predictable phenomenon.
              >
              > Focus on learning at first. Improvement will follow, later; insisting
              > on improved performance right away will kill learning. In fact, you
              > should expect a temporary *decrease* in performance initially:
              > learning puts people off-balance.
              >
              > Learning is (to a good approximation) finding the questions to ask,
              > and finding the answers.
              >
              > Start with the question: why?
              >
              > Why does your boss want 100% productivity improvement? What will he do
              > with it? What if other parts of your organization, including the parts
              > that are outside, cannot keep up with an increase in productivity? How
              > will an outside QA respond to internal changes?
              >
              > Why do you think you need a full time Scrum Master? How do you think
              > that having one will change things in your team? *Precisely* what do
              > you envision happening as a result of having this role filled?
              >
              > Why does your boss think it's unnecessary? What is the worst that will
              > happen if you do not have a full time Scrum Master? How long would it
              > take you to find a competent Scrum Master? (A good rule of thumb, in
              > my experience, is three to six months.) Is there anything important
              > that you could do while you are waiting to hire one?
              >
              > Cheers,
              > Laurent
              >
            • Mark Levison
              ... Hmm how are you measuring Technical Debt? I don t know of any perfect way but I also know that unless I m unless I m using some tool (ex Sonar) I don t
              Message 6 of 16 , Dec 1 11:54 AM
                Actually quite small. We have very experienced team. Quality and technical debt is not an issue at this point.

                Hmm how are you measuring Technical Debt? I don't know of any perfect way but I also know that unless I'm unless I'm using some tool (ex Sonar) I don't that I ever have a good idea. BTW No tool is perfect, Sonar has its flaws but without any measurement all you have is conjecture.


                That is actually one of my concerns with Scrum as I heard that with Scrum technical debt increases and quality falls. I am assuming those are experiences of bad teams.

                I suspect that has alot to do with maturity, engineering practices and how much they focus on improvement. A team without any engineering practices starting Scrum will pile on the technical debt. A team that uses TDD/BDD/ATDD/flavour of the week - will likely do better. Any team that really uses retrospectives will improve. The kicker is that retrospectives are often done poorly.

                Cheers
                Mark Levison



                > As for productivity, how do you measure that now? How would you know it
                > improved? More importantly, how would your customers/users know you
                > improved?
                Good question. We do not measure it now. We plan to use velocity to measure it once we start doing scrum. I was hoping Scrum Master would help me answer some of these questions.


                --- In scrumdevelopment@yahoogroups.com, Dave Rooney <daverooneyca@...> wrote:
                >
                > What is the reason why you think Scrum will help? Are your customers or
                > users clamoring for more content sooner? How large is your outstanding
                > defect list?
                >
                > As for productivity, how do you measure that now? How would you know it
                > improved? More importantly, how would your customers/users know you
                > improved?
                > On 2011-11-26 3:52 PM, "ag12340@..." <ag12340@...>
                > wrote:
                >
                > > **

                > >
                > >
                > > I am new to Scrum. Attended 2 day training.
                > >
                > > my title: dev manager
                > >
                > > current process: requirements doc, arch and design, iterative and
                > > incremental dev, handoff to qa, deploy. We deploy every 3 months.
                > >
                > > Good things: We can go back and change requirements and design. PO and biz
                > > owner is very involved and very accessible.
                > >
                > > Team: Cross functional 7 devs. QA is outside.
                > >
                > > My boss is onboard with Scrum. He loves 300% productivity improvement
                > > scrum has many studies for and daily meetings.
                > >
                > > He thinks (wants) we should be able to hit 100% productivity improvement
                > > in an year (our goal for Scrum) and 40% in 6 months.
                > >
                > > I requested for a full time scrum master. He want justification for extra
                > > cost and wants to know why I or some PM cannot do it.
                > >
                > > I said my hiring a full time SM, we will be able to reduce number of
                > > developers by 2 (from 7 to 5) in an year and still get more done.
                > >
                > > Is that a good justification? What else can I provide?
                > >
                > >
                > >
                >


              • Pierre Neis
                This is 1 scenario. Here another: If you re focus on delivery done increments, tech debts are managed as constraints and blocking points. So you have to keep
                Message 7 of 16 , Dec 1 1:41 PM
                  This is 1 scenario.

                  Here another:

                  If you're focus on delivery done increments, tech debts are managed as constraints and blocking points. 
                  So you have to keep balance with reduce this Tech Debt and release Done increments.

                  There, I use a trick:
                  • monthly deliveries
                  • 2 week sprints: the first delivers features and the 2d fix the debt 
                  • always start the project in a clean space
                  • Debt must be fixed at 1st release: no procrastination accepted (Scrum Master plays SM Angel!!)
                  Concerning "Justify Scrum Master"
                  • in a small project with no interdependencies : (s)he makes coordination
                  • in a huge project: (s)he must play the backup for the Product Owner and coach all Project Stakeholders
                  • + I coach my Scrum Masters by improving the BPM process: at Retrospective, the Development Team leaves a feedback on the improved initial BPM (part of DoD) --> working on government projects!!!
                   

                  Pierre E.  NEIScsp

                  Head of Lean Competence Centre @ coPROcess S.A. 
                  │ Scrum & Lean Coach   

                  M: +352 / 661 727 867  - Skype: pierre.neis  
                  Meet with me: http://meetwith.me/pierreneis



                   

                  TwitterLatest tweet: a Daily NEIS's world! is out! http://t.co/YpLxwEdT ▸ Top stories today via @toile_filante @agiletd @agile_exec @userfocus @gapingvoidart Follow @elPedroMajor Reply Retweet   13:34 Dec-01


                  On 1 December 2011 20:54, Mark Levison <mark@...> wrote:
                   


                  Actually quite small. We have very experienced team. Quality and technical debt is not an issue at this point.

                  Hmm how are you measuring Technical Debt? I don't know of any perfect way but I also know that unless I'm unless I'm using some tool (ex Sonar) I don't that I ever have a good idea. BTW No tool is perfect, Sonar has its flaws but without any measurement all you have is conjecture.


                  That is actually one of my concerns with Scrum as I heard that with Scrum technical debt increases and quality falls. I am assuming those are experiences of bad teams.

                  I suspect that has alot to do with maturity, engineering practices and how much they focus on improvement. A team without any engineering practices starting Scrum will pile on the technical debt. A team that uses TDD/BDD/ATDD/flavour of the week - will likely do better. Any team that really uses retrospectives will improve. The kicker is that retrospectives are often done poorly.

                  Cheers
                  Mark Levison



                  > As for productivity, how do you measure that now? How would you know it
                  > improved? More importantly, how would your customers/users know you
                  > improved?
                  Good question. We do not measure it now. We plan to use velocity to measure it once we start doing scrum. I was hoping Scrum Master would help me answer some of these questions.


                  --- In scrumdevelopment@yahoogroups.com, Dave Rooney <daverooneyca@...> wrote:
                  >
                  > What is the reason why you think Scrum will help? Are your customers or
                  > users clamoring for more content sooner? How large is your outstanding
                  > defect list?
                  >
                  > As for productivity, how do you measure that now? How would you know it
                  > improved? More importantly, how would your customers/users know you
                  > improved?
                  > On 2011-11-26 3:52 PM, "ag12340@..." <ag12340@...>
                  > wrote:
                  >
                  > > **

                  > >
                  > >
                  > > I am new to Scrum. Attended 2 day training.
                  > >
                  > > my title: dev manager
                  > >
                  > > current process: requirements doc, arch and design, iterative and
                  > > incremental dev, handoff to qa, deploy. We deploy every 3 months.
                  > >
                  > > Good things: We can go back and change requirements and design. PO and biz
                  > > owner is very involved and very accessible.
                  > >
                  > > Team: Cross functional 7 devs. QA is outside.
                  > >
                  > > My boss is onboard with Scrum. He loves 300% productivity improvement
                  > > scrum has many studies for and daily meetings.
                  > >
                  > > He thinks (wants) we should be able to hit 100% productivity improvement
                  > > in an year (our goal for Scrum) and 40% in 6 months.
                  > >
                  > > I requested for a full time scrum master. He want justification for extra
                  > > cost and wants to know why I or some PM cannot do it.
                  > >
                  > > I said my hiring a full time SM, we will be able to reduce number of
                  > > developers by 2 (from 7 to 5) in an year and still get more done.
                  > >
                  > > Is that a good justification? What else can I provide?
                  > >
                  > >
                  > >
                  >



                • ag12340@rocketmail.com
                  Thank you all, I talked to many people who are doing Scrum in the field. Following comes out recommended practice so far. I have decided to make my Tech Lead
                  Message 8 of 16 , Dec 1 3:11 PM
                    Thank you all,

                    I talked to many people who are doing Scrum in the field. Following comes out recommended practice so far.

                    I have decided to make my Tech Lead as "Scrum Master". We will get an experienced coach to watch us and help us out initially (first few sprints). I am dev manager.

                    1) Part 1 of planning meeting - PO will lead. I will attend. PO discusses backlog here.

                    2) Tech lead will lead part 2 of planning meeting where team decides how much they can do. I will not attend this part of meeting. PO will attend.

                    3) Tech lead will lead daily meetings. Any technical impediments he will resolve with team, others he will escalate to me. I will occasionally attend this meeting to make sure team is working together properly.

                    4) Retrospective - I will lead. Coach will help here initially.

                    I will work with stake holders and minimize any distractions to team and keep making sure team dynamics is good. I will also work with tech lead and team to make sure we are improving and implementing suggestions from retrospective.

                    We will go with this approach and improve, adapt and innovate as we go on.


                    --- In scrumdevelopment@yahoogroups.com, Pierre Neis <pierreneis@...> wrote:
                    >
                    > This is 1 scenario.
                    >
                    > Here another:
                    >
                    > If you're focus on delivery done increments, tech debts are managed as
                    > constraints and blocking points.
                    > So you have to keep balance with reduce this Tech Debt and release Done
                    > increments.
                    >
                    > There, I use a trick:
                    >
                    > - monthly deliveries
                    > - 2 week sprints: the first delivers features and the 2d fix the debt
                    > - always start the project in a clean space
                    > - Debt must be fixed at 1st release: no procrastination accepted (Scrum
                    > Master plays SM Angel!!)
                    >
                    > Concerning "Justify Scrum Master"
                    >
                    > - in a small project with no interdependencies : (s)he makes coordination
                    > - in a huge project: (s)he must play the backup for the Product Owner
                    > and coach all Project Stakeholders
                    > - + I coach my Scrum Masters by improving the BPM process: at
                    > Retrospective, the Development Team leaves a feedback on the improved
                    > initial BPM (part of DoD) --> working on government projects!!!
                    >
                    >
                    >
                    > *Pierre E. NEIS*, *csp*
                    >
                    > *Head of Lean Competence Centre @ coPROcess S.A. **â"‚ Scrum & Lean Coach *
                    >
                    > *M*: +352 / 661 727 867 - *Skype*: pierre.neis
                    > *Meet with* me: http://meetwith.me/pierreneis
                    >
                    > *
                    > *
                    >
                    > “"If you think you know everything about baseball, your dead wrong!" -
                    > Julian "JUNEBUG"
                    > Bussells<http://www.quotesdaddy.com/quote/1392067/julian-junebug-bussells/if-you-think-you-know-everything-about-baseball-your>
                    > ” Get this email app!
                    > <http://www.wisestamp.com/apps/quotes?utm_source=extension&utm_medium=email&utm_term=quotes&utm_campaign=apps>
                    >
                    > [image: Twitter] <http://twitter.com/elPedroMajor>Latest tweet: a Daily
                    > NEIS's world! is out! http://t.co/YpLxwEdT ▸ Top stories today via
                    > @toile_filante @agiletd @agile_exec @userfocus @gapingvoidart Follow
                    > @elPedroMajor <http://twitter.com/elPedroMajor> Reply
                    > <http://twitter.com/?status=@elPedroMajor%20&in_reply_to_status_id=142220090568491000&in_reply_to=elPedroMajor>
                    > Retweet
                    > <http://twitter.com/?status=RT%20%40elPedroMajor%3A%20a%20Daily%20NEIS's%20world!%20is%20out!%20http%3A%2F%2Ft.co%2FYpLxwEdT%20%E2%96%B8%20Top%20stories%20today%20via%20%40toile_filante%20%40agiletd%20%40agile_exec%20%40userfocus%20%40gapingvoidart>
                    > 13:34 Dec-01<http://twitter.com/elPedroMajor/statuses/142220090568491008>
                    > Get a signature like this.
                    > <http://r1.wisestamp.com/r/landing?promo=17&dest=http%3A%2F%2Fwww.wisestamp.com%2Femail-install%3Futm_source%3Dextension%26utm_medium%3Demail%26utm_campaign%3Dpromo_17>
                    > CLICK
                    > HERE.<http://r1.wisestamp.com/r/landing?promo=17&dest=http%3A%2F%2Fwww.wisestamp.com%2Femail-install%3Futm_source%3Dextension%26utm_medium%3Demail%26utm_campaign%3Dpromo_17>
                    >
                    >
                    >
                    > On 1 December 2011 20:54, Mark Levison <mark@...> wrote:
                    >
                    > > **
                    > >
                    > >
                    > >
                    > > Actually quite small. We have very experienced team. Quality and technical
                    > >> debt is not an issue at this point.
                    > >>
                    > >
                    > > Hmm how are you measuring Technical Debt? I don't know of any perfect way
                    > > but I also know that unless I'm unless I'm using some tool (ex Sonar) I
                    > > don't that I ever have a good idea. BTW No tool is perfect, Sonar has its
                    > > flaws but without any measurement all you have is conjecture.
                    > >
                    > >
                    > >> That is actually one of my concerns with Scrum as I heard that with Scrum
                    > >> technical debt increases and quality falls. I am assuming those are
                    > >> experiences of bad teams.
                    > >>
                    > >
                    > > I suspect that has alot to do with maturity, engineering practices and how
                    > > much they focus on improvement. A team without any engineering practices
                    > > starting Scrum will pile on the technical debt. A team that uses
                    > > TDD/BDD/ATDD/flavour of the week - will likely do better. Any team that
                    > > really uses retrospectives will improve. The kicker is that retrospectives
                    > > are often done poorly.
                    > >
                    > > Cheers
                    > > Mark Levison
                    > >
                    > >
                    > >>
                    > >> > As for productivity, how do you measure that now? How would you know it
                    > >> > improved? More importantly, how would your customers/users know you
                    > >> > improved?
                    > >> Good question. We do not measure it now. We plan to use velocity to
                    > >> measure it once we start doing scrum. I was hoping Scrum Master would help
                    > >> me answer some of these questions.
                    > >>
                    > >>
                    > >> --- In scrumdevelopment@yahoogroups.com, Dave Rooney <daverooneyca@>
                    > >> wrote:
                    > >> >
                    > >> > What is the reason why you think Scrum will help? Are your customers or
                    > >> > users clamoring for more content sooner? How large is your outstanding
                    > >> > defect list?
                    > >> >
                    > >> > As for productivity, how do you measure that now? How would you know it
                    > >> > improved? More importantly, how would your customers/users know you
                    > >> > improved?
                    > >> > On 2011-11-26 3:52 PM, "ag12340@" <ag12340@>
                    > >> > wrote:
                    > >> >
                    > >> > > **
                    > >>
                    > >> > >
                    > >> > >
                    > >> > > I am new to Scrum. Attended 2 day training.
                    > >> > >
                    > >> > > my title: dev manager
                    > >> > >
                    > >> > > current process: requirements doc, arch and design, iterative and
                    > >> > > incremental dev, handoff to qa, deploy. We deploy every 3 months.
                    > >> > >
                    > >> > > Good things: We can go back and change requirements and design. PO
                    > >> and biz
                    > >> > > owner is very involved and very accessible.
                    > >> > >
                    > >> > > Team: Cross functional 7 devs. QA is outside.
                    > >> > >
                    > >> > > My boss is onboard with Scrum. He loves 300% productivity improvement
                    > >> > > scrum has many studies for and daily meetings.
                    > >> > >
                    > >> > > He thinks (wants) we should be able to hit 100% productivity
                    > >> improvement
                    > >> > > in an year (our goal for Scrum) and 40% in 6 months.
                    > >> > >
                    > >> > > I requested for a full time scrum master. He want justification for
                    > >> extra
                    > >> > > cost and wants to know why I or some PM cannot do it.
                    > >> > >
                    > >> > > I said my hiring a full time SM, we will be able to reduce number of
                    > >> > > developers by 2 (from 7 to 5) in an year and still get more done.
                    > >> > >
                    > >> > > Is that a good justification? What else can I provide?
                    > >> > >
                    > >> > >
                    > >> > >
                    > >> >
                    > >>
                    > >>
                    > >
                    > >
                    >
                  • Mark Levison
                    I m troubled. I m sure you are an excellent manager but I m not sure if you really understand Scrum. First you keep on using the word lead to describe the
                    Message 9 of 16 , Dec 1 4:17 PM

                      I'm troubled. I'm sure you are an excellent manager but I'm not sure if you really understand Scrum. First you keep on using the word lead to describe the meetings are run. Facilitate is a much better word it makes out clear that you have a self organizing team. Second you seem to think that it's ok to rotate facilitation with out having any effect on the team. Self organizing teams are hard to nurture, your language doesn't make it clear that you recognize that. Help me see my mistake. Help me see that you understand Scrum deeply and that you recognize the tradeoffs you're making.

                      Cheers
                      Mark - on a phone

                      On Dec 1, 2011 6:12 PM, "ag12340@..." <ag12340@...> wrote:
                       

                      Thank you all,

                      I talked to many people who are doing Scrum in the field. Following comes out recommended practice so far.

                      I have decided to make my Tech Lead as "Scrum Master". We will get an experienced coach to watch us and help us out initially (first few sprints). I am dev manager.

                      1) Part 1 of planning meeting - PO will lead. I will attend. PO discusses backlog here.

                      2) Tech lead will lead part 2 of planning meeting where team decides how much they can do. I will not attend this part of meeting. PO will attend.

                      3) Tech lead will lead daily meetings. Any technical impediments he will resolve with team, others he will escalate to me. I will occasionally attend this meeting to make sure team is working together properly.

                      4) Retrospective - I will lead. Coach will help here initially.

                      I will work with stake holders and minimize any distractions to team and keep making sure team dynamics is good. I will also work with tech lead and team to make sure we are improving and implementing suggestions from retrospective.

                      We will go with this approach and improve, adapt and innovate as we go on.

                      --- In scrumdevelopment@yahoogroups.com, Pierre Neis <pierreneis@...> wrote:
                      >
                      > This is 1 scenario.
                      >
                      > Here another:
                      >
                      > If you're focus on delivery done increments, tech debts are managed as
                      > constraints and blocking points.
                      > So you have to keep balance with reduce this Tech Debt and release Done
                      > increments.
                      >
                      > There, I use a trick:
                      >
                      > - monthly deliveries
                      > - 2 week sprints: the first delivers features and the 2d fix the debt
                      > - always start the project in a clean space
                      > - Debt must be fixed at 1st release: no procrastination accepted (Scrum
                      > Master plays SM Angel!!)
                      >
                      > Concerning "Justify Scrum Master"
                      >
                      > - in a small project with no interdependencies : (s)he makes coordination
                      > - in a huge project: (s)he must play the backup for the Product Owner
                      > and coach all Project Stakeholders
                      > - + I coach my Scrum Masters by improving the BPM process: at
                      > Retrospective, the Development Team leaves a feedback on the improved
                      > initial BPM (part of DoD) --> working on government projects!!!
                      >
                      >
                      >
                      > *Pierre E. NEIS*, *csp*
                      >
                      > *Head of Lean Competence Centre @ coPROcess S.A. **â"‚ Scrum & Lean Coach *
                      >
                      > *M*: +352 / 661 727 867 - *Skype*: pierre.neis
                      > *Meet with* me: http://meetwith.me/pierreneis
                      >
                      > *
                      > *
                      >
                      > “"If you think you know everything about baseball, your dead wrong!" -
                      > Julian "JUNEBUG"
                      > Bussells<http://www.quotesdaddy.com/quote/1392067/julian-junebug-bussells/if-you-think-you-know-everything-about-baseball-your>
                      > †Get this email app!
                      > <http://www.wisestamp.com/apps/quotes?utm_source=extension&utm_medium=email&utm_term=quotes&utm_campaign=apps>
                      >
                      > [image: Twitter] <http://twitter.com/elPedroMajor>Latest tweet: a Daily
                      > NEIS's world! is out! http://t.co/YpLxwEdT â–¸ Top stories today via
                      > @toile_filante @agiletd @agile_exec @userfocus @gapingvoidart Follow
                      > @elPedroMajor <http://twitter.com/elPedroMajor> Reply
                      > <http://twitter.com/?status=@elPedroMajor%20&in_reply_to_status_id=142220090568491000&in_reply_to=elPedroMajor>
                      > Retweet
                      > <http://twitter.com/?status=RT%20%40elPedroMajor%3A%20a%20Daily%20NEIS's%20world!%20is%20out!%20http%3A%2F%2Ft.co%2FYpLxwEdT%20%E2%96%B8%20Top%20stories%20today%20via%20%40toile_filante%20%40agiletd%20%40agile_exec%20%40userfocus%20%40gapingvoidart>
                      > 13:34 Dec-01<http://twitter.com/elPedroMajor/statuses/142220090568491008>
                      > Get a signature like this.
                      > <http://r1.wisestamp.com/r/landing?promo=17&dest=http%3A%2F%2Fwww.wisestamp.com%2Femail-install%3Futm_source%3Dextension%26utm_medium%3Demail%26utm_campaign%3Dpromo_17>
                      > CLICK
                      > HERE.<http://r1.wisestamp.com/r/landing?promo=17&dest=http%3A%2F%2Fwww.wisestamp.com%2Femail-install%3Futm_source%3Dextension%26utm_medium%3Demail%26utm_campaign%3Dpromo_17>
                      >
                      >
                      >
                      > On 1 December 2011 20:54, Mark Levison <mark@...> wrote:
                      >
                      > > **
                      > >
                      > >
                      > >
                      > > Actually quite small. We have very experienced team. Quality and technical
                      > >> debt is not an issue at this point.
                      > >>
                      > >
                      > > Hmm how are you measuring Technical Debt? I don't know of any perfect way
                      > > but I also know that unless I'm unless I'm using some tool (ex Sonar) I
                      > > don't that I ever have a good idea. BTW No tool is perfect, Sonar has its
                      > > flaws but without any measurement all you have is conjecture.
                      > >
                      > >
                      > >> That is actually one of my concerns with Scrum as I heard that with Scrum
                      > >> technical debt increases and quality falls. I am assuming those are
                      > >> experiences of bad teams.
                      > >>
                      > >
                      > > I suspect that has alot to do with maturity, engineering practices and how
                      > > much they focus on improvement. A team without any engineering practices
                      > > starting Scrum will pile on the technical debt. A team that uses
                      > > TDD/BDD/ATDD/flavour of the week - will likely do better. Any team that
                      > > really uses retrospectives will improve. The kicker is that retrospectives
                      > > are often done poorly.
                      > >
                      > > Cheers
                      > > Mark Levison
                      > >
                      > >
                      > >>
                      > >> > As for productivity, how do you measure that now? How would you know it
                      > >> > improved? More importantly, how would your customers/users know you
                      > >> > improved?
                      > >> Good question. We do not measure it now. We plan to use velocity to
                      > >> measure it once we start doing scrum. I was hoping Scrum Master would help
                      > >> me answer some of these questions.
                      > >>
                      > >>
                      > >> --- In scrumdevelopment@yahoogroups.com, Dave Rooney <daverooneyca@>
                      > >> wrote:
                      > >> >
                      > >> > What is the reason why you think Scrum will help? Are your customers or
                      > >> > users clamoring for more content sooner? How large is your outstanding
                      > >> > defect list?
                      > >> >
                      > >> > As for productivity, how do you measure that now? How would you know it
                      > >> > improved? More importantly, how would your customers/users know you
                      > >> > improved?
                      > >> > On 2011-11-26 3:52 PM, "ag12340@" <ag12340@>
                      > >> > wrote:
                      > >> >
                      > >> > > **
                      > >>
                      > >> > >
                      > >> > >
                      > >> > > I am new to Scrum. Attended 2 day training.
                      > >> > >
                      > >> > > my title: dev manager
                      > >> > >
                      > >> > > current process: requirements doc, arch and design, iterative and
                      > >> > > incremental dev, handoff to qa, deploy. We deploy every 3 months.
                      > >> > >
                      > >> > > Good things: We can go back and change requirements and design. PO
                      > >> and biz
                      > >> > > owner is very involved and very accessible.
                      > >> > >
                      > >> > > Team: Cross functional 7 devs. QA is outside.
                      > >> > >
                      > >> > > My boss is onboard with Scrum. He loves 300% productivity improvement
                      > >> > > scrum has many studies for and daily meetings.
                      > >> > >
                      > >> > > He thinks (wants) we should be able to hit 100% productivity
                      > >> improvement
                      > >> > > in an year (our goal for Scrum) and 40% in 6 months.
                      > >> > >
                      > >> > > I requested for a full time scrum master. He want justification for
                      > >> extra
                      > >> > > cost and wants to know why I or some PM cannot do it.
                      > >> > >
                      > >> > > I said my hiring a full time SM, we will be able to reduce number of
                      > >> > > developers by 2 (from 7 to 5) in an year and still get more done.
                      > >> > >
                      > >> > > Is that a good justification? What else can I provide?
                      > >> > >
                      > >> > >
                      > >> > >
                      > >> >
                      > >>
                      > >>
                      > >
                      > >
                      >

                    • ag12340@rocketmail.com
                      ... I agree facilitate meeting is better word. I will start using it and bring it in my thinking and others thinking. Thanks ... Yes, It is OK. It is not
                      Message 10 of 16 , Dec 1 4:46 PM
                        >> First you keep on using the word lead to describe the meetings are run. Facilitate is a much better word

                        I agree facilitate meeting is better word. I will start using it and bring it in my thinking and others thinking. Thanks

                        >>Second you seem to think that it's ok
                        > to rotate facilitation with out having any effect on the team.

                        Yes, It is OK. It is not important who is facilitating the meeting till they are facilitating. XP did rotation.


                        >> Self organizing teams are hard to nurture,

                        I disagree. Self organizing seems to me the natural state in knowledge worker economy. Thats what you get by default. Command and control is very hard to nurture because it is not natural for knowledge workers and there is lots of resistance.


                        --- In scrumdevelopment@yahoogroups.com, Mark Levison <mark@...> wrote:
                        >
                        > I'm troubled. I'm sure you are an excellent manager but I'm not sure if you
                        > really understand Scrum. First you keep on using the word lead to describe
                        > the meetings are run. Facilitate is a much better word it makes out clear
                        > that you have a self organizing team. Second you seem to think that it's ok
                        > to rotate facilitation with out having any effect on the team. Self
                        > organizing teams are hard to nurture, your language doesn't make it clear
                        > that you recognize that. Help me see my mistake. Help me see that you
                        > understand Scrum deeply and that you recognize the tradeoffs you're making.
                        >
                        > Cheers
                        > Mark - on a phone
                        > On Dec 1, 2011 6:12 PM, "ag12340@..." <ag12340@...>
                        > wrote:
                        >
                        > > **
                        > >
                        > >
                        > > Thank you all,
                        > >
                        > > I talked to many people who are doing Scrum in the field. Following comes
                        > > out recommended practice so far.
                        > >
                        > > I have decided to make my Tech Lead as "Scrum Master". We will get an
                        > > experienced coach to watch us and help us out initially (first few
                        > > sprints). I am dev manager.
                        > >
                        > > 1) Part 1 of planning meeting - PO will lead. I will attend. PO discusses
                        > > backlog here.
                        > >
                        > > 2) Tech lead will lead part 2 of planning meeting where team decides how
                        > > much they can do. I will not attend this part of meeting. PO will attend.
                        > >
                        > > 3) Tech lead will lead daily meetings. Any technical impediments he will
                        > > resolve with team, others he will escalate to me. I will occasionally
                        > > attend this meeting to make sure team is working together properly.
                        > >
                        > > 4) Retrospective - I will lead. Coach will help here initially.
                        > >
                        > > I will work with stake holders and minimize any distractions to team and
                        > > keep making sure team dynamics is good. I will also work with tech lead and
                        > > team to make sure we are improving and implementing suggestions from
                        > > retrospective.
                        > >
                        > > We will go with this approach and improve, adapt and innovate as we go on.
                        > >
                        > > --- In scrumdevelopment@yahoogroups.com, Pierre Neis <pierreneis@>
                        > > wrote:
                        > > >
                        > > > This is 1 scenario.
                        > > >
                        > > > Here another:
                        > > >
                        > > > If you're focus on delivery done increments, tech debts are managed as
                        > > > constraints and blocking points.
                        > > > So you have to keep balance with reduce this Tech Debt and release Done
                        > > > increments.
                        > > >
                        > > > There, I use a trick:
                        > > >
                        > > > - monthly deliveries
                        > > > - 2 week sprints: the first delivers features and the 2d fix the debt
                        > > > - always start the project in a clean space
                        > > > - Debt must be fixed at 1st release: no procrastination accepted (Scrum
                        > > > Master plays SM Angel!!)
                        > > >
                        > > > Concerning "Justify Scrum Master"
                        > > >
                        > > > - in a small project with no interdependencies : (s)he makes coordination
                        > > > - in a huge project: (s)he must play the backup for the Product Owner
                        > > > and coach all Project Stakeholders
                        > > > - + I coach my Scrum Masters by improving the BPM process: at
                        > > > Retrospective, the Development Team leaves a feedback on the improved
                        > > > initial BPM (part of DoD) --> working on government projects!!!
                        > > >
                        > > >
                        > > >
                        > > > *Pierre E. NEIS*, *csp*
                        > > >
                        > > > *Head of Lean Competence Centre @ coPROcess S.A. **â"‚ Scrum & Lean
                        > > Coach *
                        > > >
                        > > > *M*: +352 / 661 727 867 - *Skype*: pierre.neis
                        > > > *Meet with* me: http://meetwith.me/pierreneis
                        > > >
                        > > > *
                        > > > *
                        > > >
                        > > > “"If you think you know everything about baseball, your dead wrong!" -
                        > > > Julian "JUNEBUG"
                        > > > Bussells<
                        > > http://www.quotesdaddy.com/quote/1392067/julian-junebug-bussells/if-you-think-you-know-everything-about-baseball-your
                        > > >
                        > > > †Get this email app!
                        > > > <
                        > > http://www.wisestamp.com/apps/quotes?utm_source=extension&utm_medium=email&utm_term=quotes&utm_campaign=apps
                        > > >
                        > > >
                        > > > [image: Twitter] <http://twitter.com/elPedroMajor>Latest tweet: a Daily
                        > > > NEIS's world! is out! http://t.co/YpLxwEdT ▸ Top stories today via
                        > > > @toile_filante @agiletd @agile_exec @userfocus @gapingvoidart Follow
                        > > > @elPedroMajor <http://twitter.com/elPedroMajor> Reply
                        > > > <
                        > > http://twitter.com/?status=@elPedroMajor%20&in_reply_to_status_id=142220090568491000&in_reply_to=elPedroMajor
                        > > >
                        > > > Retweet
                        > > > <http://twitter.com/?status=RT%20%40elPedroMajor%3A%20a%20Daily%20NEIS
                        > > 's%20world!%20is%20out!%20http%3A%2F%2Ft.co%2FYpLxwEdT%20%E2%96%B8%20Top%20stories%20today%20via%20%40toile_filante%20%40agiletd%20%40agile_exec%20%40userfocus%20%40gapingvoidart>
                        > > > 13:34 Dec-01<http://twitter.com/elPedroMajor/statuses/142220090568491008
                        > > >
                        > > > Get a signature like this.
                        > > > <
                        > > http://r1.wisestamp.com/r/landing?promo=17&dest=http%3A%2F%2Fwww.wisestamp.com%2Femail-install%3Futm_source%3Dextension%26utm_medium%3Demail%26utm_campaign%3Dpromo_17
                        > > >
                        > > > CLICK
                        > > > HERE.<
                        > > http://r1.wisestamp.com/r/landing?promo=17&dest=http%3A%2F%2Fwww.wisestamp.com%2Femail-install%3Futm_source%3Dextension%26utm_medium%3Demail%26utm_campaign%3Dpromo_17
                        > > >
                        > > >
                        > > >
                        > > >
                        > > > On 1 December 2011 20:54, Mark Levison <mark@> wrote:
                        > > >
                        > > > > **
                        > > > >
                        > > > >
                        > > > >
                        > > > > Actually quite small. We have very experienced team. Quality and
                        > > technical
                        > > > >> debt is not an issue at this point.
                        > > > >>
                        > > > >
                        > > > > Hmm how are you measuring Technical Debt? I don't know of any perfect
                        > > way
                        > > > > but I also know that unless I'm unless I'm using some tool (ex Sonar) I
                        > > > > don't that I ever have a good idea. BTW No tool is perfect, Sonar has
                        > > its
                        > > > > flaws but without any measurement all you have is conjecture.
                        > > > >
                        > > > >
                        > > > >> That is actually one of my concerns with Scrum as I heard that with
                        > > Scrum
                        > > > >> technical debt increases and quality falls. I am assuming those are
                        > > > >> experiences of bad teams.
                        > > > >>
                        > > > >
                        > > > > I suspect that has alot to do with maturity, engineering practices and
                        > > how
                        > > > > much they focus on improvement. A team without any engineering
                        > > practices
                        > > > > starting Scrum will pile on the technical debt. A team that uses
                        > > > > TDD/BDD/ATDD/flavour of the week - will likely do better. Any team that
                        > > > > really uses retrospectives will improve. The kicker is that
                        > > retrospectives
                        > > > > are often done poorly.
                        > > > >
                        > > > > Cheers
                        > > > > Mark Levison
                        > > > >
                        > > > >
                        > > > >>
                        > > > >> > As for productivity, how do you measure that now? How would you
                        > > know it
                        > > > >> > improved? More importantly, how would your customers/users know you
                        > > > >> > improved?
                        > > > >> Good question. We do not measure it now. We plan to use velocity to
                        > > > >> measure it once we start doing scrum. I was hoping Scrum Master would
                        > > help
                        > > > >> me answer some of these questions.
                        > > > >>
                        > > > >>
                        > > > >> --- In scrumdevelopment@yahoogroups.com, Dave Rooney <daverooneyca@>
                        > > > >> wrote:
                        > > > >> >
                        > > > >> > What is the reason why you think Scrum will help? Are your
                        > > customers or
                        > > > >> > users clamoring for more content sooner? How large is your
                        > > outstanding
                        > > > >> > defect list?
                        > > > >> >
                        > > > >> > As for productivity, how do you measure that now? How would you
                        > > know it
                        > > > >> > improved? More importantly, how would your customers/users know you
                        > > > >> > improved?
                        > > > >> > On 2011-11-26 3:52 PM, "ag12340@" <ag12340@>
                        > > > >> > wrote:
                        > > > >> >
                        > > > >> > > **
                        > > > >>
                        > > > >> > >
                        > > > >> > >
                        > > > >> > > I am new to Scrum. Attended 2 day training.
                        > > > >> > >
                        > > > >> > > my title: dev manager
                        > > > >> > >
                        > > > >> > > current process: requirements doc, arch and design, iterative and
                        > > > >> > > incremental dev, handoff to qa, deploy. We deploy every 3 months.
                        > > > >> > >
                        > > > >> > > Good things: We can go back and change requirements and design. PO
                        > > > >> and biz
                        > > > >> > > owner is very involved and very accessible.
                        > > > >> > >
                        > > > >> > > Team: Cross functional 7 devs. QA is outside.
                        > > > >> > >
                        > > > >> > > My boss is onboard with Scrum. He loves 300% productivity
                        > > improvement
                        > > > >> > > scrum has many studies for and daily meetings.
                        > > > >> > >
                        > > > >> > > He thinks (wants) we should be able to hit 100% productivity
                        > > > >> improvement
                        > > > >> > > in an year (our goal for Scrum) and 40% in 6 months.
                        > > > >> > >
                        > > > >> > > I requested for a full time scrum master. He want justification
                        > > for
                        > > > >> extra
                        > > > >> > > cost and wants to know why I or some PM cannot do it.
                        > > > >> > >
                        > > > >> > > I said my hiring a full time SM, we will be able to reduce number
                        > > of
                        > > > >> > > developers by 2 (from 7 to 5) in an year and still get more done.
                        > > > >> > >
                        > > > >> > > Is that a good justification? What else can I provide?
                        > > > >> > >
                        > > > >> > >
                        > > > >> > >
                        > > > >> >
                        > > > >>
                        > > > >>
                        > > > >
                        > > > >
                        > > >
                        > >
                        > >
                        > >
                        >
                      • Mark Levison
                        Email is so imprecise and unclear. I wasn t sure how well you understood and Agile, but reading your reply makes it clear I was wrong. On Thu, Dec 1, 2011 at
                        Message 11 of 16 , Dec 1 5:47 PM
                          Email is so imprecise and unclear. I wasn't sure how well you understood and Agile, but reading your reply makes it clear I was wrong.

                          On Thu, Dec 1, 2011 at 7:46 PM, ag12340@... <ag12340@...> wrote:

                          >>Second you seem to think that it's ok
                          > to rotate facilitation with out having any effect on the team.

                          Yes, It is OK. It is not important who is facilitating the meeting till they are facilitating. XP did rotation.

                          On this point we will differ, I see teams that rotate Scrum Master take longer to mature. That may relate to the next item. 

                          >> Self organizing teams are hard to nurture,

                          I disagree. Self organizing seems to me the natural state in knowledge worker economy. Thats what you get by default. Command and control is very hard to nurture because it is not natural for knowledge workers and there is lots of resistance.

                          In principle that should be true, sadly my practice has lead to me to discover so many command and control shops that I wonder. My experience is that many mouth the words "self organization" and few live it. To my mind this is one of bigger issues facing large organizations that try to adopt agile.

                          Cheers
                          Mark Levison

                          MarkMark Levison | Agile Pain Relief Consulting | Certified Scrum Trainer
                          Agile Editor @ InfoQ | Blog | Twitter | Office: (613) 862-2538
                          Recent Entries:
                          Story Slicing How Small is Small Enough, Why use an Agile Coach


                          --- In scrumdevelopment@yahoogroups.com, Mark Levison <mark@...> wrote:
                          >
                          > I'm troubled. I'm sure you are an excellent manager but I'm not sure if you
                          > really understand Scrum. First you keep on using the word lead to describe
                          > the meetings are run. Facilitate is a much better word it makes out clear
                          > that you have a self organizing team. Second you seem to think that it's ok
                          > to rotate facilitation with out having any effect on the team. Self
                          > organizing teams are hard to nurture, your language doesn't make it clear
                          > that you recognize that. Help me see my mistake. Help me see that you
                          > understand Scrum deeply and that you recognize the tradeoffs you're making.
                          >
                          > Cheers
                          > Mark - on a phone
                          > On Dec 1, 2011 6:12 PM, "ag12340@..." <ag12340@...>
                          > wrote:
                          >
                          > > **

                          > >
                          > >
                          > > Thank you all,
                          > >
                          > > I talked to many people who are doing Scrum in the field. Following comes
                          > > out recommended practice so far.
                          > >
                          > > I have decided to make my Tech Lead as "Scrum Master". We will get an
                          > > experienced coach to watch us and help us out initially (first few
                          > > sprints). I am dev manager.
                          > >
                          > > 1) Part 1 of planning meeting - PO will lead. I will attend. PO discusses
                          > > backlog here.
                          > >
                          > > 2) Tech lead will lead part 2 of planning meeting where team decides how
                          > > much they can do. I will not attend this part of meeting. PO will attend.
                          > >
                          > > 3) Tech lead will lead daily meetings. Any technical impediments he will
                          > > resolve with team, others he will escalate to me. I will occasionally
                          > > attend this meeting to make sure team is working together properly.
                          > >
                          > > 4) Retrospective - I will lead. Coach will help here initially.
                          > >
                          > > I will work with stake holders and minimize any distractions to team and
                          > > keep making sure team dynamics is good. I will also work with tech lead and
                          > > team to make sure we are improving and implementing suggestions from
                          > > retrospective.
                          > >
                          > > We will go with this approach and improve, adapt and innovate as we go on.
                          > >
                          > > --- In scrumdevelopment@yahoogroups.com, Pierre Neis <pierreneis@>
                          > > wrote:
                          > > >
                          > > > This is 1 scenario.
                          > > >
                          > > > Here another:
                          > > >
                          > > > If you're focus on delivery done increments, tech debts are managed as
                          > > > constraints and blocking points.
                          > > > So you have to keep balance with reduce this Tech Debt and release Done
                          > > > increments.
                          > > >
                          > > > There, I use a trick:
                          > > >
                          > > > - monthly deliveries
                          > > > - 2 week sprints: the first delivers features and the 2d fix the debt
                          > > > - always start the project in a clean space
                          > > > - Debt must be fixed at 1st release: no procrastination accepted (Scrum
                          > > > Master plays SM Angel!!)
                          > > >
                          > > > Concerning "Justify Scrum Master"
                          > > >
                          > > > - in a small project with no interdependencies : (s)he makes coordination
                          > > > - in a huge project: (s)he must play the backup for the Product Owner
                          > > > and coach all Project Stakeholders
                          > > > - + I coach my Scrum Masters by improving the BPM process: at
                          > > > Retrospective, the Development Team leaves a feedback on the improved
                          > > > initial BPM (part of DoD) --> working on government projects!!!
                          > > >
                          > > >
                          > > >
                          > > > *Pierre E. NEIS*, *csp*
                          > > >
                          > > > *Head of Lean Competence Centre @ coPROcess S.A. **â"‚ Scrum & Lean
                          > > Coach *
                          > > >
                          > > > *M*: +352 / 661 727 867 - *Skype*: pierre.neis
                          > > > *Meet with* me: http://meetwith.me/pierreneis
                          > > >
                          > > > *
                          > > > *
                          > > >
                          > > > “"If you think you know everything about baseball, your dead wrong!" -
                          > > > Julian "JUNEBUG"
                          > > > Bussells<
                          > > http://www.quotesdaddy.com/quote/1392067/julian-junebug-bussells/if-you-think-you-know-everything-about-baseball-your
                          > > >
                          > > > †Get this email app!
                          > > > <
                          > > http://www.wisestamp.com/apps/quotes?utm_source=extension&utm_medium=email&utm_term=quotes&utm_campaign=apps
                          > > >
                          > > >
                          > > > [image: Twitter] <http://twitter.com/elPedroMajor>Latest tweet: a Daily
                          > > > NEIS's world! is out! http://t.co/YpLxwEdT â–¸ Top stories today via
                          > > > @toile_filante @agiletd @agile_exec @userfocus @gapingvoidart Follow
                          > > > @elPedroMajor <http://twitter.com/elPedroMajor> Reply
                          > > > <
                          > > http://twitter.com/?status=@elPedroMajor%20&in_reply_to_status_id=142220090568491000&in_reply_to=elPedroMajor
                          > > >
                          > > > Retweet
                          > > > <http://twitter.com/?status=RT%20%40elPedroMajor%3A%20a%20Daily%20NEIS
                          > > 's%20world!%20is%20out!%20http%3A%2F%2Ft.co%2FYpLxwEdT%20%E2%96%B8%20Top%20stories%20today%20via%20%40toile_filante%20%40agiletd%20%40agile_exec%20%40userfocus%20%40gapingvoidart>
                          > > > 13:34 Dec-01<http://twitter.com/elPedroMajor/statuses/142220090568491008
                          > > >
                          > > > Get a signature like this.
                          > > > <
                          > > http://r1.wisestamp.com/r/landing?promo=17&dest=http%3A%2F%2Fwww.wisestamp.com%2Femail-install%3Futm_source%3Dextension%26utm_medium%3Demail%26utm_campaign%3Dpromo_17
                          > > >
                          > > > CLICK
                          > > > HERE.<
                          > > http://r1.wisestamp.com/r/landing?promo=17&dest=http%3A%2F%2Fwww.wisestamp.com%2Femail-install%3Futm_source%3Dextension%26utm_medium%3Demail%26utm_campaign%3Dpromo_17
                          > > >
                          > > >
                          > > >
                          > > >
                          > > > On 1 December 2011 20:54, Mark Levison <mark@> wrote:
                          > > >
                          > > > > **
                          > > > >
                          > > > >
                          > > > >
                          > > > > Actually quite small. We have very experienced team. Quality and
                          > > technical
                          > > > >> debt is not an issue at this point.
                          > > > >>
                          > > > >
                          > > > > Hmm how are you measuring Technical Debt? I don't know of any perfect
                          > > way
                          > > > > but I also know that unless I'm unless I'm using some tool (ex Sonar) I
                          > > > > don't that I ever have a good idea. BTW No tool is perfect, Sonar has
                          > > its
                          > > > > flaws but without any measurement all you have is conjecture.
                          > > > >
                          > > > >
                          > > > >> That is actually one of my concerns with Scrum as I heard that with
                          > > Scrum
                          > > > >> technical debt increases and quality falls. I am assuming those are
                          > > > >> experiences of bad teams.
                          > > > >>
                          > > > >
                          > > > > I suspect that has alot to do with maturity, engineering practices and
                          > > how
                          > > > > much they focus on improvement. A team without any engineering
                          > > practices
                          > > > > starting Scrum will pile on the technical debt. A team that uses
                          > > > > TDD/BDD/ATDD/flavour of the week - will likely do better. Any team that
                          > > > > really uses retrospectives will improve. The kicker is that
                          > > retrospectives
                          > > > > are often done poorly.
                          > > > >
                          > > > > Cheers
                          > > > > Mark Levison
                          > > > >
                          > > > >
                          > > > >>
                          > > > >> > As for productivity, how do you measure that now? How would you
                          > > know it
                          > > > >> > improved? More importantly, how would your customers/users know you
                          > > > >> > improved?
                          > > > >> Good question. We do not measure it now. We plan to use velocity to
                          > > > >> measure it once we start doing scrum. I was hoping Scrum Master would
                          > > help
                          > > > >> me answer some of these questions.
                          > > > >>
                          > > > >>
                          > > > >> --- In scrumdevelopment@yahoogroups.com, Dave Rooney <daverooneyca@>
                          > > > >> wrote:
                          > > > >> >
                          > > > >> > What is the reason why you think Scrum will help? Are your
                          > > customers or
                          > > > >> > users clamoring for more content sooner? How large is your
                          > > outstanding
                          > > > >> > defect list?
                          > > > >> >
                          > > > >> > As for productivity, how do you measure that now? How would you
                          > > know it
                          > > > >> > improved? More importantly, how would your customers/users know you
                          > > > >> > improved?
                          > > > >> > On 2011-11-26 3:52 PM, "ag12340@" <ag12340@>
                          > > > >> > wrote:
                          > > > >> >
                          > > > >> > > **
                          > > > >>
                          > > > >> > >
                          > > > >> > >
                          > > > >> > > I am new to Scrum. Attended 2 day training.
                          > > > >> > >
                          > > > >> > > my title: dev manager
                          > > > >> > >
                          > > > >> > > current process: requirements doc, arch and design, iterative and
                          > > > >> > > incremental dev, handoff to qa, deploy. We deploy every 3 months.
                          > > > >> > >
                          > > > >> > > Good things: We can go back and change requirements and design. PO
                          > > > >> and biz
                          > > > >> > > owner is very involved and very accessible.
                          > > > >> > >
                          > > > >> > > Team: Cross functional 7 devs. QA is outside.
                          > > > >> > >
                          > > > >> > > My boss is onboard with Scrum. He loves 300% productivity
                          > > improvement
                          > > > >> > > scrum has many studies for and daily meetings.
                          > > > >> > >
                          > > > >> > > He thinks (wants) we should be able to hit 100% productivity
                          > > > >> improvement
                          > > > >> > > in an year (our goal for Scrum) and 40% in 6 months.
                          > > > >> > >
                          > > > >> > > I requested for a full time scrum master. He want justification
                          > > for
                          > > > >> extra
                          > > > >> > > cost and wants to know why I or some PM cannot do it.
                          > > > >> > >
                          > > > >> > > I said my hiring a full time SM, we will be able to reduce number
                          > > of
                          > > > >> > > developers by 2 (from 7 to 5) in an year and still get more done.
                          > > > >> > >
                          > > > >> > > Is that a good justification? What else can I provide?
                          > > > >> > >
                          > > > >> > >
                          > > > >> > >
                          > > > >> >
                          > > > >>
                          > > > >>
                          > > > >
                          > > > >
                          > > >
                          > >
                          > >
                          > >
                          >


                        • Michael James
                          ... Mark and I are both reacting to the phrase Tech Lead. While the step you ve taken will probably make things better, I m guessing an additional useful
                          Message 12 of 16 , Dec 2 12:25 AM
                            On Dec 1, 2011, at 6:11 PM, ag12340@... wrote:

                            > I have decided to make my Tech Lead as "Scrum Master".

                            Mark and I are both reacting to the phrase "Tech Lead." While the step you've taken will probably make things better, I'm guessing an additional useful step may be to reduce the influence of job titles and externally-designated hierarchies. I recently heard Jeff Sutherland talking about the effectiveness of teams without job titles at Bell Labs as inspiration for Scrum.

                            Once your team understands the ScrumMaster's role a bit better, an interesting thing to explore would be asking the team to decide who their ScrumMaster should be.

                            --mj
                          • ag12340@rocketmail.com
                            Thank you. That is a good suggestion. I will make expectations clear to the team from onset that roles like SM and tech lead are not sticky. It would be easy
                            Message 13 of 16 , Dec 2 9:29 AM
                              Thank you. That is a good suggestion.

                              I will make expectations clear to the team from onset that roles like SM and tech lead are not sticky. It would be easy to do for SM as it is a new role and no one has it. It would be harder to do for tech lead. I will have to give it more thought. I do not want to demotivate people.


                              --- In scrumdevelopment@yahoogroups.com, Michael James <mj4scrum@...> wrote:
                              >
                              > On Dec 1, 2011, at 6:11 PM, ag12340@... wrote:
                              >
                              > > I have decided to make my Tech Lead as "Scrum Master".
                              >
                              > Mark and I are both reacting to the phrase "Tech Lead." While the step you've taken will probably make things better, I'm guessing an additional useful step may be to reduce the influence of job titles and externally-designated hierarchies. I recently heard Jeff Sutherland talking about the effectiveness of teams without job titles at Bell Labs as inspiration for Scrum.
                              >
                              > Once your team understands the ScrumMaster's role a bit better, an interesting thing to explore would be asking the team to decide who their ScrumMaster should be.
                              >
                              > --mj
                              >
                            • George Dinwiddie
                              Hi, ag12340 ... If your expectation of Scrum is principally productivity improvement, and especially if you measure productivity using velocity, then, yes, you
                              Message 14 of 16 , Dec 2 2:01 PM
                                Hi, ag12340

                                On 11/27/11 1:01 AM, ag12340@... wrote:
                                > Actually quite small. We have very experienced team. Quality and
                                > technical debt is not an issue at this point.
                                >
                                > That is actually one of my concerns with Scrum as I heard that with
                                > Scrum technical debt increases and quality falls. I am assuming those
                                > are experiences of bad teams.
                                >
                                >> As for productivity, how do you measure that now? How would you know it
                                >> improved? More importantly, how would your customers/users know you
                                >> improved?
                                > Good question. We do not measure it now. We plan to use velocity to
                                > measure it once we start doing scrum. I was hoping Scrum Master would
                                > help me answer some of these questions.

                                If your expectation of Scrum is principally productivity improvement,
                                and especially if you measure productivity using velocity, then, yes,
                                you are likely to experience an increase of technical debt and a
                                decrease in quality.

                                That's not how it works.

                                Scrum, done well, can help you better do the right thing--not
                                necessarily do it faster. If you also pay attention to quality (in many
                                ways, not just the external aspects of the program being developed),
                                then you may also achieve an increase in productivity.

                                I've rarely, if ever, seen an increase in productivity in response to a
                                desire to increase productivity. Going directly for that goal seems to
                                give the /appearance/ of increased productivity, as quality is
                                sacrificed to meet the measurement chosen as a proxy for productivity.
                                This abandonment of focus on quality will, in a relatively short time,
                                decrease productivity, perhaps to a point from which it is very hard to
                                recover.

                                Productivity is one of those desirables that seems best approached
                                obliquely. If you focus on smooth flow, on increasing skill and
                                knowledge, and on improved internal quality of the system, then
                                productivity gains are likely to accompany.

                                >>> I am new to Scrum. Attended 2 day training.

                                Realize that there is much you do not know, and that some of it is
                                things you think you know but don't realize the subtleties.

                                >>> my title: dev manager

                                In most organizations I've seen, you might not be the best person to
                                lead the retrospectives--not if you want them to be effective. It's a
                                rare manager who can do so.

                                >>> current process: requirements doc, arch and design, iterative and
                                >>> incremental dev, handoff to qa, deploy. We deploy every 3 months.
                                >>>
                                >>> Good things: We can go back and change requirements and design. PO and biz
                                >>> owner is very involved and very accessible.

                                That part sounds good.

                                >>> Team: Cross functional 7 devs. QA is outside.

                                That doesn't. If you want quality and productivity benefits, I suggest
                                making QA part of the team.

                                >>> My boss is onboard with Scrum. He loves 300% productivity improvement
                                >>> scrum has many studies for and daily meetings.
                                >>>
                                >>> He thinks (wants) we should be able to hit 100% productivity improvement
                                >>> in an year (our goal for Scrum) and 40% in 6 months.
                                >>>
                                >>> I requested for a full time scrum master. He want justification for extra
                                >>> cost and wants to know why I or some PM cannot do it.

                                You boss cannot be onboard with Scrum. He seems to know little or
                                nothing about the heart of Scrum, but is only looking for cost savings.
                                You cannot be onboard with something you don't understand (though you
                                may think your are).

                                >>> I said my hiring a full time SM, we will be able to reduce number of
                                >>> developers by 2 (from 7 to 5) in an year and still get more done.

                                What is your justification for that assertion?

                                - George

                                --
                                ----------------------------------------------------------------------
                                * George Dinwiddie * http://blog.gdinwiddie.com
                                Software Development http://www.idiacomputing.com
                                Consultant and Coach http://www.agilemaryland.org
                                ----------------------------------------------------------------------
                              • Andrew Pham
                                On Mon, Nov 21, 2011 at 8:56 PM, ag12340@rocketmail.com
                                Message 15 of 16 , Dec 3 9:02 AM
                                  On Mon, Nov 21, 2011 at 8:56 PM, ag12340@... <ag12340@...> wrote:
                                   

                                  I am new to Scrum. Attended 2 day training.

                                  my title: dev manager

                                  current process: requirements doc, arch and design, iterative and incremental dev, handoff to qa, deploy. We deploy every 3 months.

                                  Good things: We can go back and change requirements and design. PO and biz owner is very involved and very accessible.

                                  Team: Cross functional 7 devs. QA is outside.

                                  My boss is onboard with Scrum. He loves 300% productivity improvement scrum has many studies for and daily meetings.

                                  He thinks (wants) we should be able to hit 100% productivity improvement in an year (our goal for Scrum) and 40% in 6 months.

                                  I requested for a full time scrum master. He want justification for extra cost and wants to know why I or some PM cannot do it.

                                   
                                  There is no justification for a (certified) ScrumMaster, especially with people getting automatically a certification after a two-day class with no passing or failing test.

                                  Change is hard but Scrum itself, as a project management process framework, is very simple, especially after you get management's understanding and support as well as buying and excitement from the team.

                                  What you guys (and any project team new to Scrum) would need is a practicing coach to help you with the process, which they can learn by reading Ken's and Jeff's Scrum guide and one or two practical books and, especially, by working with and learning from the practicing coach.

                                  Cheers,

                                  Andrew

                                  Author of
                                  Scrum in Action, Agile Project Management and Development in the Real-World
                                  http://www.amazon.com/Scrum-Action-Andrew-Pham/dp/143545913X/ref=ntt_at_ep_dpi_1-1

                                  and of "Business-Driven IT-Wide Agile (Scrum) and/or Kanban (Lean) Implementation" (reviewed and upcoming)


                                  I said my hiring a full time SM, we will be able to reduce number of developers by 2 (from 7 to 5) in an year and still get more done.

                                  Is that a good justification? What else can I provide?



                                • ag12340@rocketmail.com
                                  Thank you Andrew. I agree. It is important to have a coach for some initial period (few sprints, I guess time varies from team to team) and then have him come
                                  Message 16 of 16 , Dec 3 12:24 PM
                                    Thank you Andrew. I agree. It is important to have a coach for some initial period (few sprints, I guess time varies from team to team) and then have him come in from time to time.

                                    --- In scrumdevelopment@yahoogroups.com, Andrew Pham <andrewpham74@...> wrote:
                                    >
                                    > On Mon, Nov 21, 2011 at 8:56 PM, ag12340@... <
                                    > ag12340@...> wrote:
                                    >
                                    > > **
                                    > >
                                    > >
                                    > > I am new to Scrum. Attended 2 day training.
                                    > >
                                    > > my title: dev manager
                                    > >
                                    > > current process: requirements doc, arch and design, iterative and
                                    > > incremental dev, handoff to qa, deploy. We deploy every 3 months.
                                    > >
                                    > > Good things: We can go back and change requirements and design. PO and biz
                                    > > owner is very involved and very accessible.
                                    > >
                                    > > Team: Cross functional 7 devs. QA is outside.
                                    > >
                                    > > My boss is onboard with Scrum. He loves 300% productivity improvement
                                    > > scrum has many studies for and daily meetings.
                                    > >
                                    > > He thinks (wants) we should be able to hit 100% productivity improvement
                                    > > in an year (our goal for Scrum) and 40% in 6 months.
                                    > >
                                    > > I requested for a full time scrum master. He want justification for extra
                                    > > cost and wants to know why I or some PM cannot do it.
                                    > >
                                    >
                                    > There is no justification for a (certified) ScrumMaster, especially with
                                    > people getting automatically a certification after a two-day class with no
                                    > passing or failing test.
                                    >
                                    > Change is hard but Scrum itself, as a project management process framework,
                                    > is very simple, especially after you get management's understanding and
                                    > support as well as buying and excitement from the team.
                                    >
                                    > What you guys (and any project team new to Scrum) would need is a
                                    > practicing coach to help you with the process, which they can learn by
                                    > reading Ken's and Jeff's Scrum guide and one or two practical books and,
                                    > especially, by working with and learning from the practicing coach.
                                    >
                                    > Cheers,
                                    >
                                    > Andrew
                                    >
                                    > Author of *Scrum in Action**, Agile Project Management and Development in
                                    > the Real-World*
                                    > http://www.amazon.com/Scrum-Action-Andrew-Pham/dp/143545913X/ref=ntt_at_ep_dpi_
                                    > *1*<http://www.amazon.com/Scrum-Action-Andrew-Pham/dp/143545913X/ref=ntt_at_ep_dpi_1>
                                    > -1
                                    >
                                    > and of *"Business-Driven IT-Wide Agile (Scrum) and/or Kanban (Lean)
                                    > Implementation" **(reviewed and upcoming)*
                                    >
                                    >
                                    > > I said my hiring a full time SM, we will be able to reduce number of
                                    > > developers by 2 (from 7 to 5) in an year and still get more done.
                                    > >
                                    > > Is that a good justification? What else can I provide?
                                    > >
                                    >
                                    > >
                                    > >
                                    >
                                  Your message has been successfully submitted and would be delivered to recipients shortly.