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

RE: [XP] dev ops split?

Expand Messages
  • Amir Kolsky
    Hello Otto, I would recommend you guys create a skills matrix. Put it in a prominent place so everyone knows what the skills are. Every story(task) should be
    Message 1 of 6 , Apr 26, 2012
      Hello Otto,

      I would recommend you guys create a skills matrix. Put it in a prominent
      place so everyone knows what the skills are.

      Every story(task) should be assigned to a specific skill level and people
      can freely pick and choose from what they are skilled to work on.

      Every member is expected to raise their skill level over time - it is up to
      management to determine how fast that should happen, as the faster the skill
      raising the slower the actual development.

      The raising of the skill level has a positive benefit on the overall team
      health so it has a business value in and of itself. The mechanism whereby
      the skill is raised could be by working alone, pairing, training, reviewing,


      From: extremeprogramming@yahoogroups.com
      [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Otto Behrens
      Sent: Tuesday, April 24, 2012 7:56 AM
      To: extremeprogramming
      Subject: [XP] dev ops split?


      In our team (of 7 developers) we handle development and operations
      (system admin, infrastructure). Some people tend to prefer more
      technical tasks and others prefer application development and some
      like both. We've always encouraged people who avoid tasks to take it
      and learn things (we do pair, but not always).

      But it feels as if we are working ineffectively. The diversity of
      things seem to be too much. It ranges from understanding a reasonably
      intricate problem domain, enhancing frameworks, scripting deployments
      and running machines. It feels as if we need some focus in particular
      topics. Firstly, just to get some depth into an area and secondly to
      do less context switching. We break down the project into small bits
      and touching on the bits all over just makes it difficult to really
      get to know something well and to do it really well.

      The other dilemma is that we battle to get the priority on more
      technical issues right. The customer do not want to prioritise stuff
      that he does not see a functional benefit for. Although he expects the
      system to run smoothly, us to deliver frequently and nobody to hack
      the system.

      Do you also have this prioritisation challenge? How do you handle it?

      I'm scared to change this, perhaps because I personally like the
      diversity of tasks. Secondly, I don't like key man dependencies. An
      option is to split the team into "dev ops" and "application
      development", which will certainly give focus to certain areas and
      reduce the diversity of technical stuff you have to contend with.

      Do you split your development team into separate disciplines?

      Thanks for your help

      Some background, if you need more context:

      We work in a agile team of around 10 people, doing most of the XP
      practices (some better than others). One of these people can be seen
      as the on-site customer, another the product owner (deciding which
      tasks take priority between the customers, I suppose an on site
      customer himself). We develop web based systems for multiple

      One person is dedicated to testing, automating tests with selenium
      IDE. We write unit tests (first) and have reasonable test coverage. We
      deploy (mostly) weekly to production.

      We've got all tasks listed in one project, which we manage on
      pivotaltracker. Any of the 6 developers can take a task from the list,
      preferably from the top of the list. From a development perspective,
      we are quite cross functional. The task could be
      - a bug,
      - something technical like set up a machine,
      - a functional enhancement,
      - a task that was rejected (even if it was done by someone else),
      - a script or
      - anything we do on the project.

      [Non-text portions of this message have been removed]
    Your message has been successfully submitted and would be delivered to recipients shortly.