Perfect Software Really Fast – Conflict is Good
I’ve figured it out. But people are worried it will create tension. Who cares? a little tension never hurt anyone. Like with everything else, the solution is money. just throw money at it? no, of course not. That’s too obvious. Here’s the solution – compensate your QA people on Quality and your developers on speed. That’s all there is to it. the details are easy, I challenge you to find a flaw in my logic here:
Developers need to develop stuff. For S3, they need to do it fast. Really fast. IT says it’ll take 18 months? We’ll have you up and running within a week. Not necessarily all the bells and whistles, but something that is valuable to you, the client. and that’s to production in that speed, not just coded, but coded, verified, and released all within a week. So how do we make them develop stuff fast? Simple – tie their compensation to how long it takes them to get something out. Not the end solution completely solved. Not just the development part. so, if their compensation is (x) and is tied to revenue, and, if something is in production and being used by the customer takes more than a week, their compensation is (x) – (the number of days early)*(some constant). simple – if it goes live late, you lose money for each day. (you can have a positive side too, but to be fair to QA, we’re going to leave it as negative only for now)
Did I mention it has to be bug free? Yep, bug free. QA also makes (x), which is tied to revenue. QA needs to make sure software doesn’t have bugs. So, for every bug that is found after something goes to production, QA loses (y) amount of money. That’s it: more bugs = less pay. hell, ANY bugs = less pay.
but wait, I hear you say – Dev should want quality too! But they do! why? because if they don’t, QA will block. nothing goes live till QA says go. but what incentive does QA have to do things quickly? they don’t. And this is key. In my ideal world, QA is bored. bored out of their skulls – all they do is test bug free software all day, every day. No one says QA has to be done fast. QA has to be done right. what stops them from halting everything? simple – their compensation is tied to revenue. No revenue, no money period.
But just think of the animosity it would cause! The developers get mad at QA for sending their stuff back with bugs. QA getting mad at development for making so many bugs. oh, what a horrible working environment! Come on… really? all of a sudden, development has a huge incentive to write bug free software. the vast majority of the time in development is really re-work from bad software. get rid of that, and the speed and quality skyrocket.
Get people to write software that doesn’t suck (look for a new blog post on this topic later), and you can finally delivery perfect quality fast. Just don’t be scared of a little conflict.
If a date slip leads to less bonus pay, do all the developers that worked on that functionality incur a bonus decrement, or only the developer whose slated work took too long?
If the date slip occurred due to reasons outside of the development team’s reach (illness, requirement issues, lack of training), does the dev team still incur a bonus decrement?
Also, if the date slip occurred due to unwise management choices (in your example above – poor hiring), shouldn’t the management incur the bonus decrement?
[...] Compensating QA and engineering? Use Conflict – it’s not bad [...]
Is the 1-week delivery time a constant in your equations, or does it change according to estimates? If it changes according to estimates, who decides those estimates and how can we ensure they are a reliable gauge of how long the work should take? If it’s a constant, how can we ensure the amount of work passed on by the BAs fall within the attainable 1-week? Does all of this estimate/requirement refining occur within the 1-week goal?
Good question Joe. …and how do you ensure the BA’s time allotted expectation is REALITY? What an analyst thinks should last a week could take dev a month to build. The BA’s job should be to provide requirements for features needed by the customer pool and allow the experts who are building the feature say how long it’s going to take.
Another reason I like Agile. The BA is replaced by a Product Manager in my current work case. That Product Manager is the funnel of all the marketing, sales, and customer feedback and builds raw requirements, along with prioritization, for the team to digest, break into workable features, and then allocate the overall effort scores, assignments, and tasking.
The workload is broken into small “Sprints” and the team updates itself everyday with the progress, issues, and next efforts. The sprints are kept to small enough cycles, say 2-4 weeks, and at the end of every sprint is a fully deliverable set of features, built, tested, patch capable, and documented.
In agile you deliver features or to dates, but not both.
So standardization of estimates, standardization of requirement gathering, and contractual agreements between the company and it’s delivery/qa employees must all be accomplished prior to implementing this idea.
It also seems that there is a ceiling but no floor to your compensation model. This is against the fair labor standards act which requires at least a minimum wage.
Joe – to your first point: the one week delivery is simply a number that has yet to be achieved, it is by no means an end. And, no, it specifically does not change according to estimates – that simply gives the opportunity to game the system by overestimating. the amount of work is totally irrelevant. If the customer would actually use (by which I mean – use because it adds value) a screen that said “Hello World”, then that would meet that requirement.
Joe, To your second point -
Absolutely not. The only thing that needs to be established prior to implementation of this is the idea of compensated development, compensated QA and a solution to a problem. methodology and standardization are irrelevant.
as for your minimum wage situation – if you have employees who are bumping against minimum wage requirements because either their base salary is so low that a small slip up causes them to bump against it or because their time or quality is so poor that they drop below it, then you are hiring the wrong people. And, as you well know, I’d fire you long before you got to that point.
Realistically, this would be implemented as a variable compensation plan, rather than a base compensation plan. e.g. your bonus this year starts at $50,000 – it’s yours to lose. one day costs $1000. good luck.
Mark,
The assumption you are making is that a task will be worked from start to finish by the development team (and other priorities will not be assigned ahead of it mid-task). This would effectively increase the delivery time of the task and dilute the compensation.
With the BA team managing the workflow, this can / will happen from time to time.
How are you going to address?
A fair question. Realistically, this needs to be implemented on the right scale – a week isn’t really the right unit. The only truly appropriate unit is “one atomic unit of work”, which is, except in true emergencies, not allowed to be interfered with. S3 folks know what atomic unit we use. I’ll write another blog post about it for the rest of you.
Interesting but at least a couple more things needed:
1. Correct requirements. This talks to the kanji characters scenario in one of your comments
2. QA involved at the start of the development and not at the end. For non S3 folks reading, we already do this, so it’s a clarification for readers
One last thing: not everyone is wholly motivated by $. In fact, there are outliers who specifically are not motivated by $. Rather, they simply take pride in doing an excellent job.
Absolutely, getting the right team is only a start, and one of the more difficult tasks to get correct. As for the rest, I’ve found the best way to accomplish it is through a team development approach, like Agile/Scrum. A team that incorporates, all elements (architecture, engineering, QA, tech-writing), instead of partitioning them into separate factions which end up pitting performance against each other.
Making the team aware and accountable seems to quickly drive out who the real players are and who needs to be benched forever.
Jack,
I think your note will be the topic for a future blog post – should generate some controversy.
To seek perfection is definitely a noble and commendable quest. Having and setting appropriate expectations (both yours and theirs) is just one of the tools used in getting there.
Over the twenty plus years I’ve been in the development grind, I’ve come to find the best products come from teams, teams working together with common goals of delivering the best, most useful solutions, with the highest degree of functionality and quality that enables the customer’s success. Additionally, a team united in this purpose has always a more satisfying experience to be a part of. Finding the right members for a team to achieve it… priceless.
Warning: Keep and eye out for that person who always empties the coffee pot, but never has the time to refill it.
Ray,
I like your responses – you’ll see a number of blog posts addressing some of them in the coming weeks. Watch for them. Notably, I will discuss Agile, how the S3 Production System addresses teams, and how I perceive the past 20+ years of software. So, rather than undermining my own future blog posts by answering those points, when I do finish them, I’ll add links to them here.
However, it is important to realize that the financial motivation has absolutely no bearing on the methodology used. It is a personal motivator, independent of all other aspects of the development.
Mark,
Good deal. I’ll look for them. …and for the record, I do believe the right team, mixed with the additional motivation of success and/or reward, will make a difference in the overall speed and extent of delivery and the state of the overall quality. I’ve seen it.
I think you’re definitely on the right track to a very interesting development/compensation model.
This could be an interesting conversation to have.
I’ve been developing, testing, marketing, selling and supporting software and hardware for over a quarter century. I have yet to experience perfection. I suspect you were using that to simply make a point.
In my opinion, development and test should be held equally accountable. You can not test quality into a product, you can only measure it. For example, take a simple requirement “create software to allow the input of a name”. I could write the code in two minutes but test it forever (until I feel confident enough that it is ready.) After testing it for hours or days, testing letters, numbers, punctuation, length, … I would decide to ship it. After releasing the product, the customer inputs kanji characters and breaks the code. So is it developments fault for writing code that can not handle that situation, is it tests fault for not thinking about that possibility and testing for it or is it the customers fault for not being more specific in their requirement? Take that situation one step further, development spends another 30 seconds modifying the code to not accept kanji characters. Now if I’m responsible for testing, I have to not only test kanji characters, but I need to retest everything I did prior (to be sure the change did not break something already tested) and I need to consider other possibilities like Arabic, … If I was punished for something like that I would put the product in analysis paralysis.
At the end of the day, the true measure of success is customer satisfaction and that comes down to how well you support your product. Assuming that you don’t deliver complete junk, a customer that has a few issues and gets excellent support and quick resolution is always a happier customer (more likely to be a reference).
Got to run, good luck with perfection
Jack,
You have identified an important part of the process that was (intentionally) not addressed in this post, but will be in a future post. The fact that the requirements do not meet the needs of the customer is neither development’s nor QA’s bust – the compensation argument continues to the BA’s you have writing the requirements – and my future post will address that.
Whether the specs and requirements are complete is not relevant – the above still holds. An unstated requirement is not a bug. The example of putting sand into a fuel tank was once brought up in a meeting with me – if the car doesn’t go when someone puts sand in the fuel tank, the car is buggy. Obviously that’s nonsense – the required input into the fuel tank is gasoline, of a certain octane and quality. Putting jet fuel, even though it is still fuel, in the gas tank similarly does not make the car buggy. This is no different from putting Kanji into a text field that was specified to take ascii characters.
Does this mean the software would meet the customer’s needs? not necessarily – but in the above scenerio, I’m not discussing the customer’s needs, merely whether the software performed the agreed upon functionality.
The kanji example was only intended to point out the infinite permutations that result in a real barrier to perfection. It’s all how you define what a failure is. I’ve never met an engineer that could not rationalize failure with “working as designed” in that if my code fails, it obviously was not designed to handle that situation.
Mark developed the idea of conflict as a kid/teenager. Listen to him. Mum