One developer, half a tester

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.

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

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)

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

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.

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.

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.

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.

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

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.

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"

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

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.

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

This is all great advice, thank you.

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

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.

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

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.

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.

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

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.

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 ?

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.

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

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.

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.

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

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

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

it is executive sponsorship that is needed.

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