In all the scrum literature, there is much rhetoric on focusing on delivering value but there is very little explanation on how you calculate it. Exactly how do you calculate it? I came across an interesting article by Ryan Shriver called "Measurable Value with Agile" where he talks about delivering the right things by choosing tasks based on a cost/benefit analysis, and then delivering those things right with the selected agile method of your choice. Value is then calculated by measuring it via a defined set of identified targets, constraints, and benchmarks. Although I do agree that measuring performance is important, there is still a major problem; if business value can only be measured once a product/feature is delivered, how do you know which user stories to work on first and which ones to avoid? Sure a cost/benefit analysis may be an easy way to determine which tasks to focus on, however, the value of that task is yet to be determined. You can do a cost/benefit analysis, choose the "best" user story based on that analysis, and still deliver a feature that has absolutely zero value. So how do we offset this?
Extreme Programming postulates, that courage is one of the fundamentally important virtues of an agile developer. I would augment this postulate and claim that it is, together with talent, THE most important one.
Why? Simple. Courage lets you overcome any and all obstacles that may stand in a way of developing a fine piece of software.
For example, I have seen a lot of cases where a programmer would shy away from an interesting project, because thay claim that thay lacked knowledge and expertise in the particular area. Or – the subject matter seemed too hard. They felt not „worthy” to try. Let me be a bit controversial and say: lack of knowledge does not matter. The courage to learn new stuff does.
Lately I noticed several discussion threads both offline and online (the most notable online one is in the leandevelopment Yahoo! group) focusing on the value of software testing, both automated and manual. The main discussion point as far as I can see it is in whether the testing is actually a waste that is unfortunately needed to cope with the insufficient practices and should eventually be eliminated.
Knowledge Source
Software development is always not a mass production, but a new product development - software engineers are not manufacturing goods, but rather make a design for a compiler to manufacture something nobody previously built.
"Honesty is the best policy — when there is money in it."
- Mark Twain
XP requires constant communication between team members. More specifically, XP and Agile teams depend on honest communication between stakeholders, including developers, testers, managers, and customers.
We expect manufacturers and vendors to be honest to us about the products and services they offer and market to us. Our customers expect the same. Honesty is especially crucial during iterative development where a minor course correction early in the schedule can save significant time down the road.
Extreme Programming values are the primary guidelines to be used whenever it is not clear how to resolve the particular situation. Value of respect is special in that it is the only Extreme Programming value not present in the first edition of the Extreme Programming Explained. Kent Beck added it to the second edition basing on how the first book has been interpreted in many companies out there. Extreme Programming is no fixed mechanical process that anybody could be forced doing.
Extreme Programming values are the primary guidelines to be used whenever it is not clear how to resolve the particular situation. Value of courage is about acknowledging the fact that the best way to produce the best possible products is to be honest and transparent on all the possible levels from customer communication to the way you type code despite how uncomfortable the idea of high transparency might look like from the beginning. The courage is needed to admit the team and organization weaknesses.
Extreme Programming is best known for its efficient engineering practices such as Pair Programming or Test-First Programming. However, practices are only a surface of Extreme Programming. The pros and cons of the practices, their importance and order of applying depend on the organizational and team context. Values are the backbone of XP. It is the understanding of values that makes the practices reasonable. It is possible to implement the practices without caring about the values, however, you can take most of XP only if your organization values match the values of XP.
Extreme Programming values are the primary guidelines to be used whenever it is not clear how to resolve the particular situation. Value of feedback emphasizes the belief in that requirements always change and/or are not well understood in the beginning of the project. Therefore the only way to build software the customer really needs is to continuously adjust the development basing on his feedback. Same goes to the technical level.
Extreme Programming values are the primary guidelines to be used whenever it is not clear how to resolve the particular situation. Value of simplicity calls for looking for the simplest working solution first and improving it later only the need arises. This value is based on the assumption that requirements and many other things in software are changing so often and are so imprecise until done that it is rarely worth to implement things supposed to be helpful at some point in the future.
An exciting story on how a person in the deepest regret, having no faith in himself can find its predestination and joy in life by having a close look on what really motivates him, not on what he thinks motivates him.
RSS feed
Subscribe on Kindle
