Bugs and user story points

I know it’s hard to spot, but my heart burns in my … business being for Scrum and agile software development practices. The agile manifesto. The human orientated character I see behind all this type of management style. What does it mean to me?

First it means that people are not resources. They can not be plugged into the socket like a vacuum cleaner and if that vc get’s broke you take the spare one from the basement, plug it in, and if it’s the identical brand and type – it will do the same job as the one before.

But that’s what I often encounter, especially on this epic project I am in right now and since years already. Our statistical data could be good enough to show how things are impacted when someone experienced leaves and a fresh man or woman from a preferred supplier joins. But it is hard to say: “Velocity down by a point, freshman in” or “Release moved by a day, because XYZ had the flu”. So I have a hard time proving it, and I have people on the management level in this company who do not get it anyway.

So lately I discussed with a group of 2 project managers and 2 developers if we should assign story points to bugs. The idea: We will have people in India fix bugs, and people in the core team in Germany & UK developing the software. If we knew how many complexity was in the last bugs we had / timely effort, we could size the team in India. And in the future we could just estimate the bugs in UK & Germany still and do the work in India, so we could track those guys abroad – whether they are maxed out or not etc..

This goes in so many ways against agility, that I think I need to throw up before I continue writing. Ah, much better. So – First: Split of Development and Bugfixing. What insanity. If I do develop a piece of software and people in a different timezone will fix the bugs, I will push responsibility for developing good code in the first place to the Indian guys – who have no stake in having a bug free software in the first place. They live from the bugs. The more bugs the better. The users do sit in Germany and UK – they won’t launch a missile to hit India, no, they will kill people closer to them. And the developers will say: We did everything on time but the support team is the bottleneck.

Secondly – you can not assign story points to a bug. A complexity estimate for capacity reasons – why not. I do not like it – but as long as noone tells me that fixing a bug adds additional value on TOP of the original user story – I am fine. See, a User Story represents a piece of functionality. If you deliver it, you can have story points. If you build in a bug and therefore the feature is not fully usable, we do not deserve to earn story points on something we delivered not correctly in the first place respectively receive additional story points for fixing the original user story.

But how should the dear and beloved project manager now estimate the amount of people he needs in India? Easy – if they get to do user stories or change requests – they can have them – and they can fix the bugs they develop into this as well. Just trying to plan bugs is planning the unplannable. How would we know what bugs will appear? If any? I mean, truely, in an ideal world 99% of your bugs surface in the automated testing (unit, integration, system tests) (99% as there is no ideal world where you do not have any bugs) – if you strive through Kaizen to a better and better development process, you will not have as many bugs in 12 months than you have today – and those bugs might be totally different when it comes to complexity.

Then, as the last obvious mistake I can see that doing estimates as A and B is doing the work – this sucks. How will the supplier buy in? He won’t. If we would let him do the estimates maybe he would agree, but ultimately I think  we could just build a second team which is enabled to build a slice of the software themselves – and improve through Kaizen. A different culture, different people – I think it would help us all learning from each other. The way they want to set it up it sounds like constant friction, no agility and incentives people not to do a good job on both sides of the world.

What I can not recognize after all of this writing is cost savings. The knowledge transfer between the two teams must be beyond all what I can imagine right. We need to train someone who is pretty outstanding in development 3-6 months before he is fully capable of understanding one part of our architecture (the Datawarehouse that is). Not speaking of the transportation layer, source system or business intelligence tool at the end…but that’s a different story.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s