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

RE: [scrumdevelopment] Company Standards (Was Re:Voting the entire team off the island)

Expand Messages
  • Roy Morien
    On the subject of choice of tools, and company standards etc.... I don t know about everyone else in the world (a difficult thing to know at the best of times)
    Message 1 of 148 , Jul 1, 2008
    • 0 Attachment
      On the subject of choice of tools, and company standards etc....
      I don't know about everyone else in the world (a difficult thing to know at the best of times) but I find the learning curve on some of the more monumental development tool products to be a bit steep. I can't imagine learning Visual Studio 2008 from scratch in a mere few days. I do remember learning the basics of Delphi back in about 1995 in a couple of days (which is what attracted me to that marvellous but severely under-utilised IDE in the first place). But it then took me about another 5 years to really say I was fully competent with the product.
      So the idea that somewhere into the development project the team can make a decision to use a product like Visual Studio even when they have no knowledge of it, seems to me to be ludicrous. I think that a competent, professional team should commence a project with a portfolio of development products that they are well trained in, and well experienced in. Anything less would not be professional or ethical, in my view. You would be holding yourself out as a professional, competent developer when that is not the case.

      Unless, of course, part of the project is understood to include the selection of appropriate tools, and the necessary training and expertise that would be needed.
      I cannot envisage a situation in an organisation where having a set of standard development tools is somehow not proper. I cannot see how it is more 'agile' to leave the decision about development tools until sometime into the project. Obviously over time new development products and environments will become available, and decisions made to adopt them.

      In organisations where contracting to develop systems for external organisations it may be necessary to adopt a new set of development tools for a given project. But the training and learning of that would be included in the contract price. Nonetheless, having a portfolio of well understood tools is still highly desirable if it is within the contract to use them.
      I teach my students that a well positioned development team has the following available before the project is taken on:

      Your Portfolio of Development Tools and Standards

      Before you start development in a project, you should ensure that you have the following in place:

      ·    A detailed understanding and map of the client’s hardware and network architecture.

      ·    A good understanding of the client’s current installed software, database management system, current language and development tools in use.

      ·    Your Design and Coding Standards, including GUI design standards, website standard structures, documentation formats etc.

      ·    Your development tools portfolio; IDE, Report Writer, Data Dictionary, DBMS etc. etc.

      ·    Your libraries of 3rd party functions, procedures, classes etc.

      ·    Your Backup and Archiving plan and appropriate software.

      ·    Your Security Standards, tools, software etc.

      ·    Your plans for creating a Development Environment, a Testing Environment, and know about the client’s Production Environment.

      ·    Software installation manager software, and plan for updating or re-installing the system on the client’s system.

      Is there a problem here that somehow offends the pure agilist?
      Roy Morien 

      To: scrumdevelopment@yahoogroups.com
      From: woyna@...
      Date: Mon, 30 Jun 2008 21:06:00 +0000
      Subject: [scrumdevelopment] Company Standards (Was Re:Voting the entire team off the island)

      The basic premise of Scrum is that it's an empirical process that
      allows the team to improve by identifying and removing impediments.

      However, it sounds like you're suggesting that the team is free to
      choose any tool or approach they like without first demonstrating that
      the "company standard" is in fact an impediment to success.

      I find that quite odd. We warn people about piling too many features
      into a product before knowing that the features are actually useful.
      We say that they should prioritize, and only build the highest
      priority features.

      Shouldn't it be the team's responsibility to demonstrate that an
      existing approach is deficient? Just because something is a standard
      doesn't mean it's not good. Sure, there may be something technically
      better, but is it really better from a business value standpoint?
      What's the cost associated with purchasing, training, and supporting
      multiple tools/frameworks? It doesn't come for free.

      By focusing on optimizing *your* project, you may be guilty of
      suboptimizing the whole organization. You can't look at things in
      isolation, at least not in a large enterprise.


      --- In scrumdevelopment@ yahoogroups. com, Ilja Preuss <it@...> wrote:
      > woynam wrote:
      > > We have anywhere from 20 to 30 teams working in parallel at any given
      > > moment. How would our lives be better if each team selected a
      > > different logging framework? What if they selected a different app
      > > server? How about a different programming language?
      > I don't know. Was someone suggesting that you should do that?
      > > That's simply crazy talk. Someone in our community once said "Doing
      > > agile is not an excuse to be stupid.".
      > I agree that that sounds crazy. I wouldn't want to be in such a
      > situation. And that someone from the community was certainly right.
      > > Seriously, our focus should be on providing business value to our
      > > customers. I don't see how creating a hodge podge software
      > > architecture provides value in the long run.
      > I don't see that either.
      > I also don't see how a company standard that was probably created
      > my project even started could guarantee optimal value creation for my
      > project.
      > > Unlike many folks, I strongly believe there is still a role for
      > > architects in an agile organization. This is especially true in a
      > > large organization. One of the biggest reasons why many organizations
      > > struggle to achieve agility is that their systems are a complete mess.
      > > Everyone doing their own thing. Everyone has a specialty, because
      > > they've created a subsystem using technology that nobody else in the
      > > organization understands.
      > That sounds bad.
      > > I've read about many large organization that have successfully scaled
      > > agile, and almost all of them have a common platform to build upon.
      > "Almost all". Interesting. ..
      > Cheers, Ilja

      Find out: SEEK Salary Centre Are you paid what you're worth?
    • Emiliano Heyns
      On Fri, Jun 27, 2008 at 11:36 PM, Emiliano Heyns
      Message 148 of 148 , Sep 13, 2008
      • 0 Attachment
        On Fri, Jun 27, 2008 at 11:36 PM, Emiliano Heyns <Emiliano.Heyns@...> wrote:
        On Fri, Jun 27, 2008 at 4:42 PM, Ilja Preuss <it@...> wrote:
        Emiliano Heyns wrote:
        > Do I want them to behave differently... that is a very good question. I
        > think (easy to say) I would be OK with a wide variety of behaviors as
        > long as we're showing noticeable progress towards our projects' goal.

        How visible is that progress? How visible is how much needs still to be
        done to reach that goal? Is this reflected in some kind of burn chart
        that the team members believe in?

        I'm beginning to doubt this. We have something like this, but I wonder whether the value of the milestones is adequately explained, which could certainly be an issue for the new member. If not, it could explain a thing or two.

        I've been reading Jean Tabaka's book; I forgot who recommended it to me, but here's a heart-felt thank you to whoever did. I've found "a thing or two" that I should have handled very, very differently. So my apologies to this group, after the apologies already rendered to my team. We're not at the performing stage yet, but in a lot better shape than we were.

        Thanks all,

      Your message has been successfully submitted and would be delivered to recipients shortly.