Skip to main content
Back
X
Back

Scrum Forum

One developer, half a tester

Last post 04:32 am August 14, 2014
by Anonymous
30 replies
Author
Messages
05:45 pm August 7, 2014

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?

10:36 am August 8, 2014

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.

07:59 am August 11, 2014

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."
:)

08:12 am August 11, 2014

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)

08:41 am August 11, 2014

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

09:02 am August 11, 2014

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.

09:05 am August 11, 2014

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.

09:09 am August 11, 2014

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.

10:35 am August 11, 2014

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.

10:39 am August 11, 2014

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? :)

11:03 am August 11, 2014

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.

11:54 am August 11, 2014

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"

12:09 pm August 11, 2014

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" ;-)

03:18 am August 12, 2014

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.

07:10 am August 12, 2014

Anyone can do the testing provided there's a good test script/plan.

07:30 am August 12, 2014

This is all great advice, thank you.

Is there a best practice for tracking and measuring technical debt over time?

07:49 am August 12, 2014

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.

08:19 am August 12, 2014

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

08:47 am August 12, 2014

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.

08:49 am August 12, 2014

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.

12:57 pm August 12, 2014

Does the Scrum Master had some training ? Can't you rely on him to remove or scale to the managers your impediments ?

12:58 pm August 12, 2014

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.

02:53 am August 13, 2014

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 ?

09:58 am August 13, 2014

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.

01:20 pm August 13, 2014

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

01:26 pm August 13, 2014

Our PO doesn't really understand what's required of her in the role. What's more, both she and I report to a manager who really acts more like the PO than anyone else.

I honestly don't know what the company values, as I work in relative isolation. I bet if they could have their way, they would do 1 week sprints and push everyone to work 60 hours a week. I've experienced that before.

I keep having items added to the product backlog, but even though they have not been groomed or commited to for any sprint, I'm told they are a priority, and as such I am to work on them first, in deference to what's been committed to in the sprint. Just because it's quick to code doesn't make it cheap.

01:46 pm August 13, 2014

I've had best results, in that sort of situation, by coaching "transparency first" with an elementary task or kanban board. This helps to establish the key building blocks of prioritization and queue management, limited WIP, metrics, and completing work to a known Definition of Done

I generally stick with that until I see where the pull for releases is coming from. I can then start coaching the value of cadence to incipient Product Owners. If this is valued, then I have a case for upping the game further and to start coaching Scrum.

02:35 pm August 13, 2014

I appreciate all of that. I think this organization wants to do scrum, but keeps getting caught up in deadlines. So from where I sit then mentality is, "do scrum as best you can, but remember we still have to ship all of it by the deadline".

05:39 pm August 13, 2014

Mark,

Based on everything you've said, your company is not doing Scrum, and has no interest in succeeding with real Scrum. It sounds like their culture is one of command and control waterfall, which has been shown to be 3X less likely to succeed(Schedule/Scope/Cost) than Agile. Until they realize that what they're doing is not working well, they likely will not change any of their behavior.

If they really *do* want help, then give them our web site and tell them to give us a call. :-) We help orgs like this all the time. I just sent you a LinkedIn request. :-)

http://ScrumCrazy.com

12:35 am August 14, 2014

> I think this organization wants to do scrum, but keeps getting caught up in deadlines

Many organizations want the benefits of change, but without having to change. These are not the ones that succeed in an agile transformation. Wanting to "do" Scrum isn't enough, it is executive sponsorship that is needed.

04:32 am August 14, 2014

it is executive sponsorship that is needed.

+1
Hey, Ian, have you been introduced to my top-managers ? ;-)