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

Re: Thoughts on use of explicit Agile Modeling vs "emergent design"

Expand Messages
  • alexis.hui@gmail.com
    Recommend reading Scott Amblers Agile Modeling Method if you haven t already. Discusses an agile way to do this. Also, being light on the modeling notation is
    Message 1 of 17 , Aug 16, 2010
      Recommend reading Scott Amblers Agile Modeling Method if you haven't already. Discusses an agile way to do this. Also, being light on the modeling notation is a good idea (CRCs are helpful and so is Martin Fowlers UML distilled).

      Depending on the size of the project and complexity I will do more upfront modeling or not. In the spirit of agile, I find we model if "we" need to understand something together. Often, it becomes clear that the team needs some upfront modeling as you notice people speaking different languages or churn happens during planning or story writing. The key is on understanding vs specifying.

      Recommend spending at least an hour doing this with the team except for the most trivial of projects.

      -Alexis Hui
      www.agileconsulting.blogspot.com
      Sent on the TELUS Mobility network with BlackBerry
    • Roy Morien
      I firmly believe that you can start modelling of the database, and development of the database, as soon as you have identified the first entity. That is, if
      Message 2 of 17 , Aug 16, 2010
        I firmly believe that you can start modelling of the database, and development of the database, as soon as you have identified the first entity. That is, if you do ER Modelling properly, and accept the notion that the Conceptual Model, presented as an ER Model, can be evolved, and changes to the resultant database schema can in most cases be accomplished very simply and easily. I would suggest that taking an OO approach would also enable evolving and incrementing the database.
         
        Frankly, I do not think size is a factor in this. In fact, if I would acknowledge size as a factor, it would be to say that the bigger and potentially more complex the database schema is going to be, the more you should lean (excuse the pun!) towards evolving the schema.
         
        I personally feel that in the main UML is too complex and tries to cover every aspect of modelling, and is too cumbersome to use. User Stories are much more lightweight than Use Cases, and by analysing User Stories one by one you can quite reasonably come to design and development decisions without even consaidering the use of UML and Use Cases.
         
        Regards,
        Roy Morien
         

        To: scrumdevelopment@yahoogroups.com
        From: alexis.hui@...
        Date: Mon, 16 Aug 2010 11:51:03 +0000
        Subject: [scrumdevelopment] Re: Thoughts on use of explicit Agile Modeling vs "emergent design"

         
        Recommend reading Scott Amblers Agile Modeling Method if you haven't already. Discusses an agile way to do this. Also, being light on the modeling notation is a good idea (CRCs are helpful and so is Martin Fowlers UML distilled).

        Depending on the size of the project and complexity I will do more upfront modeling or not. In the spirit of agile, I find we model if "we" need to understand something together. Often, it becomes clear that the team needs some upfront modeling as you notice people speaking different languages or churn happens during planning or story writing. The key is on understanding vs specifying.

        Recommend spending at least an hour doing this with the team except for the most trivial of projects.

        -Alexis Hui
        www.agileconsulting.blogspot.com
        Sent on the TELUS Mobility network with BlackBerry

      • David A Barrett
        ... through ... 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
        Message 3 of 17 , Aug 18, 2010
          >> > 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.
        • drc@outformations.com
          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
          Message 4 of 17 , Aug 18, 2010

            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
            ----------------------------------------------------------------------------

          • Michael Spayd
            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
            Message 5 of 17 , Aug 18, 2010
              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
              ----------------------------------------------------------------------------





            • 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 6 of 17 , Aug 18, 2010
                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 7 of 17 , Aug 18, 2010

                  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 8 of 17 , Aug 19, 2010
                    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 9 of 17 , Aug 19, 2010
                      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 10 of 17 , Aug 19, 2010
                        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 11 of 17 , Aug 19, 2010
                          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 12 of 17 , Aug 19, 2010
                            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 13 of 17 , Aug 19, 2010
                              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 14 of 17 , Aug 20, 2010
                                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 15 of 17 , Aug 20, 2010
                                  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 16 of 17 , Aug 20, 2010
                                    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 17 of 17 , Aug 26, 2010
                                      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.