Agile teams try to avoid the over-detalization of the customer requirements. In many cases the initial requirements are specified as loosely as in one sentence. In order to keep focus on the real customer demand (and not on what dialogs he’d like to see) the feature requests are often expressed in a form of “As a , I want [so that ]”. For example, “As a network administrator, I want to monitor the most active nodes of the system so that I was able to easily balance the load”. This form of requirement works very well until you start to work on it. It allows for capturing the original user need, while delaying the implementation specifics as long as possible, so that the team was able to work on it with as much information as possible.
At the iteration start, when the team selects user stories or features to be implemented, the requirements have to specified in the bigger detail, while still omitting as much implementation as possible until the actual start of the development. The agile term for these additional level of details is “conditions of satisfaction”. For the above administration requirement example conditions of satisfaction might specify which parameters of the system the administrator needs to monitor (e.g. processor load in %, free network bandwidth in KBits per second) and how would he like to monitor the system (e.g. be notified by SMS, see the load himself when running the administration panel).
There are couple of simple questions that can aid creating the helpful conditions of satisfaction (adopted from Writing Contracts for Agile Development )
– How will the team know weÃ¢â‚¬â„¢re done?
– When the team demonstrates this feature to you what would you like to see so that you know the team has done what you expect?
When do you usually specify the requirement details and what level of detail do you find useful?
Many if not most of software development companies employ some kind of the bonus plan for their developers. Developers or teams get a set of targets to reach and depending on the target fulfillment the bonus is paid. The idea of compensating the extraordinary performance and success is a good one. Unfortunately there two major problems with the bonus plans:
Expected bonus is not a reward
As Joel Spolsky puts it “They [bonus plans]’ve become like tips in restaurants: everyone expects one, so they can no longer be used well to award performance”. Most of the good managers I’ve heard of try to plan the bonus targets so that their subordinates would get about the same amount of money whatever happens.At the time when there is a reasonable lack of programmers everywhere, it is just too dangerous to have an employee that expected the bonus, but didn’t get it. The received bonus feels like something expected, while the one that was not received feels like a punishment and most of bosses wouldn’t like their employees to feel punished.
Whatever is the bonus target it effectively forces the person to optimize towards the concrete target. That’s not bad idea on its own. Unfortunately, there are so many aspects of software development, that it is too difficult to define a set of meaningful metrics to optimize for. Programmers are clever people and whenever there is a request to optimize towards a certain goal, it is usually possible to game the metrics and actually make things worse (since the problem is not removed, but rather hidden). For example, if the bonus target was to reduce the number of critical bugs per month, one of the ways for reaching the target would be to reject the bug reports as long as possible, to move them to another slightly-related departments, to claim that these are “features”, etc. As a result, the system would look better (since less bugs are in the bug system), but would actually become worse (since less bugs are actually acknowledged and fixed).
There is so much potential harm in the bonus plans, that frankly, I fail to understand why so many companies keep using the bonus plans. The only reason I could see is if the bonus is seen by the top management as the method for implicitly cutting salaries, whenever the company results are not too good. To me the potential employee disappointment feels like too big price for such a method. If the company is doing really bad, cutting the bonuses out won’t probably be enough, and if the company is doing just a bit bad, the disappointed programmers is the last thing needed for getting out of trouble.
Do you find your bonus plan motivating useful? Would you trade your bonus for the almost equivalent salary raise?