Forums

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. If you have left the first and last name fields blank on your member profile, your email address will be displayed instead.

All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

One developer, half a tester
Last Post 13 Aug 2014 11:32 PM by Olivier Ledru. 30 Replies.
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Page 1 of 212 > >>
Author Messages
Mark Richman
New Member
New Member
Posts:55
Mark Richman

--
07 Aug 2014 12:45 PM
    I am the only developer on a small Scrum team. I only have one tester on my team, and she is only allocated 50% to the project. As a result, our sprints are ending incomplete, not due to incomplete code, but because she has insufficient capacity to fully test the work.

    This can't be a unique phenomenon. Is there a best practice here?
    Olivier Ledru
    Basic Member
    Basic Member
    Posts:260
    Olivier Ledru

    --
    08 Aug 2014 05:36 AM
    I will just quote the Scrum Guide :
    • Scrum recognizes no sub-teams in the Development Team, regardless of particular domains that need to be addressed like testing or business analysis; there are no exceptions to this rule; and,
    • Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.

    => As a team member, even if I'm expert on developement tasks, I'm also responsible of the testing tasks.
    I'm not as effecient as the expert but testing-tasks have to be done, so I need to work on them.
    Ludwig Harsch
    Basic Member
    Basic Member
    Posts:272
    Ludwig Harsch

    --
    11 Aug 2014 02:59 AM
    And not to forget:
    "Fewer than three Development Team members decrease interaction and results in smaller productivity gains. Smaller Development Teams may encounter skill constraints during the Sprint, causing the Development Team to be unable to deliver a potentially releasable Increment."
    :)
    Mark Richman
    New Member
    New Member
    Posts:55
    Mark Richman

    --
    11 Aug 2014 03:12 AM
    The team itself is of an appropriate size, but I am the one and only developer, and there is one and only one tester. For what it's worth, this is my team's composition:

    Scrum Master
    Product Owner
    Developer (Me)
    QA Analyst
    Documentation Writer
    Product Manager
    Department Manager (My boss)




    Ludwig Harsch
    Basic Member
    Basic Member
    Posts:272
    Ludwig Harsch

    --
    11 Aug 2014 03:41 AM
    OK, got you.
    Product Manager and Department Manager belong to the development team?
    The agile approach would be, as Olivier said, that someone of the development team does the testing, no matter who. For example, you could do it. Which leads to less development done. Which makes it transparent that you have some room for improvement. Right now it is not transparent, because you deliver an untested increment. This is known as the "Squirrel Burger".
    Mark Richman
    New Member
    New Member
    Posts:55
    Mark Richman

    --
    11 Aug 2014 04:02 AM
    The Product Manager is a chicken, not a pig, and the Product Owner is generally her proxy. The Department Manager is a pig, in the sense that he'll be fired if the product fails...which makes him more of a Product Manager than the actual Product Manager.

    What makes things more challenging is that the team are not all colocated. Our QA tester is in Bangalore, so we suffer from the time delay and communication complexity in round-trip testing.

    We agreed this morning to "finish fixing the bugs" by 3pm today, in order to have the PM and PO test the changes before handing off to our QA resource offshore. This will at least give some confidence level that I'm not delivering crap on a daily basis, only to wake up the next day with a larger defect list from offshore than the day before.

    Hopefully this tactic is short-term, and only applied to resolve critical defects early on in this project. I think it's unreasonable to expect a daily break/fix cycle of 9am-3pm.
    Olivier Ledru
    Basic Member
    Basic Member
    Posts:260
    Olivier Ledru

    --
    11 Aug 2014 04:05 AM
    I guess you give us the composition of your team, but not the one of your Scrum Team and your Develpment Team within it.
    It seems your Dev Team is made up of 3 people, the very mininum. In this case, nobody can stick to there domain of expertise, the 3 people need to be versatile.
    Mark Richman
    New Member
    New Member
    Posts:55
    Mark Richman

    --
    11 Aug 2014 04:09 AM
    I am a development team of one within the scrum team. That is, we have no other developers, or other team members who could fill the role of developer.

    I don't believe he who writes the code should test his own code, so I have the PM and PO testing my code before handoff to QA overnight.

    Unfortunately, this results in all eyes being on me all the time. It's quite stressful when defects are raised, as it spotlights me as a walking impediment.
    Ludwig Harsch
    Basic Member
    Basic Member
    Posts:272
    Ludwig Harsch

    --
    11 Aug 2014 05:35 AM
    I don't see you as impediment. In fact, it sounds like you are the only one delivering valuable work while being impeded by long distances, time zones, non-agile roles etc.
    The first thing you can change is your believe in separation of writing and testing code. Actually testing is part of developing, that's why it belongs to the development team's responsibilities. Have you heard about test driven development?
    You can still show the result to the Product Owner for acceptance, but not for finding bugs.
    Mark Richman
    New Member
    New Member
    Posts:55
    Mark Richman

    --
    11 Aug 2014 05:39 AM
    Yes, I know what TDD is, though I haven't practiced it religiously. I find myself more focused on banging out features and bugs than writing tests. I know that TDD is intended to reduce and/or prevent this thrashing, but I guess I am not skilled enough in the testing tools to integrate them productively into my work. This requires a time investment that management doesn't seem to have a tolerance for, especially since I'm working backwards from a deadline...on a new product from scratch that I'm writing myself. Realistic goals huh? :)
    Ludwig Harsch
    Basic Member
    Basic Member
    Posts:272
    Ludwig Harsch

    --
    11 Aug 2014 06:03 AM
    From the things you write I have the impression that you are pretty close to find all the answers yourself.
    I guess you also know the story of the lumberjack who is asked why he doesn't sharpen his blunt saw. He says: I don't have time to sharpen my saw, because I'm too busy cutting trees.
    Olivier Ledru
    Basic Member
    Basic Member
    Posts:260
    Olivier Ledru

    --
    11 Aug 2014 06:54 AM

    Posted By mrichman on 11 Aug 2014 09:09 AM
    I am a development team of one within the scrum team. That is, we have no other developers, or other team members who could fill the role of developer.

    The Development Team in Scrum is not only made of developer folks.
    Maybe the term is misleading, let's see it as "Production Team" or "The-guys-working-on-it Team"
    Mark Richman
    New Member
    New Member
    Posts:55
    Mark Richman

    --
    11 Aug 2014 07:09 AM
    Exactly. So, how does one make the case for fitting "saw sharpening time" into a sprint? I'm certainly not going to do it in my "other 40 hours a week" ;-)

    Ludwig Harsch
    Basic Member
    Basic Member
    Posts:272
    Ludwig Harsch

    --
    11 Aug 2014 10:18 PM
    What you can make transparent for the management is the technical debt which accumulates. This is missing automated tests, missing refactoring, etc. Over time, more effort is needed to pay back interests for that debt (manual testing, changing code which is not clean) and less time remains to create new functionality. One day you are at the point where paying back the technical debt is more effort than developing the product again from scratch. Most companies need 5-10 years to bring a product to this point.
    The alternative is to invest in quality now by following these steps:
    1. Stop creating technical debt
    2. Pay back a small amount of debt this sprint
    3. Repeat from 2 until the debt is paid
    Yes, you will deliver less functionality this sprint. And the next sprint. But you will still be able to enhance the product in 5 years.
    Puffy Watches
    New Member
    New Member
    Posts:1
    Puffy Watches

    --
    12 Aug 2014 02:10 AM
    Anyone can do the testing provided there's a good test script/plan.
    Mark Richman
    New Member
    New Member
    Posts:55
    Mark Richman

    --
    12 Aug 2014 02:30 AM
    This is all great advice, thank you.

    Is there a best practice for tracking and measuring technical debt over time?
    Ludwig Harsch
    Basic Member
    Basic Member
    Posts:272
    Ludwig Harsch

    --
    12 Aug 2014 02:49 AM
    I don't know which technologies you use, but there are tools like JaCoCo (measure code coverage), Findbugs (find potential bugs), PMD (find duplicate code etc) and Sonar can even calculate your technical debt in man months. I think that is a good and simple way to visualize it. Take a measure each sprint and plot the debt over time. I suggest to enhance the definition of done with the rule that the debt may not increase. Could be a first step.
    Ian Mitchell
    Veteran Member
    Veteran Member
    Posts:1695
    Ian Mitchell

    --
    12 Aug 2014 03:19 AM
    > So, how does one make the case for fitting "saw sharpening time" into a sprint?

    The Scrum Master is responsible for the implementation of the Scrum Process and its optimization. He or she should be making the case for the improvements being suggested, and should be coaching stakeholders accordingly.
    Mark Richman
    New Member
    New Member
    Posts:55
    Mark Richman

    --
    12 Aug 2014 03:47 AM

    Posted By Ludwig on 12 Aug 2014 07:49 AM
    I don't know which technologies you use, but there are tools like JaCoCo (measure code coverage), Findbugs (find potential bugs), PMD (find duplicate code etc) and Sonar can even calculate your technical debt in man months. I think that is a good and simple way to visualize it. Take a measure each sprint and plot the debt over time. I suggest to enhance the definition of done with the rule that the debt may not increase. Could be a first step.


    Thanks! I'm going to have to find the analogous tools for Visual Studio (code coverage and duplicate code are built in), but this points me in the right direction.
    Mark Richman
    New Member
    New Member
    Posts:55
    Mark Richman

    --
    12 Aug 2014 03:49 AM

    Posted By Ian Mitchell on 12 Aug 2014 08:19 AM
    > So, how does one make the case for fitting "saw sharpening time" into a sprint?

    The Scrum Master is responsible for the implementation of the Scrum Process and its optimization. He or she should be making the case for the improvements being suggested, and should be coaching stakeholders accordingly.



    I don't see any evidence of this, unfortunately. In my SM's defense, however, the organization is very new to Scrum, and nobody has been formally trained. I'm taking it upon myself to bone up quickly (through this website and other resources) and hopefully share the knowledge.
    Olivier Ledru
    Basic Member
    Basic Member
    Posts:260
    Olivier Ledru

    --
    12 Aug 2014 07:57 AM
    Does the Scrum Master had some training ? Can't you rely on him to remove or scale to the managers your impediments ?
    Mark Richman
    New Member
    New Member
    Posts:55
    Mark Richman

    --
    12 Aug 2014 07:58 AM

    Posted By Olivier Ledru on 12 Aug 2014 12:57 PM
    Does the Scrum Master had some training ? Can't you rely on him to remove or scale to the managers your impediments ?


    I know the training was informal. Unknown regarding impediments, as I've been able to remove all my own as they have been purely technical thus far.
    Olivier Ledru
    Basic Member
    Basic Member
    Posts:260
    Olivier Ledru

    --
    12 Aug 2014 09:53 PM
    Your increments are probably not shippable, the Dev Team is building technical debt/untested code/unfinished work.
    It seems to me that your Scrum process is not efficient.
    In Scrum, the Scrum Master is responsible for the process.
    Your issue is much more than just a "developper issue".
    What can you ask to your Scrum Master ?
    Mark Richman
    New Member
    New Member
    Posts:55
    Mark Richman

    --
    13 Aug 2014 04:58 AM
    Correct - we're not delivering shippable code. The sprints are spilling over into the next because of defects and/or regressions. This is a large project completely from scratch, with a new team, and everyone is new to scrum. Add to that a management-imposed deadline. Oh, and I'm the one and only developer.

    Most of the features I am implementing take the form of "spikes" through the architecture at it is evolving. As a result, estimates are off (though that is improving over time).

    I don't think there are any real impediments to progress, other than perhaps making the sprint 3 weeks instead of 2, just so we can have comprehensive testing (we have zero automated unit tests). I don't think it's reasonable to hand off a completed feature to QA offshore every night, or have every defect fixed every day.

    The company has "standardized" on 2 week sprints, so the tactic has been to make everything fit. I disagree with this, especially since it end-loads the sprint with testing and redevelopment in the last day of the sprint. If we were doing real scrum (and not scrumbutt) we would probably only be implementing one feature per sprint at our velocity.
    Ian Mitchell
    Veteran Member
    Veteran Member
    Posts:1695
    Ian Mitchell

    --
    13 Aug 2014 08:20 AM
    > The company has "standardized" on 2 week sprints

    If Sprint Goals are not being articulated, and timeboxing is not being respected, and potentially shippable increments are not being delivered by the end of a sprint, then in truth sprints aren't happening at all.

    Scrum depends on having Product Owners who value being in receipt of such increments each and every Sprint. Other agile approaches, such as Kanban, do not involve sprinting. Does your organization value sprints enough to commit to Scrum...and if so, can it explain why a 2 week timebox is thought to be optimal?



    You are not authorized to post a reply.
    Page 1 of 212 > >>


    Feedback