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

Re: [scrumdevelopment] How to have a conversation about Agile with the CFO?

Expand Messages
  • John Goodsen
    Lately, I ve been borrowing more from Lean thinking than Scrum for the CxO conversations I like to feel them out if they understand the difference between cost
    Message 1 of 17 , Aug 18, 2010
    • 0 Attachment
      Lately, I've been borrowing more from Lean thinking than Scrum for the CxO conversations 

      I like to feel them out if they understand the difference between cost and throughput accounting, first, and then understand which model they are using.  If it's the latter, you are on solid ground.  If it's the former, then you have more work ahead of you.  

      The follow-on conversation is about the cost of WIP, the cost of Delay and the value of Limiting WIP to establish flow.  You might draw an ROI over Time chart that compares to traditional development showing short, frequent releases do not require as deep of an initial captial investment before you see a return. 

      If that ROI chart description is not clear, I can post a picture of it.

      John

      On Wed, Aug 18, 2010 at 1:30 PM, <drc@...> wrote:



      I'm about to have a meeting with the CFO of the company where I'm supporting a scrum adoption.

      I'm curious what you think might be interesting or important questions or concerns to raise with her as part of that conversation?

      What has been your experience with making the advantages (and disadvantages) of scrum visible to the "C" level folks in your organization?

      Thanks in advance for your comments and thoughts!

      -- David Chilcott
      Outformations, Inc.

      Keep Breathing.  Tell the Truth.  Be Fearless.  Choose Love.   Embrace the Mystery.
      ---------------------------------------------------------------------------
      Email: drc@...
      Voice: 510.655.7122
      Skype: DavidChilcott
      Twitter: DavidChilcott
      Facebook: www.facebook.com/DavidRChilcott
      LinkedIn: www.linkedin.com/in/DavidChilcott  
      ----------------------------------------------------------------------------
      Ask me about the Outformations Agile Enterprise JumpStart
      http://bit.ly/AgileJumpStart
      ----------------------------------------------------------------------------






      --
      John Goodsen                 RADSoft / Better Software Faster
      jgoodsen@...            Lean/Agile/XP/Scrum Coaching and Training
      http://www.radsoft.com          Ruby on Rails and Java Solutions
    • drc@outformations.com
      Thanks John... Please do post or forward your ROI chart/picture... that would be very helpful... D ;-) -- David Chilcott Outformations, Inc. Keep Breathing.
      Message 2 of 17 , Aug 18, 2010
      • 0 Attachment

        Thanks John...

        Please do post or forward your ROI chart/picture...  that would be very helpful...

        D ;-)

        -- David Chilcott
        Outformations, Inc.

        Keep Breathing.  Tell the Truth.  Be Fearless.  Choose Love.   Embrace the Mystery.
        ---------------------------------------------------------------------------
        Email: drc@...
        Voice: 510.655.7122
        Skype: DavidChilcott
        Twitter: DavidChilcott
        Facebook: www.facebook.com/DavidRChilcott
        LinkedIn: www.linkedin.com/in/DavidChilcott  
        ----------------------------------------------------------------------------
        Ask me about the Outformations Agile Enterprise JumpStart
        http://bit.ly/AgileJumpStart
        ----------------------------------------------------------------------------




        John Goodsen <jgoodsen@...>
        Sent by: scrumdevelopment@yahoogroups.com

        08/18/2010 10:46 AM

        Please respond to
        scrumdevelopment@yahoogroups.com

        To
        scrumdevelopment@yahoogroups.com
        cc
        Subject
        Re: [scrumdevelopment] How to have a conversation about Agile with the CFO?





         

        Lately, I've been borrowing more from Lean thinking than Scrum for the CxO conversations 

        I like to feel them out if they understand the difference between cost and throughput accounting, first, and then understand which model they are using.  If it's the latter, you are on solid ground.  If it's the former, then you have more work ahead of you.  

        The follow-on conversation is about the cost of WIP, the cost of Delay and the value of Limiting WIP to establish flow.  You might draw an ROI over Time chart that compares to traditional development showing short, frequent releases do not require as deep of an initial captial investment before you see a return. 

        If that ROI chart description is not clear, I can post a picture of it.

        John

        On Wed, Aug 18, 2010 at 1:30 PM, <drc@...> wrote:



        I'm about to have a meeting with the CFO of the company where I'm supporting a scrum adoption.


        I'm curious what you think might be interesting or important questions or concerns to raise with her as part of that conversation?


        What has been your experience with making the advantages (and disadvantages) of scrum visible to the "C" level folks in your organization?


        Thanks in advance for your comments and thoughts!


        -- David Chilcott
        Outformations, Inc.

        Keep Breathing.  Tell the Truth.  Be Fearless.  Choose Love.   Embrace the Mystery.
        ---------------------------------------------------------------------------
        Email:
        drc@...
        Voice: 510.655.7122
        Skype: DavidChilcott
        Twitter: DavidChilcott
        Facebook:
        www.facebook.com/DavidRChilcott
        LinkedIn:
        www.linkedin.com/in/DavidChilcott  
        ----------------------------------------------------------------------------
        Ask me about the Outformations Agile Enterprise JumpStart

        http://bit.ly/AgileJumpStart
        ----------------------------------------------------------------------------






        --
        John Goodsen                 RADSoft / Better Software Faster

        jgoodsen@...            Lean/Agile/XP/Scrum Coaching and Training
        http://www.radsoft.com          Ruby on Rails and Java Solutions


      • petriheiramo
        Hi Dave, ... By sufficient skill and understanding I was referring more to their Agile practices skills, not domain or technology skills. I ve seen lots of
        Message 3 of 17 , Aug 19, 2010
        • 0 Attachment
          Hi Dave,


          > I have yet to meet a developer that has "sufficient skill and
          > understanding" to actually build good, working systems that doesn't have
          > "sufficient skill and understanding to cut through unnecessary details,
          > look at the very core of things" and act sensibly. If only you'll let
          > them.

          By "sufficient skill and understanding" I was referring more to their Agile practices skills, not domain or technology skills. I've seen lots of people who are very good at the latter, but virtually lack the former. Yes, they can build the system, but they are very influenced by their past development practices. Of course, if they want to embrace Agile, they have the capacity to learn fast.

          And sometimes even those guys get thrown into a project with a lot of new things to them, while they are expected to use Scrum, which is also new to them. In these environments, it may be sometimes useful to give a bit more time to "get their bearings" before committing to delivery.

          None of that means that I wouldn't generally try to limit the preliminary "pre-game" period to the minimum.


          Yours Sincerely, Petri

          --- In scrumdevelopment@yahoogroups.com, David A Barrett <dave.barrett@...> wrote:
          >
          > >> > I personally think there is too much "just get going" attitude in
          > >> > Agile culture. It works in some environments, with some teams.
          > >>
          > >> Yes, it works for those teams that think as they're doing.
          > >
          > >Yes, indeed, who have the sufficient skill and understanding to cut
          > through
          > > unnecessary details, look at the very core of things, identify the first
          > > things to try sensibly and have the skills to evolve the architecture
          > >as they develop the system.
          > >
          > >Recommending that approach to a team who is new to Agile and
          > >the techniques is a bit irresponsible, in my opinion, because so many
          > >new teams "get going" too fast and stumble not long after. Then they
          > >say "Agile doesn't work, because...". So it pays to do a bit more
          > >preliminary research and extra thinking (supported, of course, by a
          > >coach, I hope, who can advice them appropriately away from
          > > too-much-thinking), before getting to action.
          >
          > I have to admit that I had a strong (negative) visceral reaction to this
          > post.
          >
          > All of us were new to Agile at some point, and some of us were doing it
          > when it felt like no one else we knew was doing it. So we didn't have the
          > experiences of others to guide us as we figured out what it was all about
          > and how to make it work for us.
          >
          > And yes, we made mistakes. Lots of mistakes. But even with mistakes it
          > was better than what we were doing before, so our customers still came out
          > winners. We were still felt like we were succeeding.
          >
          > I have yet to meet a developer that has "sufficient skill and
          > understanding" to actually build good, working systems that doesn't have
          > "sufficient skill and understanding to cut through unnecessary details,
          > look at the very core of things" and act sensibly. If only you'll let
          > them.
          >
          >
          >
          >
          > Dave Barrett
          >
          >
          > This e-mail may be privileged and/or confidential, and the sender does not
          > waive any related rights and obligations. Any distribution, use or copying
          > of this e-mail or the information it contains by other than an intended
          > recipient is unauthorized. If you received this e-mail in error, please
          > delete it and advise me (by return e-mail or otherwise) immediately.
          >
          > Ce courrier électronique est confidentiel et protégé. L'expéditeur ne
          > renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion,
          > utilisation ou copie de ce message ou des renseignements qu'il contient
          > par une personne autre que le (les) destinataire(s) désigné(s) est
          > interdite. Si vous recevez ce courrier électronique par erreur, veuillez
          > le supprimer et m'en aviser immédiatement, par retour de courrier
          > électronique ou par un autre moyen.
          >
        • Steve Ropa
          I m interested in the idea of cap vs expense in that scenario... I can t think of a ton there, except perhaps that defect work is often expensed, while
          Message 4 of 17 , Aug 19, 2010
          • 0 Attachment
            I'm interested in the idea of cap vs expense in that scenario...  I can't think of a ton there, except perhaps that defect work is often expensed, while initial development can be capitalized.  Perhaps since we are spending more effort on high quality development with agile practices, we don't have to spend as much time on defects, thus being able to capitalize the work.  I'm not 100% sure of the validity of this though.  Interestingly, the last company I was worrying about this with had actually been trying to find a way to minimize cap and maximize expenditures.  I still don't get why they wanted to, but there it is.

            Sent: Wednesday, August 18, 2010 11:40 AM
            Subject: Re: [scrumdevelopment] How to have a conversation about Agile with the CFO?

             

            Excellent question, David! I don't think I've seen a post about pitching to the CFO

            on this list.

            My thoughts go to pure business benefit for the CFO:
            • the date moves up for putting the investment into service in Agile with its more frequent deployments; it would be great if you could take in two NPV (net present value) scenarios for a waterfall vs. Agile project to illustrate this point and the resultant savings
            • the ability to stop even successful projects when they are past the steep part of their value realization curve creates greater overall enterprise value realization; again a comparison scenario would be great, even if its just a hand-drawing (which is what I typically do)
            • capitalization vs. expense benefits in terms of how the investment of Agile projects is accounted for in the company's books vs. waterfall projects; I have heard finance people talk about this but am not expert enough to tell you the details
            • lower turnover on Agile teams leads to lower training and hiring costs (I have seen this lower turnover to be true, but don't have a published reference, though someone else probably does)
            That's off the top. 

            Best,
            Michael
            -- 
            Collective Edge Coaching, llc
            "Helping teams to perform, and organizations to transform."
            www.collective-edge.com
            Michael K. Spayd, Principal & Chief Sage, ORSCC
            (720) 300.5286  - (USA)
            michael@...


            On Wed, Aug 18, 2010 at 11:30 AM, <drc@...> wrote:
             


            I'm about to have a meeting with the CFO of the company where I'm supporting a scrum adoption.

            I'm curious what you think might be interesting or important questions or concerns to raise with her as part of that conversation?

            What has been your experience with making the advantages (and disadvantages) of scrum visible to the "C" level folks in your organization?

            Thanks in advance for your comments and thoughts!

            -- David Chilcott
            Outformations, Inc.

            Keep Breathing.  Tell the Truth.  Be Fearless.  Choose Love.   Embrace the Mystery.
            ---------------------------------------------------------------------------
            Email: drc@...
            Voice: 510.655.7122
            Skype: DavidChilcott
            Twitter: DavidChilcott
            Facebook: www.facebook.com/DavidRChilcott
            LinkedIn: www.linkedin.com/in/DavidChilcott  
            ----------------------------------------------------------------------------
            Ask me about the Outformations Agile Enterprise JumpStart
            http://bit.ly/AgileJumpStart
            ----------------------------------------------------------------------------





          • barrettdab
            Petri, Not to put too fine a point on it, but what you said was, Yes, indeed, who have the sufficient skill and understanding to cut through unnecessary
            Message 5 of 17 , Aug 19, 2010
            • 0 Attachment
              Petri,

              Not to put too fine a point on it, but what you said was, "Yes, indeed, who have the sufficient skill and understanding to cut through
              unnecessary details, look at the very core of things, identify the first things to try sensibly and have the skills to evolve the architecture as they develop the system."

              There's nothing specifically Agile in any of that. That's just plain, old-fashioned critical thinking. Vital for programmers of any ilk and, yes, vital for Agile practitioners too.

              My point was that good programmers have those skills already, and there's no reason to believe that they wouldn't apply them to implementing Agile.

              Dave

              --- In scrumdevelopment@yahoogroups.com, "petriheiramo" <petri.heiramo@...> wrote:
              >
              > Hi Dave,
              >
              >
              > > I have yet to meet a developer that has "sufficient skill and
              > > understanding" to actually build good, working systems that doesn't have
              > > "sufficient skill and understanding to cut through unnecessary details,
              > > look at the very core of things" and act sensibly. If only you'll let
              > > them.
              >
              > By "sufficient skill and understanding" I was referring more to their Agile practices skills, not domain or technology skills. I've seen lots of people who are very good at the latter, but virtually lack the former. Yes, they can build the system, but they are very influenced by their past development practices. Of course, if they want to embrace Agile, they have the capacity to learn fast.
            • John Goodsen
              ... there s no rocket science going on here, but hope this helps: http://leanthinkingyoursoftware.blogspot.com/2010/08/how-deep-are-your-pockets.html -- John
              Message 6 of 17 , Aug 19, 2010
              • 0 Attachment
                On Wed, Aug 18, 2010 at 1:51 PM, <drc@...> wrote:

                Please do post or forward your ROI chart/picture...  that would be very helpful...


                there's no rocket science going on here, but hope this helps:


                --
                John Goodsen                 RADSoft / Better Software Faster
                jgoodsen@...            Lean/Agile/XP/Scrum Coaching and Training
                http://www.radsoft.com          Ruby on Rails and Java Solutions
              • Michael Spayd
                Hi Steve, I m not sure if you are in part referring to my post, replying in any case... I realize this is different with different clients and their
                Message 7 of 17 , Aug 19, 2010
                • 0 Attachment
                  Hi Steve,

                  I'm not sure if you are in part referring to my post, replying in any case...

                  I realize this is different with different clients and their interpretations of GAAP,
                  but what I have seen in clients is that they believe they need to treat waterfall
                  development one way, where requirements gathering and even design do not
                  count as part of the product (I assume to capitalize it, but I'm not sure) whereas
                  development and testing do. In Agile, because you can deploy something quite
                  quickly, more/all of the work can be counted in this way. The finance people
                  were quite happy about this, after they got over their being stuck in the old
                  way as the only way.

                  I hope that is helpful.

                  Michael

                  -- 
                  Collective Edge Coaching, llc
                  "Helping teams to perform, and organizations to transform."
                  www.collective-edge.com
                  Michael K. Spayd, Principal & Chief Sage, ORSCC
                  (720) 300.5286  - (USA)
                  michael@...


                  On Thu, Aug 19, 2010 at 8:20 AM, Steve Ropa <theropas@...> wrote:
                   

                  I'm interested in the idea of cap vs expense in that scenario...  I can't think of a ton there, except perhaps that defect work is often expensed, while initial development can be capitalized.  Perhaps since we are spending more effort on high quality development with agile practices, we don't have to spend as much time on defects, thus being able to capitalize the work.  I'm not 100% sure of the validity of this though.  Interestingly, the last company I was worrying about this with had actually been trying to find a way to minimize cap and maximize expenditures.  I still don't get why they wanted to, but there it is.

                  Sent: Wednesday, August 18, 2010 11:40 AM
                  Subject: Re: [scrumdevelopment] How to have a conversation about Agile with the CFO?

                   

                  Excellent question, David! I don't think I've seen a post about pitching to the CFO

                  on this list.

                  My thoughts go to pure business benefit for the CFO:
                  • the date moves up for putting the investment into service in Agile with its more frequent deployments; it would be great if you could take in two NPV (net present value) scenarios for a waterfall vs. Agile project to illustrate this point and the resultant savings
                  • the ability to stop even successful projects when they are past the steep part of their value realization curve creates greater overall enterprise value realization; again a comparison scenario would be great, even if its just a hand-drawing (which is what I typically do)
                  • capitalization vs. expense benefits in terms of how the investment of Agile projects is accounted for in the company's books vs. waterfall projects; I have heard finance people talk about this but am not expert enough to tell you the details
                  • lower turnover on Agile teams leads to lower training and hiring costs (I have seen this lower turnover to be true, but don't have a published reference, though someone else probably does)
                  That's off the top. 

                  Best,
                  Michael
                  -- 
                  Collective Edge Coaching, llc
                  "Helping teams to perform, and organizations to transform."
                  www.collective-edge.com
                  Michael K. Spayd, Principal & Chief Sage, ORSCC
                  (720) 300.5286  - (USA)
                  michael@...


                  On Wed, Aug 18, 2010 at 11:30 AM, <drc@...> wrote:
                   


                  I'm about to have a meeting with the CFO of the company where I'm supporting a scrum adoption.

                  I'm curious what you think might be interesting or important questions or concerns to raise with her as part of that conversation?

                  What has been your experience with making the advantages (and disadvantages) of scrum visible to the "C" level folks in your organization?

                  Thanks in advance for your comments and thoughts!

                  -- David Chilcott
                  Outformations, Inc.

                  Keep Breathing.  Tell the Truth.  Be Fearless.  Choose Love.   Embrace the Mystery.
                  ---------------------------------------------------------------------------
                  Email: drc@...
                  Voice: 510.655.7122
                  Skype: DavidChilcott
                  Twitter: DavidChilcott
                  Facebook: www.facebook.com/DavidRChilcott
                  LinkedIn: www.linkedin.com/in/DavidChilcott  
                  ----------------------------------------------------------------------------
                  Ask me about the Outformations Agile Enterprise JumpStart
                  http://bit.ly/AgileJumpStart
                  ----------------------------------------------------------------------------









                • petriheiramo
                  Hi Dave, ... Well, not all architect level people have that skill. They have the skills to create complicated architectures, so they create them. Not all of
                  Message 8 of 17 , Aug 19, 2010
                  • 0 Attachment
                    Hi Dave,


                    > Not to put too fine a point on it, but what you said was, "Yes, indeed, who have the sufficient skill and understanding to cut through
                    > unnecessary details, look at the very core of things, identify the first things to try sensibly and have the skills to evolve the architecture as they develop the system."
                    >
                    > There's nothing specifically Agile in any of that. That's just plain, old-fashioned critical thinking. Vital for programmers of any ilk and, yes, vital for Agile practitioners too.
                    >
                    > My point was that good programmers have those skills already, and there's no reason to believe that they wouldn't apply them to implementing Agile.

                    Well, not all architect level people have that skill. They have the skills to create complicated architectures, so they create them. Not all of them have the mindset to focus on right things from Agile perspective. Of course, you might not call them "good".

                    AND I was not referring to technical skill, although that, too, is necessary. Also, not all people think "critically" the same way; people disagree what the core issues could be.

                    All you have to do is to listen to traditional architects who defiantly claim that they just have to design the whole architecture first (or the sky will fall), and you know there is skill and knowledge involved in being able to do Agile design.


                    Yours Sincerely, Petri
                  • David A Barrett
                    Back to the original topic: It occurs to me that, regardless of your project management methodology, any non-trivial computer system that you develop is
                    Message 9 of 17 , Aug 20, 2010
                    • 0 Attachment
                      Back to the original topic:  It occurs to me that, regardless of your project management methodology, any non-trivial computer system that you develop is either going to involve "emergent design" or you're going to deliver the wrong product.

                      So you might as well embrace the emergent design approach from the start.



                      Dave Barrett


                      This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please delete it and advise me (by return e-mail or otherwise) immediately.

                      Ce courrier électronique est confidentiel et protégé. L'expéditeur ne renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) désigné(s) est interdite. Si vous recevez ce courrier électronique par erreur, veuillez le supprimer et m'en aviser immédiatement, par retour de courrier électronique ou par un autre moyen.
                    • George Dinwiddie
                      Petri ... In my experience, it s the architects who no longer code who do this. ... Isn t that the point? People can argue about models until the cows come
                      Message 10 of 17 , Aug 20, 2010
                      • 0 Attachment
                        Petri

                        On 8/20/10 3:28 AM, petriheiramo wrote:
                        > Hi Dave,
                        >
                        >
                        >> Not to put too fine a point on it, but what you said was, "Yes,
                        >> indeed, who have the sufficient skill and understanding to cut
                        >> through unnecessary details, look at the very core of things,
                        >> identify the first things to try sensibly and have the skills to
                        >> evolve the architecture as they develop the system."
                        >>
                        >> There's nothing specifically Agile in any of that. That's just
                        >> plain, old-fashioned critical thinking. Vital for programmers of
                        >> any ilk and, yes, vital for Agile practitioners too.
                        >>
                        >> My point was that good programmers have those skills already, and
                        >> there's no reason to believe that they wouldn't apply them to
                        >> implementing Agile.
                        >
                        > Well, not all architect level people have that skill. They have the
                        > skills to create complicated architectures, so they create them. Not
                        > all of them have the mindset to focus on right things from Agile
                        > perspective. Of course, you might not call them "good".

                        In my experience, it's the architects who no longer code who do this.

                        > AND I was not referring to technical skill, although that, too, is
                        > necessary. Also, not all people think "critically" the same way;
                        > people disagree what the core issues could be.

                        Isn't that the point? People can argue about models until the cows come
                        home. Trying an experiment gives them information that guides the
                        discussion. It give bounds when it shows that an approach isn't feasible.

                        > All you have to do is to listen to traditional architects who
                        > defiantly claim that they just have to design the whole architecture
                        > first (or the sky will fall), and you know there is skill and
                        > knowledge involved in being able to do Agile design.

                        Yes, and that skill and knowledge comes from practice, not from
                        continuing to do the same thing (design without code).

                        As you probably know, many of those "whole architectures designed first"
                        turn out to be really terrible when you try to implement them. Other
                        places, they're not understood or ignored by the developers anyway.

                        - George

                        --
                        ----------------------------------------------------------------------
                        * George Dinwiddie * http://blog.gdinwiddie.com
                        Software Development http://www.idiacomputing.com
                        Consultant and Coach http://www.agilemaryland.org
                        ----------------------------------------------------------------------
                      • Steve Ropa
                        Thanks Michael, I was indeed referring to your comments about capitalization vs. expense benefits. I hadn t thought about the fact that requirements gathering
                        Message 11 of 17 , Aug 20, 2010
                        • 0 Attachment
                          Thanks Michael,
                           
                          I was indeed referring to your comments about capitalization vs. expense benefits.  I hadn't thought about the fact that requirements gathering and design don't count as capitalizeable expenditures.

                          Sent: Thursday, August 19, 2010 12:08 PM
                          Subject: Re: [scrumdevelopment] How to have a conversation about Agile with the CFO?

                           

                          Hi Steve,


                          I'm not sure if you are in part referring to my post, replying in any case...

                          I realize this is different with different clients and their interpretations of GAAP,
                          but what I have seen in clients is that they believe they need to treat waterfall
                          development one way, where requirements gathering and even design do not
                          count as part of the product (I assume to capitalize it, but I'm not sure) whereas
                          development and testing do. In Agile, because you can deploy something quite
                          quickly, more/all of the work can be counted in this way. The finance people
                          were quite happy about this, after they got over their being stuck in the old
                          way as the only way.

                          I hope that is helpful.

                          Michael

                          -- 
                          Collective Edge Coaching, llc
                          "Helping teams to perform, and organizations to transform."
                          www.collective-edge.com
                          Michael K. Spayd, Principal & Chief Sage, ORSCC
                          (720) 300.5286  - (USA)
                          michael@...


                          On Thu, Aug 19, 2010 at 8:20 AM, Steve Ropa <theropas@...> wrote:
                           

                          I'm interested in the idea of cap vs expense in that scenario...  I can't think of a ton there, except perhaps that defect work is often expensed, while initial development can be capitalized.  Perhaps since we are spending more effort on high quality development with agile practices, we don't have to spend as much time on defects, thus being able to capitalize the work.  I'm not 100% sure of the validity of this though.  Interestingly, the last company I was worrying about this with had actually been trying to find a way to minimize cap and maximize expenditures.  I still don't get why they wanted to, but there it is.

                          Sent: Wednesday, August 18, 2010 11:40 AM
                          Subject: Re: [scrumdevelopment] How to have a conversation about Agile with the CFO?

                           

                          Excellent question, David! I don't think I've seen a post about pitching to the CFO

                          on this list.

                          My thoughts go to pure business benefit for the CFO:
                          • the date moves up for putting the investment into service in Agile with its more frequent deployments; it would be great if you could take in two NPV (net present value) scenarios for a waterfall vs. Agile project to illustrate this point and the resultant savings
                          • the ability to stop even successful projects when they are past the steep part of their value realization curve creates greater overall enterprise value realization; again a comparison scenario would be great, even if its just a hand-drawing (which is what I typically do)
                          • capitalization vs. expense benefits in terms of how the investment of Agile projects is accounted for in the company's books vs. waterfall projects; I have heard finance people talk about this but am not expert enough to tell you the details
                          • lower turnover on Agile teams leads to lower training and hiring costs (I have seen this lower turnover to be true, but don't have a published reference, though someone else probably does)
                          That's off the top. 

                          Best,
                          Michael
                          -- 
                          Collective Edge Coaching, llc
                          "Helping teams to perform, and organizations to transform."
                          www.collective-edge.com
                          Michael K. Spayd, Principal & Chief Sage, ORSCC
                          (720) 300.5286  - (USA)
                          michael@...


                          On Wed, Aug 18, 2010 at 11:30 AM, <drc@...> wrote:
                           


                          I'm about to have a meeting with the CFO of the company where I'm supporting a scrum adoption.

                          I'm curious what you think might be interesting or important questions or concerns to raise with her as part of that conversation?

                          What has been your experience with making the advantages (and disadvantages) of scrum visible to the "C" level folks in your organization?

                          Thanks in advance for your comments and thoughts!

                          -- David Chilcott
                          Outformations, Inc.

                          Keep Breathing.  Tell the Truth.  Be Fearless.  Choose Love.   Embrace the Mystery.
                          ---------------------------------------------------------------------------
                          Email: drc@...
                          Voice: 510.655.7122
                          Skype: DavidChilcott
                          Twitter: DavidChilcott
                          Facebook: www.facebook.com/DavidRChilcott
                          LinkedIn: www.linkedin.com/in/DavidChilcott  
                          ----------------------------------------------------------------------------
                          Ask me about the Outformations Agile Enterprise JumpStart
                          http://bit.ly/AgileJumpStart
                          ----------------------------------------------------------------------------









                        • Jeff Anderson
                          I m a big fan of ambler s AMM book, in a nutshell, some form of modeling takes place on agile teams, wether on a white board, sticky notes, or UML. At the
                          Message 12 of 17 , Aug 26, 2010
                          • 0 Attachment
                            I'm a big fan of ambler's AMM book, in a nutshell, some form of
                            modeling takes place on agile teams, wether on a white board, sticky
                            notes, or UML.

                            At the start of projects I favour the sticky notes and white boards,
                            it facilitates the collaboration you need to get understanding and
                            shared knowledge, which is one of the primary reasons to model.

                            Later on as models begin to settle (they never fully settle) I might
                            use electronic tools so that models can reach a wider audience, but
                            not always sometimes a picture on a wiki will do.

                            I think about 20 percent of my modeling happens up front, enough to
                            get scope, platform, some inclination of the business domain but 80
                            percent is emergent, it is done as part of delivery, and is always
                            changing.

                            Another great modeling book that I think agile enthusiasts should read
                            is domain driven design, It talks about using models to add focus to
                            discussions around business logic, and how those models should
                            religiously reflect implementation, so as to stay relevant and easy to
                            maintain.

                            On 8/20/10, George Dinwiddie <lists@...> wrote:
                            > Petri
                            >
                            > On 8/20/10 3:28 AM, petriheiramo wrote:
                            >> Hi Dave,
                            >>
                            >>
                            >>> Not to put too fine a point on it, but what you said was, "Yes,
                            >>> indeed, who have the sufficient skill and understanding to cut
                            >>> through unnecessary details, look at the very core of things,
                            >>> identify the first things to try sensibly and have the skills to
                            >>> evolve the architecture as they develop the system."
                            >>>
                            >>> There's nothing specifically Agile in any of that. That's just
                            >>> plain, old-fashioned critical thinking. Vital for programmers of
                            >>> any ilk and, yes, vital for Agile practitioners too.
                            >>>
                            >>> My point was that good programmers have those skills already, and
                            >>> there's no reason to believe that they wouldn't apply them to
                            >>> implementing Agile.
                            >>
                            >> Well, not all architect level people have that skill. They have the
                            >> skills to create complicated architectures, so they create them. Not
                            >> all of them have the mindset to focus on right things from Agile
                            >> perspective. Of course, you might not call them "good".
                            >
                            > In my experience, it's the architects who no longer code who do this.
                            >
                            >> AND I was not referring to technical skill, although that, too, is
                            >> necessary. Also, not all people think "critically" the same way;
                            >> people disagree what the core issues could be.
                            >
                            > Isn't that the point? People can argue about models until the cows come
                            > home. Trying an experiment gives them information that guides the
                            > discussion. It give bounds when it shows that an approach isn't feasible.
                            >
                            >> All you have to do is to listen to traditional architects who
                            >> defiantly claim that they just have to design the whole architecture
                            >> first (or the sky will fall), and you know there is skill and
                            >> knowledge involved in being able to do Agile design.
                            >
                            > Yes, and that skill and knowledge comes from practice, not from
                            > continuing to do the same thing (design without code).
                            >
                            > As you probably know, many of those "whole architectures designed first"
                            > turn out to be really terrible when you try to implement them. Other
                            > places, they're not understood or ignored by the developers anyway.
                            >
                            > - George
                            >
                            > --
                            > ----------------------------------------------------------------------
                            > * George Dinwiddie * http://blog.gdinwiddie.com
                            > Software Development http://www.idiacomputing.com
                            > Consultant and Coach http://www.agilemaryland.org
                            > ----------------------------------------------------------------------
                            >
                            >

                            --
                            Sent from my mobile device

                            Jeff Anderson

                            http://agileconsulting.blogspot.com/
                          Your message has been successfully submitted and would be delivered to recipients shortly.