Pivoting Your Organization to Become Agile Testers

schedule Feb 28th 05:30 PM - Jan 1st 12:00 AM place Sigma

Many organizations struggle with transforming from the old style teams consisting of members with specialized silos of skills into Agile teams consisting of generalized specialists.  This results in sub-optimal Agile adoptions in Agile/Scrum environments, which is where most organizations transforming to Agile are advised to start.

We will start with a look into the real role of QA in the organization, and where they truly add value in the production of quality code to allow the business to move forward. Piggybacking on the role of QA, we will then speak to exactly what QA needs to do to add value to the software development process, and how they integrate in the DevOps model that is a contemporary solution to an age old issue.  And, finally, we will speak to some uncomfortable truths, and draw conclusions into the skills that Agile Testers must be expected to master to allow the organization to pivot successfully into a truly Agile development group.

 
2 favorite thumb_down thumb_up 11 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist
 

Outline/structure of the Session

This talk has been given at STP 2013 (San Diego CA) and will also be presented at Agile Development and Better Software East 2013 (Boston MA, in the fall).  I will substantially use the same material, but will have cull it down and tighten it up a bit to fit within 45 minutes.

Learning Outcome

  • For Agile and Scrum to work, QC in the organization must become QA, and integrated with the rest of Delivery
  • Lean thinking has direct applicability in terms of reducing waste due to large batch sizes that results from traditional QC testing
  • Lean thinking has direct applicability in terms of avoiding the evils of both Scrummerfall and matrixed organizations   
  • There may be up-skilling for QA to operate effectively in the new arrangement, but that’s good for everyone

Target Audience

QA, Developers, Managers

schedule Submitted 4 years ago

Comments Subscribe to Comments

comment Comment on this Proposal
  • Howard Deiner
    By Howard Deiner  ~  4 years ago
    reply Reply

    Jeesh.  I guess I didn't do a good job monitoring for comments.  I'll be more vigilant!  :-)

    I actually share your concern about the timeslot being a constraint.  It's an easy topic to go on for hours about.  I didn't want to try to ask for a 90 minute slot, as that really constrains the program choices.  And I don't recall there being a 60 minute slot.  Never the less, I'm confident that I can shorten down the stuff.  As I recall, some of the material was an attempt to get QA types aware of the basics in an Agile mindset (it was presented at a tester's event), and I can probably start there, as participants to Agile India have already drank from the cup of Agile, and I can presume a little more familiararity on their part.  

    • Doc Norton
      By Doc Norton  ~  4 years ago
      reply Reply

      Howard:

      I think this is a good approach. You can assume a certain level of familiarity with Agile and cull that content to help better fit the time-slot.

      How do you plan to remove these elements from the presentation? What challenges, if any, will that create for you? Lack of context or continuity? Awkaward transitions between slides?

      This is a good topic and I want to make sure you are confident you can deliver the core message well.

      Thanks.

      - Doc

       

       

      • Howard Deiner
        By Howard Deiner  ~  4 years ago
        reply Reply

        Forgot to say that I'm quite comfortable that I can hit the timebox with a focussed message and confident that I can get that core message across in a decent fashion.

        • Doc Norton
          By Doc Norton  ~  4 years ago
          reply Reply

          You expressed a concern with the time slot as a constraint. If you've given it more thought and feel it is not a concern, I trust you. I know for myself, I tend to have stories that I can lengthen or shorten as needed to match the audience and timeslot.

          • Howard Deiner
            By Howard Deiner  ~  4 years ago
            reply Reply

            I'm comfortable with reducing the scope of the presentation to speak just to the Lean principles and making the points come true.  After I gave this presentation in the Spring, when I showed it to my current client, he wanted me to present just the Lean parts to the executives.  That tells me that the Lean message was the area of interest.  Which makes sense, because most "gotta do Agile, gotta do Scrum" adoptions fail to recognize that the barrier to effective QA integration with Delivery Teams surrounds the barrier of how QA is engaged as a silo to be managed for effectiveness and efficiency, instead of remembering that the greater good for effectiveness and efficiency is gained by the organization getting closer to a single stream of features completely through the system.  I can reorganize and make the 45 minute window comfortable.

            I do share that knack of hitting a timeslot that you speak to by keeping too many stories from becoming too long.  But, I also feel that most of the message sticks from story telling, so the way to success is to limit scope and make this targeted on just the Lean aspects.

      • Howard Deiner
        By Howard Deiner  ~  4 years ago
        reply Reply

        Hi Doc!

        I appreciate the suggestion for what could go, as in "you can assume that people going to an Agile India conference know some of the basics of Agile and Scrum."  With that idea in mind, I'm sure that sections such as "What Color i Is Your Agile Tester's Parachute?" could easily be culled.  I want to focus on how Lean thinking fits in as a way to fight silo mentality as applied to QA.  In fact, maybe I should be brave enough to limit the entire presentation down to that and even just title this "Making Your Testers Agile by Leaning Them Down", which is basically the "What Makes a Testing Organization Agile?  Lean Thinking!" section.

        --  howard

  • steve ropa
    By steve ropa  ~  4 years ago
    reply Reply

    I'd like to echo Joel's thoughts here. The slides do look great. This is also a vital topic that really needs to be addressed. I imagine picking the right slides here is going to be like deciding which is your favorite child... Maybe focusing on one of the major themes you lay out in the deck?

    • Howard Deiner
      By Howard Deiner  ~  4 years ago
      reply Reply

      Hi Steve!

       

      thanks for the kind words.  Which topic that I bring up is dearest to your heart?  I'm quite open to suggestion and help deciding where things that are already obvious should be cut.

       

      thanks again!

       

      howard

  • Sachin goel
    By Sachin goel  ~  4 years ago
    reply Reply

    Hi
    This is indeed interesting. I feel emphasis is more on early and DevOps. It is worth debating if in these models do we need formal testers. Why not extend core develeopment team and make test as part of the job?
    What are your thoughts on testing / automation for projects which have interdependecies. are there best practices to learn from?

    Thanks
    Sachin

    • Howard Deiner
      By Howard Deiner  ~  4 years ago
      reply Reply

      Hi Sachin!

       

      i fully agre with your sentiments of embedding testing with the full cross functiontea delivery teaM and I directly speak to that.  I also speak to the issue of testing by aiming more engineering practice in terms of automation.  What I don't get to in this talk is the interdependencies issues, which is an element of scaling agile, IMHO. I believe in having product delivery teams using scrum interact with platform concerned teams.  Those platform teams, with those nasty dependencies, can have their dependencies broken by having them work in a sleeper ate Kansan team, where they can service both the architectural aspects of their work, as well as getting needed product implantation occur with embedding members of the platform team with appropriate product teams as the needs are surfaced.  Once te cycle time for platform teams is undstood, product teams can then plan adequately, and just in time.  I do not speak to that in this talk, although I start on some of the discussion in the pmo transformation talk that I submitted to this conference.  The platform versus product concern issues will be a talk I will give in a couple of months in London at software architect 2013.

      thanks for the good insight, and sorry that I won't address much in this talk on that.

  • Joel Tosi
    By Joel Tosi  ~  4 years ago
    reply Reply

    Hi Howard,
    I appreciate the sentiment of your submission. Your slides look great, though as you mentioned - you have a ton of material there. For a 45 minute talk, how many slides would you be able to get that down to and still have it meaningful?

    Best,
    Joel


  • Liked Doc Norton
    keyboard_arrow_down

    Doc Norton - Creating a Global Engineering Culture

    Doc Norton
    Doc Norton
    Director of Engineering
    Groupon
    schedule 3 years ago
    Sold Out!
    45 mins
    Talk
    Beginner

    Creating a Global Engineering Culture

  • Liked Howard Deiner
    keyboard_arrow_down

    Howard Deiner - Contracts in the Age of Agility

    45 mins
    Talk
    Intermediate

    “Fixed price, fixed deliverables, and fixed schedule” contracts are just about the worst way to write contracts involving software, yet they are the most popular – so what are some techniques to use to fix that?

    Organizations that perform professional services for software development or develop software on a work for hire basis are usually engaged bound by extensive contracts.  These contracts are typically characterized as “fixed price, fixed deliverables, and fixed schedule.”  These, of course, are the vertices of the “Iron Triangle of Software Development” and foreshadow a poor outcome due to issues that make the requirements gathering and project estimation phases that precede contract negotiation so prone to error.

    Given this, the question becomes one of “how can I engage clients in a way that allows us each to achieve our goals?”  If Agile and Lean methods are the status quo for good development practices, how can I write contracts for development services that embrace this mindset and let each side achieve it’s goals better?  This lecture and roundtable explores the many facets of this question and provides the attendee answers that they can use going forward.

  • Liked Howard Deiner
    keyboard_arrow_down

    Howard Deiner - The Agile PMO - Creating A Lean Organization from the Inside-Out

    90 mins
    Talk
    Intermediate

    For many, the idea that you can transform an organization from the PMO outwards seems odd, if not impossible.  But my experience says that this is becoming a trend that more and more clients are asking advice for. 

    We know that for an Agile transformation to work, we need to engage not just the Delivery Teams to approach work differently, but we need a change agent high in the organization to support that change in mindset.  I’ve always found it difficult to find that right person in an executive leadership role who is willing to have the courage to “bet the company” on a new and unproven approach such as Agile and Scrum.  As coaches, we tend to start “pilot” projects, and hope that traction will occur “once everyone sees the great results that we get.”  But I think that this approach is fraught with peril of not getting the right project to start with, not getting the right results immediately, and not motivating people by seeing results from a process that they are not comfortable with.

    I think I’ve come upon a new approach that works better.  Instead of trying to “sell” Agile at an Enterprise level, embrace pure Lean principles high in the organization and work with the PMO leader at the organization.  Once they are comfortable with ideas such as “more leadership and less management”, “shorter concept to cash cycles”, “enabling Lean Startup mentality for disruptive product development”, “always looking for the elimination of waste”, “exploiting variability through appropriate cadence control and appropriate utilization rates”, “delegated authority”, “continuous improvement”, and “rolling planning”, the PMO becomes a terrific agent for instituting change, because they are usually already endowed with the right responsibilities and accountabilities that can push the organization forward.