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

Selling your project

Expand Messages
  • William Berger
    While I realize that this forum is about the actual implementing of Scrum, I figured many of those who read and respond to these posts probably face the issue
    Message 1 of 12 , Aug 14, 2008
      While I realize that this forum is about the actual implementing of
      Scrum, I figured many of those who read and respond to these posts
      probably face the issue of sales too.

      I'm looking for resources that describe how to sell Scrum projects,
      specifically for consulting or integrator companies.

      How does one approach the Scrum discussion in sales? The obvious
      issues would be traditional project control (PMO) and budget.

      Any thoughts?

      Bill Berger
    • Rick Simmons
      Rachel Weston (Rally) and Chris Spagnuolo (DTS Agile) did a presentation on Agile Contracting last week at Agile08, and they addressed these and many other
      Message 2 of 12 , Aug 14, 2008
        Rachel Weston (Rally) and Chris Spagnuolo (DTS Agile) did a
        presentation on Agile Contracting last week at Agile08, and they
        addressed these and many other issues. The overview is here:
        http://submissions.agile2008.org/node/1468. Their deck wasn't on the
        conference CD, but they might share it with you.

        Chris in particular is in the thick of this, selling agile projects to
        large (mostly government) organizations.

        RS






        --- In scrumdevelopment@yahoogroups.com, "William Berger"
        <Bill.Berger@...> wrote:
        >
        > While I realize that this forum is about the actual implementing of
        > Scrum, I figured many of those who read and respond to these posts
        > probably face the issue of sales too.
        >
        > I'm looking for resources that describe how to sell Scrum projects,
        > specifically for consulting or integrator companies.
        >
        > How does one approach the Scrum discussion in sales? The obvious
        > issues would be traditional project control (PMO) and budget.
        >
        > Any thoughts?
        >
        > Bill Berger
        >
      • William Berger
        Thanks Rick. I ll check it out. After I posted, I did find the sellingagile yahoo group and am now combing through the posts there. Also, in this group, some
        Message 3 of 12 , Aug 14, 2008
          Thanks Rick. I'll check it out.

          After I posted, I did find the sellingagile yahoo group and am now
          combing through the posts there. Also, in this group, some has been
          mentioned already including a link to an article by Mike Cohn
          (http://www.mountaingoatsoftware.com/article/view/5).

          I'm seeing some stuff, but am not there yet. More input is welcome.

          Thanks,
          BB

          --- In scrumdevelopment@yahoogroups.com, "Rick Simmons"
          <simmons3k@...> wrote:
          >
          > Rachel Weston (Rally) and Chris Spagnuolo (DTS Agile) did a
          > presentation on Agile Contracting last week at Agile08, and they
          > addressed these and many other issues. The overview is here:
          > http://submissions.agile2008.org/node/1468. Their deck wasn't on
          the
          > conference CD, but they might share it with you.
          >
          > Chris in particular is in the thick of this, selling agile projects
          to
          > large (mostly government) organizations.
          >
          > RS
          >
          >
          >
          >
          >
          >
          > --- In scrumdevelopment@yahoogroups.com, "William Berger"
          > <Bill.Berger@> wrote:
          > >
          > > While I realize that this forum is about the actual implementing
          of
          > > Scrum, I figured many of those who read and respond to these
          posts
          > > probably face the issue of sales too.
          > >
          > > I'm looking for resources that describe how to sell Scrum
          projects,
          > > specifically for consulting or integrator companies.
          > >
          > > How does one approach the Scrum discussion in sales? The obvious
          > > issues would be traditional project control (PMO) and budget.
          > >
          > > Any thoughts?
          > >
          > > Bill Berger
          > >
          >
        • James S. Fosdick, PMP, CSP
          ... What discussion specifically are you talking about? My general approach has always been to keep method out of sales discussions. Ultimately they are
          Message 4 of 12 , Aug 14, 2008
            > How does one approach the Scrum discussion in sales? The obvious
            > issues would be traditional project control (PMO) and budget.

            What discussion specifically are you talking about? My general
            approach has always been to keep method out of sales discussions.
            Ultimately they are irrelevant to that cycle. Rather the emphasis is
            on building value and convincing the potential client that you can do
            that.

            What issues surrounding traditional project control do you mean? Agile
            and Scrum have project control mechanisms they're just predicated on
            different assumptions about how new software products are developed
            (i.e. the right assumptions)

            As far as budget goes, budget is budget. Funding is a constrained
            resource that must be dealt with regardless of method. "Fixed
            Price"/"Fixed Scope" projects are generally bad for everyone on a
            software project irrespective of method but usually an unfortunate
            reality. The biggest advantage of Scrum is that you are building real
            business value almost immediately and every 30 days (or 2 weeks or
            whatever) you get to inspect and adapt. Since you're building real
            value up front (instead of lengthy development of artifacts that have
            no business value in and of themselves) and since you are prioritizing
            what you are building to maximize value (and I would argue earlier
            realization of ROI) you can decide at any point along the way when the
            product is sufficiently mature to release. In the long run this saves
            time and money and maximizes ROI because you build only what you need
            to realize your return. A traditional approach results in a product
            that may not actually meet stakeholder needs and where as much as 80%
            of the cost is in features of limited or no value add (i.e. the 80/20
            rule)
          • William Berger
            Thanks for the reply. ... Respectfully, I do not use this approach. However, I suspect we are more alike in our sales discussions than is suggested. We are
            Message 5 of 12 , Aug 14, 2008
              Thanks for the reply.

              > What discussion specifically are you talking about? My general
              > approach has always been to keep method out of sales discussions.

              Respectfully, I do not use this approach. However, I suspect we are
              more alike in our sales discussions than is suggested. We are highly
              transparent with clients to build trust and to set the expectations
              around the level of time and resource commitment from the client.


              > Ultimately they are irrelevant to that cycle.

              I respectfully disagree with this statement.


              > What issues surrounding traditional project control do you mean?

              By my phrasing "project control", I am referring to PMO processes
              that are prevalent in large organizations (in my experience). It
              also refers to typical, control-oriented project management that
              dictates schedule, etc... In my experience, this is almost universal.

              As for budget, I am aware of the benefits of Agile (particularly
              Scrum). However, the reality is, as was stated, clients
              prefer "Fixed Price"/"Fixed Scope". I'm looking for some ideas on
              how to effectively develop budgets with clients in relation to using
              an Agile software development paradigm. In one article I read by
              Mike Cohn, I found an approach that gives a budgetary range with high
              (very high in my experience) variability. While I like this idea,
              I've not seen this accepted in real-life, though I've actually tried.


              --- In scrumdevelopment@yahoogroups.com, "James S. Fosdick, PMP, CSP"
              <jsfosdickcsp@...> wrote:
              >
              > > How does one approach the Scrum discussion in sales? The obvious
              > > issues would be traditional project control (PMO) and budget.
              >
              > What discussion specifically are you talking about? My general
              > approach has always been to keep method out of sales discussions.
              > Ultimately they are irrelevant to that cycle. Rather the emphasis is
              > on building value and convincing the potential client that you can
              do
              > that.
              >
              > What issues surrounding traditional project control do you mean?
              Agile
              > and Scrum have project control mechanisms they're just predicated on
              > different assumptions about how new software products are developed
              > (i.e. the right assumptions)
              >
              > As far as budget goes, budget is budget. Funding is a constrained
              > resource that must be dealt with regardless of method. "Fixed
              > Price"/"Fixed Scope" projects are generally bad for everyone on a
              > software project irrespective of method but usually an unfortunate
              > reality. The biggest advantage of Scrum is that you are building
              real
              > business value almost immediately and every 30 days (or 2 weeks or
              > whatever) you get to inspect and adapt. Since you're building real
              > value up front (instead of lengthy development of artifacts that
              have
              > no business value in and of themselves) and since you are
              prioritizing
              > what you are building to maximize value (and I would argue earlier
              > realization of ROI) you can decide at any point along the way when
              the
              > product is sufficiently mature to release. In the long run this
              saves
              > time and money and maximizes ROI because you build only what you
              need
              > to realize your return. A traditional approach results in a product
              > that may not actually meet stakeholder needs and where as much as
              80%
              > of the cost is in features of limited or no value add (i.e. the
              80/20
              > rule)
              >
            • Angela Druckman
              Hi Bill - We have a large client with whom we have a long term relationship and have been able to successfully transition to Scrum on select projects.  If
              Message 6 of 12 , Aug 14, 2008
                Hi Bill -
                 
                We have a large client with whom we have a long term relationship and have been able to successfully transition to Scrum on select projects.  If you are interested in the speicifcs of how we approached the different documentation and contracts (i.e. - Statement of Work, Client Change Requests, etc) I would be happy to provide that.  In a nutshell, instead of contracting to provide a specific set of requirements, we contracted to give them a specific number of releases and they could have as much in those releases as would fit, based on time and budget, guided by the Product Backlog. 
                 
                We ended up reducing or eliminating much of our standard documents with this approach and I believe it is saving the client money because all those document design reviews cost big bucks (look at all those people sitting around the conference table for 2 hours, multiply that by your bill rate, and you will see some serious dollars!) 
                 
                And the previous approach to gather "all" (whatever that is) the requirements beforehand invariably devolved into a search for obscure situations we should really not be designing around.  Instead, working from a dynamic Product Backlog, we got real, working product to the customer much sooner and avoided dozens of hours of meetings that would have been only marginally useful.
                 
                Hope this is helpful--
                 
                     --Angela
                 



                ----- Original Message ----
                From: William Berger <Bill.Berger@...>
                To: scrumdevelopment@yahoogroups.com
                Sent: Thursday, August 14, 2008 2:48:56 PM
                Subject: [scrumdevelopment] Re: Selling your project

                Thanks for the reply.

                > What discussion specifically are you talking about? My general
                > approach has always been to keep method out of sales discussions.

                Respectfully, I do not use this approach. However, I suspect we are
                more alike in our sales discussions than is suggested. We are highly
                transparent with clients to build trust and to set the expectations
                around the level of time and resource commitment from the client.

                > Ultimately they are irrelevant to that cycle.

                I respectfully disagree with this statement.

                > What issues surrounding traditional project control do you mean?

                By my phrasing "project control", I am referring to PMO processes
                that are prevalent in large organizations (in my experience). It
                also refers to typical, control-oriented project management that
                dictates schedule, etc... In my experience, this is almost universal.

                As for budget, I am aware of the benefits of Agile (particularly
                Scrum). However, the reality is, as was stated, clients
                prefer "Fixed Price"/"Fixed Scope". I'm looking for some ideas on
                how to effectively develop budgets with clients in relation to using
                an Agile software development paradigm. In one article I read by
                Mike Cohn, I found an approach that gives a budgetary range with high
                (very high in my experience) variability. While I like this idea,
                I've not seen this accepted in real-life, though I've actually tried.

                --- In scrumdevelopment@ yahoogroups. com, "James S. Fosdick, PMP, CSP"
                <jsfosdickcsp@ ...> wrote:
                >
                > > How does one approach the Scrum discussion in sales? The obvious
                > > issues would be traditional project control (PMO) and budget.
                >
                > What
                discussion specifically are you talking about? My general
                > approach has always been to keep method out of sales discussions.
                > Ultimately they are irrelevant to that cycle. Rather the emphasis is
                > on building value and convincing the potential client that you can
                do
                > that.
                >
                > What issues surrounding traditional project control do you mean?
                Agile
                > and Scrum have project control mechanisms they're just predicated on
                > different assumptions about how new software products are developed
                > (i.e. the right assumptions)
                >
                > As far as budget goes, budget is budget. Funding is a constrained
                > resource that must be dealt with regardless of method. "Fixed
                > Price"/"Fixed Scope" projects are generally bad for everyone on a
                > software project irrespective of method but usually an unfortunate
                > reality. The biggest advantage of Scrum is that you are building
                real
                > business value almost immediately and every 30 days (or 2 weeks or
                > whatever) you get to inspect and adapt. Since you're building real
                > value up front (instead of lengthy development of artifacts that
                have
                > no business value in and of themselves) and since you are
                prioritizing
                > what you are building to maximize value (and I would argue earlier
                > realization of ROI) you can decide at any point along the way when
                the
                > product is sufficiently mature to release. In the long run this
                saves
                > time and money and maximizes ROI because you build only what you
                need
                > to realize your return. A traditional approach results in a product
                > that may not actually meet stakeholder needs and where as much as
                80%
                > of the cost is in features of limited or no value add (i.e. the
                80/20
                > rule)
                >


              • Felipe Maillist
                I think there should be a sale approach to tell to customer that he must give some of his time during the project. People have lots of expectation and we have
                Message 7 of 12 , Aug 14, 2008
                  I think there should be a sale approach to tell to customer that he must
                  give some of his time during the project. People have lots of
                  expectation and we have to sell how we procede and make sure they
                  understand their role in the project, otherwise things can get really messy.


                  *Felipe Rodrigues de Almeida
                  Fratech It*
                  +55 19 3454-8335
                  +55 19 8125-4977
                  http://www.fratech.net
                  http://blog.fratech.net


                  James S. Fosdick, PMP, CSP escreveu:
                  >
                  >
                  > > How does one approach the Scrum discussion in sales? The obvious
                  > > issues would be traditional project control (PMO) and budget.
                  >
                  > What discussion specifically are you talking about? My general
                  > approach has always been to keep method out of sales discussions.
                  > Ultimately they are irrelevant to that cycle. Rather the emphasis is
                  > on building value and convincing the potential client that you can do
                  > that.
                  >
                  > What issues surrounding traditional project control do you mean? Agile
                  > and Scrum have project control mechanisms they're just predicated on
                  > different assumptions about how new software products are developed
                  > (i.e. the right assumptions)
                  >
                  > As far as budget goes, budget is budget. Funding is a constrained
                  > resource that must be dealt with regardless of method. "Fixed
                  > Price"/"Fixed Scope" projects are generally bad for everyone on a
                  > software project irrespective of method but usually an unfortunate
                  > reality. The biggest advantage of Scrum is that you are building real
                  > business value almost immediately and every 30 days (or 2 weeks or
                  > whatever) you get to inspect and adapt. Since you're building real
                  > value up front (instead of lengthy development of artifacts that have
                  > no business value in and of themselves) and since you are prioritizing
                  > what you are building to maximize value (and I would argue earlier
                  > realization of ROI) you can decide at any point along the way when the
                  > product is sufficiently mature to release. In the long run this saves
                  > time and money and maximizes ROI because you build only what you need
                  > to realize your return. A traditional approach results in a product
                  > that may not actually meet stakeholder needs and where as much as 80%
                  > of the cost is in features of limited or no value add (i.e. the 80/20
                  > rule)
                  >
                  >
                • Peter Stevens
                  Hi Bill How to handle it in sales? Real Simple: Waterfall is more expensive . You
                  Message 8 of 12 , Sep 19, 2008
                    Hi Bill

                    How to handle it in sales? Real Simple: Waterfall is more expensive. You give the customer what he wants. If he wants a waterfall, he has to pay for a waterfall.

                    Cheers,

                    Peter

                    William Berger wrote:

                    While I realize that this forum is about the actual implementing of
                    Scrum, I figured many of those who read and respond to these posts
                    probably face the issue of sales too.

                    I'm looking for resources that describe how to sell Scrum projects,
                    specifically for consulting or integrator companies.

                    How does one approach the Scrum discussion in sales? The obvious
                    issues would be traditional project control (PMO) and budget.

                    Any thoughts?

                    Bill Berger



                    -- 
                    Peter Stevens, CSM, CSP
                    Scrum Training in German: http://ausbildung.scrum-breakfast.com
                    http://scrum-breakfast.com
                    tel: +41 44 586 6450
                    
                  • woynam
                    Another way of saying this is With waterfall, the customer pays for everything they *might* need, and gets it as late as possible. With agile, the customer
                    Message 9 of 12 , Sep 19, 2008
                      Another way of saying this is "With waterfall, the customer pays for
                      everything they *might* need, and gets it as late as possible. With
                      agile, the customer gets what they *really* need, as soon as possible,
                      and likely within one month."

                      Since time == money, the same features now is worth more than the same
                      features later.

                      Mark

                      --- In scrumdevelopment@yahoogroups.com, Peter Stevens <peterstev@...>
                      wrote:
                      >
                      > Hi Bill
                      >
                      > How to handle it in sales? Real Simple: Waterfall is more expensive
                      >
                      <http://www.scrum-breakfast.com/2008/06/waterfall-is-more-expensive-1.html>.

                      > You give the customer what he wants. If he wants a waterfall, he has to
                      > pay for a waterfall.
                      >
                      > Cheers,
                      >
                      > Peter
                      >
                      > William Berger wrote:
                      > >
                      > > While I realize that this forum is about the actual implementing of
                      > > Scrum, I figured many of those who read and respond to these posts
                      > > probably face the issue of sales too.
                      > >
                      > > I'm looking for resources that describe how to sell Scrum projects,
                      > > specifically for consulting or integrator companies.
                      > >
                      > > How does one approach the Scrum discussion in sales? The obvious
                      > > issues would be traditional project control (PMO) and budget.
                      > >
                      > > Any thoughts?
                      > >
                      > > Bill Berger
                      > >
                      > >
                      >
                      >
                      > --
                      > Peter Stevens, CSM, CSP
                      > Scrum Training in German: http://ausbildung.scrum-breakfast.com
                      > http://scrum-breakfast.com
                      > tel: +41 44 586 6450
                      >
                    • Angela Druckman
                      Our clients were thrilled they never needed to complete a Client Change Request again-- With our waterfall projects, every little change had to be covered by
                      Message 10 of 12 , Sep 22, 2008
                        Our clients were thrilled they never needed to complete a Client Change Request again--
                         
                        With our waterfall projects, every little change had to be covered by one of these documents, which then had to be circulated for review and signatures. 
                         
                        Now clients can simply update their Product Backlog between sprints.  As a matter of fact, we encourage them to change the PB as they better know their requirements, so we can be certain we are building the right thing.
                         
                        i think that still freaks them out a little  :)
                         
                              --Angela

                         

                        ----- Original Message ----
                        From: Peter Stevens <peterstev@...>
                        To: scrumdevelopment@yahoogroups.com
                        Sent: Friday, September 19, 2008 9:45:48 AM
                        Subject: Re: [scrumdevelopment] Selling your project

                        Hi Bill

                        How to handle it in sales? Real Simple: Waterfall is more expensive. You give the customer what he wants. If he wants a waterfall, he has to pay for a waterfall.

                        Cheers,

                        Peter

                        William Berger wrote:

                        While I realize that this forum is about the actual implementing of
                        Scrum, I figured many of those who read and respond to these posts
                        probably face the issue of sales too.

                        I'm looking for resources that describe how to sell Scrum projects,
                        specifically for consulting or integrator companies.

                        How does one approach the Scrum discussion in sales? The obvious
                        issues would be traditional project control (PMO) and budget.

                        Any thoughts?

                        Bill Berger



                        -- 
                        Peter Stevens, CSM, CSP
                        Scrum Training in German: http://ausbildung. scrum-breakfast. com
                        http://scrum- breakfast. com
                        tel: +41 44 586 6450
                        

                      • Maurício A. Vernaschi
                        That’s great. Same sensation here. We encourage them to change the PB too, although it always happens through the PO. Conversation (user stories 3C) is
                        Message 11 of 12 , Sep 22, 2008

                          That’s great. Same sensation here.

                           

                          We encourage them to change the PB too, although it always happens through the PO . Conversation (user stories 3C) is always drawn from customers as well.

                           

                          Thus, PMO establish deliverables to the projects in user stories and the project milestones is aligned with the sprints planning calendar.

                           

                          Regards,

                          Maurício A. Vernaschi

                           


                          From: scrumdevelopment@yahoogroups.com [mailto: scrumdevelopment@yahoogroups.com ] On Behalf Of Angela Druckman
                          Sent: segunda-feira, 22 de setembro de 2008 17:54
                          To: scrumdevelopment@yahoogroups.com
                          Subject: Re: [scrumdevelopment] Selling your project

                           

                          Our clients were thrilled they never needed to complete a Client Change Request again--

                           

                          With our waterfall projects, every little change had to be covered by one of these documents, which then had to be circulated for review and signatures. 

                           

                          Now clients can simply update their Product Backlog between sprints.  As a matter of fact, we encourage them to change the PB as they better know their requirements, so we can be certain we are building the right thing.

                           

                          i think that still freaks them out a little  :)

                           

                                --Angela


                           

                           

                          ----- Original Message ----
                          From: Peter Stevens <peterstev@gmail. com>
                          To: scrumdevelopment@ yahoogroups. com
                          Sent: Friday, September 19, 2008 9:45:48 AM
                          Subject: Re: [scrumdevelopment] Selling your project

                          Hi Bill

                          How to handle it in sales? Real Simple: Waterfall is more expensive. You give the customer what he wants. If he wants a waterfall, he has to pay for a waterfall.

                          Cheers,

                          Peter

                          William Berger wrote:

                          While I realize that this forum is about the actual implementing of
                          Scrum, I figured many of those who read and respond to these posts
                          probably face the issue of sales too.

                          I'm looking for resources that describe how to sell Scrum projects,
                          specifically for consulting or integrator companies.

                          How does one approach the Scrum discussion in sales? The obvious
                          issues would be traditional project control (PMO) and budget.

                          Any thoughts?

                          Bill Berger

                           

                          -- 
                          Peter Stevens, CSM, CSP
                          Scrum Training in German: http://ausbildung. scrum-breakfast. com
                          http://scrum- breakfast. com
                          tel: +41 44 586 6450

                           

                        • William Berger
                          I appreciate all the responses to date. I assumed the thread had died. It is great to hear that there are success stories out there for those of us that deal
                          Message 12 of 12 , Sep 22, 2008
                            I appreciate all the responses to date. I assumed the thread had died.

                            It is great to hear that there are success stories out there for those
                            of us that deal with contract, custom software development, especially
                            when dealing with client PMO organizations.

                            I'd love to hear more about the process of starting a Scrum-developed
                            project with a PMO - particularly how the PMO reconciles overall
                            project deliverables (usually contractually set at the start of a
                            project) with the fluid nature of iterative development and changing
                            requirements without change control. I must be missing something
                            fundamental.

                            I've not had time to craft my sales pitch / Scrum story for potential
                            clients. However, I now have a few ideas. I look forward to more
                            insight into Scrum working with traditional PMOs.

                            Regards,
                            Bill Berger
                          Your message has been successfully submitted and would be delivered to recipients shortly.