This is a great book to get started - and whilst it is a little dated technology wise the fundamentals are great along with a very entertaining tongue-in-cheek presentation/writing style.
I agree whole heartily, but the risk that is rarely protected by the contract is whether those features will actually give the client any return on their investment. Keeping the investment small (in terms of scope and time) only reduces the exposure in terms of cost/time to the client, yet vendors are making countless decisions that affect the outcome (e.g. ROI) of a project. The "scope" in a contract tends only to specify "what" and not "how well" or "why". At my company been experimenting in trying to solve that problem by contractually committing to outcomes (e.g. a measurable goals connected to the business case - e.g. reduce churn, increase sales, etc.) and tying part of our payment to meeting those goals.
If as the OP says, it's about treating the contractual relationship as an investment to deliver value then I believe we can do better than simply "fix scope". I've recently written about this at length including why the contract model (and agile derivatives) do little to align the interests of client and supplier to deliver value. (http://www.energizedwork.com/weblog/2014/09/commercial-contr...)
I wasn't using Toyota as proof that Agile works. I was suggesting that are common problems in managing systems of work have common solutions based on sound, proven theory.
All it takes, as others have said, is that by applying critical thinking and with armed with the knowledge of the theories I mentioned you will quickly arrive at some of the principles/processes/techniques you'll find in Agile.
The fact that the word Agile itself has become a poisoned, meaningless word, adopted by the same people that used to peddle previous software process fads (and the consultancy and services that naturally go with it) doesn't mean that there are some good ideas that really do work.
There is a large body of theory, evidence and even mathematical proof that supports why agile methodologies, such as Scrum or Kanban can improve the effectiveness of teams in terms of throughput/productivity. Systems, information, decision, risk and queuing theory when correctly applied to product design and development can yield transformative results, in a similar way that companies like Toyota transformed manufacturing process using similar principles to optimise for just-in-time production vs economies of scale.
Unfortunately, you are unlikely to find such information in most of the literature around Agile methodologies, blogs or the army of consultants that roam the earth much less your average Scrum Master. Cargo-culting is rife in most the companies I have seen, even where the adoption of agile principles and methodologies have a significant positive effect on a team's effectiveness. I'd have to classify myself as a cargo-culter in the beginning too when I first exposed to working in Agile team taking an eXtreme Programming approach some years ago.
Unfortunately, herein lies the problem. For many people it does work (whether you like it or not) and as you say, it takes on the characteristics of a religion - people experience "better" and are just happy to keep following a recipe for "success", without understanding WHY. Obviously, this leads to people trying to replicate such "success" in a different context and when things go wrong they don't know how to fix it - they don't have a deep enough understanding of how to re-apply the principles and and normally they are optimising for the WRONG thing.
There are valid proven theories behind why working in iterative cycles, limiting work-in-process, shipping working code in the production regularly and self-organising teams lead to better results - you just won't hear why from most of the Agile evangelists in this world but there are answers out there if you look for them. Instead your typical Scrum Masters obsess about far more trivial and unimportant things like how to phrase the title of a story card, retrospective formats, burn down charts and velocity points.
If you can be bothered to look a bit deeper, then just avoid using the "A" word in your searches. ;-)
P.S. If you want a really good laugh, do a bit of research on how "Waterfall" came to be and how ridiculous the whole Waterfall vs Agile thing really is.
The problem highlighted by this article and the ensuing debate here is that most people in our industry (management and developers alike) talk about good code and bad code in purely subjective terms. Until we learn to talk objectively about the systems we build (where code is just one part of that system) in terms of function (what a system needs to do),
performance (how "good" the system has to do the functions) and economics (the resource constraints in building the system) - you know, like proper engineers do, we'll never move forward. The ugly truth is that would appear that most banking systems are "good enough" - i.e. they are competitive in the environment operate in - despite the horrors that undoubtably exist in their implementation. I see a lot of talk about the consequences of "bad code" but few have the evidence to back it up. It is our responsibility as engineers to measure the performance of our systems in the _right_ way so it becomes painfully obvious where we should focus our efforts to improve things.
Recently at my company we had an internal discussion about pairing after a colleague wrote a similar post espousing all the virtues of pairing. Pairing was something we as a group had once been zealot like in our belief in its value and would we would pair on everything we did. It was clear however from the discussion that most of us had moved on from this view as far too simplistic and dare I say naive.
Looking back at over 7+ years of pairing I still believe there is wide range of value to the practice and it has made me a much better developer but like anything its value varies greatly depending on your context. I've also come to realise there times when it can be wasteful and even destructive.
Innovation is one very good example where I believe there both needs to finely balanced tension between time to work alone and collaborate together. Take a look at the studies around problem solving by groups vs individuals as to why. Similarly, pairing can also have positive and negative effects on learning and varies greatly depending on an individual's learning styles.
The funnest thing came at the end of our discussion. Having collectively realised the folly of our pair programming crusade over all these years one of the group looked back to see what one of its biggest champions Kent Beck had to say on the subject in his book Extreme Programming Explained. Categorically he said that you shouldn't pair all the time.
Exactly. I prefer to focus on what people like Steve Blank have said about creating a start up company. Better to think about how you are investing your time and resources in terms of customer discovery/validation (searching for a viable business model) and then customer creation/company building (executing on the business model). A lot of people conflate the two when thinking about the purpose of an "MVP" or just plain experiments to test assumptions - and as the poster is discovering there are consequences when you do.
Whilst the article mentions how countries like China restrict access to communication networks we should be under no illusions that nearly all major communication networks are ultimately still under the control of central government wherever you live. For the pendulum to permanently swing in favour of "freedom and democracy" we need a genuinely open network. Without an open network open devices, operating systems, software, etc could easily be neutered, if albeit in a rather draconian fashion by hitting the "off" switch. This can seem unlikely in any "free" nation, however this was almost a reality last year during the London riots. As those in power openly lamented the use of Blackberry's BBM network by the rioters (and various other communication networks) it was clear that the government came very close to ordering the service shutdown and I have no doubt it would have been had things deteriorated any further. Perhaps the great next swing might be those attempting to create decentralized mesh networks? One can hope.
https://www.amazon.com/How-DJ-Properly-Science-Playing/dp/05...