How well does the Agile Manifesto align with principles that lead to success in product development?

by [email protected]

Background

I carried out my first 20-value-delivery-step agile IT project in 1960 on an invoicing system in Oslo when I was 20 and I just used my common sense. It was a radical re-architecting of what IBM initially sold to my client. So I learned that 'smarter architecture' might be needed to deliver results stepwise, and learn at each step.

Then I began to realize not everyone in this business has common sense. But many smarter people shared the agile ideas, which we called "Evolutionary" at the time [28B]

With few exceptions [28B, 18, 19, 30, 31] I was for over 35 years a lone voice in the wilderness: the masses, including US DoD believed in Waterfall, and I was obviously a bit weird, and ignored, as I often am today about the need for Engineering methods in software and management [1,2].

Lucky for me, there were several exceptional organizations out there who asked me to help them with these 'evolutionary' ideas, like HP [29], Intel, [15] Boeing, Ericsson, and even little Confirmit in Norway [20] - and others, all of whom had more quantified documented success than any of the Manifesto Agile offspring. I was not alone, just a quiet minority.

So, below I will discuss the Agile Manifesto point by point: 4 values and 10 principles. I will first attempt to answer the question of how aligned I am with the Value or Principle. Then I will add my own ideas, and a reformulation of the the Principles.

In general I was never impressed [ 5, 27] with these because of their fuzziness. But the immature world out there, did get seduced by that fuzziness, actually they got 'screwed'. They are so immature that they deserve what they got. 'Survival is not mandatory' as W E Deming said.

If I were to put blame on a single instance, I would blame the Management MBA Culture. Too much 'bean counting' and too little about 'managing values' and 'delivering qualities' that actually 'make hay' (financial values)

. [34, 22].

The Four Values of The Agile Manifesto 

http://agilemanifesto.org

I have long since written my counter-proposal for Agile Values [36B]. I believe that these value statements are much better and clearer than the fuzzy stuff in the Manifesto. Judge for yourself.

1. Individuals and Interactions Over Processes and Tools

Well, of course. Live human reality beats theory and planning.

Planguage (specification language for requirements, design, stakeholders, results) and Evo (iterative, incremental, learning project management process [1,2], are 'tools and interactions' which deeply support stakeholders, learning, feedback, and change; in multiple dimensions (of values and costs) simultaneously.

Of course 'stakeholders first' and their 'interactions with requirements and systems': before any silly bureaucracy. However, people obviously have to be taught suitable processes to support stakeholders, and the Manifesto is so ignorant, even today, that 'stakeholders' are just barely mentioned: only the extremely narrow category 'users and customers.' dominates (think, in the practices, user- stories, use-cases: not 'stakeholder stories' and 'stakeholder cases')
My conclusion is that the Manifesto is dangerously ́narrow-minded' concerning people and interactions.

Source: http://concepts.gilb.com/dl915, Advanced Agile Software Engineering (2018) [37].

Notice the many examples of stakeholder categories, and the fact that stakeholder analysis interacts with values (requirements) in a continuous iterative, learning way? [51,52]

2. Working Software Over Comprehensive Documentation.

Absolutely agree.

That is why Evo suggests a maximum of 1-week front-end planning, before diving in and attempting to deliver real measurable stakeholder-value increments, on the 2nd and all following weeks [5. 6, 8, 1], until no stakeholder value deliveries can be prioritized [10].

Notice I said 'deliver real measurable stakeholder value', and did not make a fool of myself, by saying "Working software is the primary measure of progress" ? Or, even worse "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software".

It is why Evo has a 'startup process' that is 'time-boxed' to maximum one week [6], and why we do the 'top-ten critical stakeholder values quantified', on a single page, in a single day [5A].

We then specify the 'top-ten critical architecture ideas' on the second day, on a single page [6] and etc. the next 2 days [6] with estimation of 'architecture value impacts' and 'architecture costs', and then selection of 'next weeks agile value delivery sprint' on day 4. Manifesto agile suggests none of this ever: that is why it fails [32, 33].

Manifesto agile practices (not in the Manifesto itself, in XP) does User stories and epics. That is their language and documentation. But this is less valuable documentation, premature overhead, and are 'amateur designs' pretending to be 'requirements', and they are overrated detail overhead, suitable for coders, but not project managers, and not result designers. [5B]. 

I understand this value as a reaction to 'silly quantities of documentation' in some earlier waterfall methods [30, 31]. But the reaction is a 'programmers eye view of the world', and does not really consider the primary and critical purposes of all projects: to deliver value to stakeholders, NOT 'code to computers'.

There were far too many 'coders at heart' who negotiated the Manifesto. They had no understanding of the notion of delivering measurable and useful stakeholder value. Which, believe it or not, can be done without coding at all! Some of them (Sutherland, Cohn) do appreciate this 'value and quality' thing better today, but their methods do not take the consequences of that. The are not 'agile' in developing their methods.

Little boys with their hammers think the solution to everything is to bang in nails. Of course good managers would have prevented this narrow-minded excess, but I commented on that above in this paper. The inmates were running the asylum [38].

3. Customer Collaboration Over Contract Negotiation

This Manifesto value I believe has its root in really stupid contracting practices, coupled with even worse development processes. Waterfall, fix price and fixed dates, with contract technical design specifications instead of contract result, specifications. With long term big bang specifications that nobody really understands.

Some professional friends of mine have built a simple legal framework for doing agile. There is no fixed long term cost, or specs, or deadline.

It is all worked out in 'collaboration with the customer' step by step. If step results are measurably delivered, payment is due. [39]. 'Negotiation' is done step by step, as we learn, get results, build confidence.

In earlier times, in a situation where fixed price , fixed date and fixed high quality levels were simply handed to the developers, a smart gang at IBM Federal Systems Division, Led by Harlan Mills [18, 19], developed a process called 'Cleanroom' which was absolutely agile, but more like Evo since it got control over qualities, costs and time by quantification, measurement and learning, coupled with in step re-architecture [Quinnan, 18].

Of course since Manifesto agile has no architecture concept, it is incapable of doing agile architecture they way Quinnan did it at IBM (30 years earlier in 43 increments deliveries).

Their published results [19] were not like Manifesto Agile (20-60% failure) [33]. Their result was what we experience and expect with the cousin process 'Evo': 'all projects on time, under budget' year after year, without exception.

Zero failure rate! 'Agile as it should be' and was before Manifesto corruption (they forgot the engineering) [41]

The success reason is simple, 'lean': early continuous feedback and learning, based on quantification and measurement of critical values and qualities (software 'engineering') [2, 19, 25, 28]. The 'systems' and 'software engineering' which is totally absent from Manifesto agile.

But, if you do not state value improvements and costs quantitatively up front, and then iterate towards meeting targets, within resource constraints (engineering, Evo, Cleanroom), you cannot see deviation from plans early enough. You will FAIL, FAIL [33]. Is this really so difficult for all those smart IT people out there to understand? They 'get it' in my client businesses: but I have to admit, they are engineering business, doing software. not 'coders' doing complex systems projects.

4. Responding to Change Over Following a Plan

Of course, I agree. As I have discussed extensively above.

But, there are several kinds of 'plans': 'stupid fixed ones' based on lack of deep understanding of complex stakeholder values; 'plans which specify badly designed architecture', rather than end results for stakeholders.

Or, our preference, 'plans which focus on a few critical top level long term value improvements', quantified. Even these quantified plans are subject to incremental change.

For example, change by High level guidance, from top management, on behalf of their stakeholders, as to good directions of change and improvement.

I believe [1] that we need much better, and much higher level 'plans' [1, 5A], and that our responses need to be caused by 'numeric deviation from plans', or numeric need to change these numeric plans to reflect the real world.

This is both because:

we get to understand that real world, by trying to deliver change, and
because the real world itself needs to change top-level requirements (business, market, society change) ,

and thirdly because of the necessity of change to better top-level architectures (technology change). 

Manifesto Agile is light-years distant from, really and practically, dealing with these realities. It is doomed to fail, except in the simplest of small programming projects.

In summary, we think the '4 values' are badly stated by the Manifesto committee. But Planguage and evo methods are far better suited to the mature intent of the values. I sympathize with the Manifesto plight, but these guys totally failed on the 'architecture' for delivering the value statements. Not easy to be a committee.

But then, they do not even believe in architecture: all problems can be solved by 'user stories and coding'. it seems, in practice.

No wonder agile discovered a scaling problem [40] after a few years of continuous failure.

The Twelve Agile Manifesto Principles

http://agilemanifesto.org/principles.html

I have long since written my personal counter-proposal for Agile Principles [36A].

I believe that these 'principles' statements are much better and clearer than the fuzzy stuff in the Manifesto. Judge for yourself.

But, here are my direct comments on the principles as published. The Manifesto Principles are so fuzzy that I am sure no two people, and no two manifesto signers, understand any one of them identically.

But they are so fuzzy and sympathetic that they 'sound good'. Like 'Make America Great Again'.

Personally I think anybody could have done a lot better (alone) [36], but unfortunately a committee of diverse people, had to agree. So compromise is what you get. Lowest common denominator.

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Gilb methods (Planguage, Evo,[1,2 ]) are devoted to 'stakeholder satisfaction' but with respect to constraints such as legality, money, time, and 'balance with all other multiple values of a set of stakeholders'. We like the  Principle 1 sentiment, but dislike the formulation, strongly.

But we believe that true customer satisfaction needs to be defined unambiguously and quantitatively in terms of stakeholder values.

Not 'valuable software': people do not want 'software', they want their values satisfied.

The Manifesto has no such serious  'stakeholder value' understanding, and seems to believe that 'code delivery' is the same as 'customer satisfaction'. Or,  at the common-agile-practices level, that 'user stories delivery' is 'satisfaction'. We disagree strongly.

Here is my constructive reformulation:

1. Development efforts should attempt to deliver, measurably and cost-effectively, a well-defined set of prioritized stakeholder value-levels, as early as possible. 

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

That second sentence is pure management BS, right? Only a 'suit' would be naive enough to think it meant anything, or that the Geeks could clearly understand what suits were saying.

Gilb Methods are completely tuned to 'rapidly', and to some degree 'automatically', accommodate changing requirements, of all kinds, including all critical stakeholder values; not just functional requirements and designs (ie not just user stories, functional requirements or designs).

We not only can easily adjust any requirements, but we can compute the changed priority [10] for implementation sequence, using such tools as Value Decision Tables and needsandmeans.com tool. This is far in advance of common agile practices such as using a product owner or playing poker.

Here is my constructive reformulation:

2. Development processes must be able to discover and incorporate changes in stakeholder requirements, as soon as possible, and to understand their priority, their consequences to other stakeholders, to system architecture plans, to project plans, and contracts.

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

We do not believe that this is a useful principle. We believe that it is 'delivery of defined and approved stakeholder values' which is useful.

Including the idea of delivering 'values for resources consumed'. Meaning 'profitability' and 'efficiency'.

Evo and Planguage [1,2] would be quite happy, even in the realm of IT systems, if we never wrote code, and never delivered it. Code is not the point, except for coders, like most all of the Manifesto writers.

'Business and organizational improvements' is the point, and if we can find smarter more cost-effective ways, to deliver those values, than 'code', we should use those methods, of course.

We need, I believe, to approach most of our projects from a 'systems' point of view. Not a dangerously narrow 'program code' point of view. Planguage and Evo do this, the Manifesto has failed us here.

Here is my constructive reformulation:

3. Plan to deliver some measurable degree of improvement, to planned and prioritized stakeholder value requirements, as soon, and as frequently, as resources permit.

Not, 'working software', just real stakeholder results, please. Keep the software out of it if you can. And personally I prefer weekly or 2% of budget steps. But just keep the measurable improvements 'continuously' flowing please (yes, devops), however you choose to do it. Every minute, or 'continuous' is fine with me. I do not want to wait a couple of months, if you can do better than that.

4. Business people and developers must work together daily throughout the project.

We support the spirit of this principle (except the unnecessary limitation of the adjective 'business'). But it is clumsily formulated, and unnecessarily proscriptive, killing 'agile'

We have in Planguage and Evo, a large number of practical tools to assist collaboration: not least the basic idea that all required value improvements can and will be expressed quantitatively. All parties can really work together towards that common set of objectives.

This Planguage 'stakeholder value quantification' [1] is a great tool for improving collaboration. This is because all stakeholders and all developers will be able to understand the same thing, and track progress in actual value delivery.

'Stakeholders', including critical stakeholders, is a much broader category of critical requirements sources than 'business stakeholders'. See the example stakeholder map above (Value 1).

What does 'together' mean? What does 'daily' mean? What does 'work' mean? When does the project begin and end? Who are these business people ('suits' right?, no jeans)? Give me a break!

Here is my constructive reformulation:

4. All parties to a development effort (stakeholders), need to have a relevant voice for their interests (requirements), and an insight on the parts of the effort that they will potentially impact, or which can impact them, on a continuous basis, including into operations and decommissioning of a system.

Note: this does not have to happen by 'working together daily'. That literally becomes silly in large scale distributed systems. I personally think that by having controlled access to a common project database in Planguage, using a tool like needsandmeans.com, we can provide a 'relevant voice' to all stakeholders, and we can provide insight into consequences of plans and decisions for all.

5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

Well of course. World peace too, while we are at it.      BS level.

Projects need to be built around a balanced, logically-prioritized set of stakeholder needs [10], and with consideration of available resources (people, time, money).

Projects and project methods can be designed to motivate various types of individuals and stakeholder types. But this concept of hiring or employing (?) individuals who are motivated (in advance?) sounds optimistic to me. Motivated people can get 'turned off' for such a large number of reasons.

And would you prefer competent, experts, or motivated untrained novices?

Trust, but verify.[1, see Quality Control, esp. part 2 and Part 4, and Chapter 10 Quality Management ].

Here is my constructive reformulation:

5. Motivate stakeholders and developers, by agreeing their high-level priority objectives, and give them freedom to find the most cost-effective solutions. [42]

6. Enable face-to-face interactions

Sometime yes. But not always. Not always possible. Not always cost-effective. Not always desireable.

I understand the frustration of not being able to discuss things with stakeholders, and the dangers of not being able to motivate, get motivated, clarify, and get clarity by interactions.

So it sounds great: face-to-face, electronically or in the flesh, as long as it the most cost-effective way to deliver real measurable value.

But the really important idea is not face-to-face itself. Proscribing that, sounds like another way of killing agility.

The important idea, independent of the 'how' (the chosen means to communicate), is communication of ideas, like requirements, designs, risks, progress, problems. Often for a very large number of stakeholders and individuals, over great time and distances, in a fast changing world. We need to be able to tackle very large and complex systems, and there is a point where face to face is not the most important communication technique.

I believe that Planguage and Evo methods, including the app needsandmeans.com which works well, in 'distance online meetings and discussions',  offer a more general solution to this communication problem. And a Planguage database is one in which we can feed in or out from; and use for better face to face interactions, than if we do not use such tools.

Here is my constructive reformulation:

6. Enable crystal-clear communication, in writing, in a common project database. Enable collection and prioritization, and continuous updates, of all considerations about requirements, designs, economics, constraints, risks, issues, dependencies and prioritization.

Note: I did not specifically mention face-to-face. I want people to be free and agile enough to figure out their best current available mode of communication.

The critical idea is NOT face-to- face. But quality of relevant information from and for stakeholders, including developers. My experience is that oral communication is not a good way to formulate complex things clearly. But oral and visual communication can assist in improving the clearer formulation, in the project database in Planguage. This is a general truth in all advanced disciplines. Face-to-face is more appropriate in simpler and more primitive situations, and useful as a useful supplement to communicating with and about the project database (in Planguage). [1 [12 Communication], 2, 15]

7. Working software is the primary measure of progress.

This principle is ridiculous, except if writing code is the only purpose in life.

Which must be the case for the Manifesto signers, as evidenced by this principle. All other human beings have different measures of progress. Including all other stakeholders of the project or system involved.

The primary measures (plural!) of progress are the measurements of the delivery of an official approved current set of requirements, for a given stakeholder type, or individual.

These must necessarily be quantified, and well defined. They must be relevant measures, not just something 'easy to measure'.

This is the core discipline of Planguage, and it it not mentioned in the manifesto or in most agile practices (except Cleanroom and Evo) [1, 2, 7 , 18, 19, 20]

No wonder 'agile' fails, with this as a driving principle. it defies common sense!

Here is my constructive reformulation:

7. The primary measure of development progress is the 'degree of actual stakeholder- delivered planned value levels' with respect to planned resources; such as budgets and deadlines.

Note this can be expressed as a simplified overall measure, for any set of value requirements as 'average % of Goal Levels of required values delivered on time'. This applies even when no working software is delivered at all. So, databases are not software, right? I do like to call them dataware, but they are soft, and they can change value delivery, for example.

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 

Well I agree we don't want burned out people, death march projects and destroyed family lives.

But I do think there are a large number of methods, which need to applied simultaneously to make that happen. Including legal worker protection action by governments!

What does 'promote' mean? What evidence is there to support the idea. And which agile processes are we talking about here? And what is a measurable definition of 'sustainable development' ? Sounds like Geek BS to me [43]. Is it just about forcing us to commit errors, and deliver bad quality, under pressure at last moment? Or is there a bigger picture than bug generation?

Try Jones at namcook.com, or David rico at DavidFRico,com, or even Jack Craine's slides [32] for some possible sources. But at best this is a research project. Making unsubstantiated claims, is for fools to listen to. I prefer facts and measures, not claims. And quite different methods will work best in quite difference cultures. Wow, a Silver Bullet - Agile! Grow up.

Planguage and Evo tackle this problem directly by several devices. Value delivery from the project second week; continuously, and then 'intelligent dynamic prioritization', coupled with quantified values and qualities, are the key ideas. [1,2, 6, 10, 15].

Here is my constructive reformulation:

8. We believe that a wide variety of strategies, adapted to current local cultures, can be used to maintain a reasonable workload for developers, and other stakeholders; so that stress and pressures, which result in failed systems, need not occur.

Note: again, we raise our sights to a higher level (avoid pressure leading to problems), and leave the discovery and creativity to the locals [42].

In the case of the IBM Defect Prevention Process [1, 2, 14, 42] at the IBM Minnesota Labs, there were about 2167 process changes over about 18 months, made to the software working processes, to improve quality and productivity. I do not recall if 'agile' was one of them. No, this was pre-manifesto.

9. Continuous attention to technical excellence and good design enhances agility.

More geek BS [44].
Define, 'continuous, attention, technical, excellence, good, design, enhances, agility' !

Is agility in itself, a good thing, or is is a possible means to some specific ends?

Or is agility dangerous in the hands of people immature enough to believe the Manifesto principles?

Planguage and Evo [1, 2] specify very specific methods and tools, to plan and measure 'technical excellence' [7];  and to plan and measure  'good design' (the Value Decision Table [1,2])

The manifesto states embarrassing platitudes, with no visible foundation or purpose. It must be embarrassing today, reading this for example, to have signed off on these principles. What were they smoking?

But if you are one of the masses who got sucked into this 'agile' con game [32, 33], I can assure you that all the signers were intelligent well-intentioned men. Obviously women would not be silly enough to sign it!

Would a class-action lawsuit by CIO's against Manifesto Signers, citing serious financial and practical damage to society, set a useful precedent for future manifestos and methods suggestions?

Do you think I am an angry old man? Damn right I am angry at this irresponsible and unprofessional agile culture. It is time to stop it by law, lawsuits or revolution (software engineering revolution, anyone?)

Here is my constructive reformulation:

9. Technical excellence in products, services, systems and organizations, can and should be quantified, for any serious discussion or application. The suggested strategies or architectures, for reaching these 'quantified excellence requirements', should be estimated, using Value Decision Tables [45, 1, 2], and then measured in early small incremental delivery steps.

let me edit that a bit:

9. Quality must be quantified, and supporting designs for quality must be estimated and measured. [4]

10. Simplicity - the art of maximizing the amount of work not done - is essential.

Cute. But what does it mean to us in practice? More Geek BS. (Below Standard) :)

Here are my detailed and practical complexity-simplification ideas and methods [46, 47, 48, 49] and of course they are all using Planguage and Evo.

Small iterative value-delivery steps (Evo, and some other 'agile' methods like Cleanroom is a major simplification technique [18]. There are very many more simplification techniques [46, 47, 48, 49, 1, 2]

My favorite single practical method for dealing with complexity is the Value Decision Table [1, 2, 45]. It immediately helps us divide up the complexity 100 to 1 (a 10x10 table does that).

And there are many Planguage tools for decomposing complex problems into simpler problems [9]

Here is my constructive reformulation.

10. We need to learn and apply methods, of which there are many, to help us understand complex systems and complex relations. [46, 47, 48, 49, 1, 2] and succeed in meeting our goals in spite of them.

Note: I did not at all reference the 'work not done' phrase. That is merely one possible outcome of many - avoiding 'muda' or wasted work. Other outcomes of simplification might primarily lead to delivering the right quality and values on time, and might well involve more work than failed projects would use. None of that seemingly  'extra work' is inessential to that purpose of successful value delivery. Things should be as simple as possible, button simpler [20], incorrectly attributed to Einstein [46]. So I'll take credit for publishing it. :)

11. The best architectures, requirements, and designs emerge from self-organizing teams.

OMG. more total Geek BS from a group of people who manifestly do not understand architecture or requirements at all.

Define: best, architectures, requirements, designs, self-organizing, teams. ? [my take on some of these is at 2, Planguage Glossary ]

Where is the proof or evidence or research, or even a credible case study to back this up?

Scrum and other agile teams are intended to be self-organizing, but the level of requirements, architecture and design they produce is from 'nothing at all' to 'abysmally and embarrassingly bad', in my opinion [50]

Most so-called enterprise architects (99% according to my informal 300 architect survey [50] cannot quantify the qualities or costs of their architecture. So they must use some kind of magic. It is certainly not logic [17] or facts.

I believe in self-organizing teams, as a smart way of designing organizations and products [42], and add Dave Snowdon's Sensemaker to the mix of exciting approaches [http://cognitive-edge.com/ sensemaker/], but the above principle is a bit too vague, unsubstantiated, and impractical for my taste. it might even be 'true', but I am not so foolish to believe it, as stated! Are you?

Here is my constructive reformulation:

11. A. The most useful value and quality requirements will be quantified, and will use other Planguage mechanisms, including careful corresponding stakeholder analysis [1, 51, 52]

11 B. The most cost-effective designs/architecture, with respect to our quantified value and resource requirements, will be Value Decisioned, on an Value Decision Table: with their evidence, sources and uncertainty. They will be prioritized by values/resources with respect to risks [45].

simplified

11. We will use engineering quantification for all variable requirements, and for all architecture.

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Nice sentiment for small teams with no intent to help the larger organization learn anything from them, or without allowing that larger organization to teach them anything, or to validate their ideas on a larger scale. It is called silo thinking. [53]

For a non-trivial organization, the best proven method I know of, with facts and numbers is the Defect Prevention Process [42, 1, 14] invented by IBM. This allows any number (it scales up!) of employees and developers, anywhere distributed, to 'reflect on how to become more effective' in small teams, and then escalate deployment to the larger organization for proven ideas.

Here is my constructive reformulation:

12. a process like Defect Prevention Process, or another more-suitable for current culture, which delegates power to analyze and cure organizational weaknesses, will be applied: using participation from small self-organized teams to define and prove more cost-effective work environments, tools, methods and processes.

REFERENCES:

REFERENCES:
1. Value Planning (2017) Link to book: https://www.gilb.com/store/2W2zCX6z

2. Competitive Engineering (2005): Get a free e-copy of ‘Competitive Engineering’ book. https://www.gilb.com/p/competitive-engineering

3. gilb.com

4.TedX Talk: Tom Gilb, 'Quantify the Unquantifiable' https://www.youtube.com/watch?v=kOfK6rSLVTA

5. Gilb’s Agile Mythodology: [5A] Top Ten 'The Top 10 Critical Requirements are the Most Agile Way to Run Agile' Projects http://www.gilb.com/dl797
[5B] User Stories Need Reinforcements
http://www.gilb.com/DL461

6. Gilb: An Agile Project Startup Week www.gilb.com/dl568

7. Gilb, Competitive Engineering, Chapter 5 Scales of Measure.  https://www.dropbox.com/s/z031wn8s6aduvze/

8. in CE book [2] and See Persinscom Case: US DoD Army Personnel System. “111111 Unity Method of Decomposition into weekly increments of value delivery”. (10 min. talk slides) http://www.gilb.com/DL451

9. See the Chapter 5 Decomposition chapter in Value Planning [1] or https://www.dropbox.com/sh/dc7v636m7w7vvgx/AABfMAW_FnJny23XZKQZQkF4a?dl=0

10. Ch. 6 Prioritization VP book [1] ,https://www.dropbox.com/sh/34llx1a7ckyagxl/AAA0pDzSxN5WmoP9lOKR0Mpca?dl=0

11. Ch. 7, Risk Management in VP [1], https://www.dropbox.com/sh/fxvtya6gyvgwkfa/AAA5-vrLUt_z0h9EYt1ql3Uma?dl=0

12. Ch. 9 in VP book [1], Communication, https://www.dropbox.com/sh/fxvtya6gyvgwkfa/AAA5-vrLUt_z0h9EYt1ql3Uma?dl=0

13.Ch. 10 in VP book [1] 'Quality Management'. https://www.dropbox.com/sh/vjwybhqfxrvctk7/AAAdabECBSo5x-tSOI85R-1da?dl=0

14. Gilb & Graham, Software Inspection, 1993

15. J. Terzakis, (Intel) "The impact of requirements on software quality across three product generations," 2013 21st IEEE International Requirements Engineering Conference (RE), Rio de Janeiro, 2013, pp. 284-289. https://www.thinkmind.org/download.php?articleid=iccgi_2013_3_10_10012

16. Ch. 2 Strategies in VP [1], https://www.dropbox.com/sh/xab857l9ksfs7w0/AACKonxV1x_LI5TW62FICMMPa?dl=0

17. ”The Logic of Design: Design Process Principles". Tom Gilb, 2015, Paper. http://www.gilb.com/dl857

18. Cleanroom, Quinnan, in VP, case 2.5 [8], QUINNAN AND MILLS CLEANROOM http://www.gilb.com/dl821. Cleanroom

19. A. Mills, H. 1980. The management of software engineering: part 1: principles of software engineering. IBM Systems Jour- nal 19, issue 4 (Dec.):414-420.
Direct Copy

http://trace.tennessee.edu/cgi/viewcontent.cgi?article=1004&con- text=utk_harlan
Library header
http://trace.tennessee.edu/utk_harlan/5/

B. Mills, Harlan D.; Dyer, M.; and Linger, R. C., "Cleanroom Software Engineering" (1987). The Harlan D. Mills Collection.

http:// trace.tennessee.edu/utk_harlan/18

20. Value Driven Project Management 17.5MB slides 2008 '152'. Includes Confirmit Case (slide 70-93). http://www.gilb.com/dl152, http://www.gilb.com/dl50

21. T. Gilb and L. Brodie, "How problems with Quality Function Deployment's (QFD's) House of Quality (HoQ) can be addressed by applying some concepts of Impact Estimation (IE)" http://www.gilb.com/DL119

22. Elon Musk, the bio by Ashlee Vance, 2015. The only fault in my Tesla S from Oct 2016 to December 2017 was that the remote tire pressure sensors did not work properly with non-standard winter tires. This was fixed for free by Tesla. That quality is not an accident, it is a result of iterative intelligent prioritization weekly forever. 20 upgrades a week to production cars, and 10 a week to delivered cars (software over air).

23. Value Planning, Chapter 3, Levels of Interest. About stakeholders. https://www.dropbox.com/sh/xbzn5s8imf9vla0/AAB8h-OFvQmJ_w3wNhrDxa9_a?dl=0

24. Needs and Means Planning tool. needsandmeans.com

25. Everyday Superpowers, Gilb, Paper 020118: http://concepts.gilb.com/dl914

26. Agile References for Tom Gilb: https://www.dropbox.com/s/4gd9214tttfiwym/Agile%20References%20Gilb.pdf?dl=0

27. Gilb Agile Papers: https://www.dropbox.com/s/p6iinwnaak0339o/gilb%20agile%20papers%20slides%20per%20231017.pdf?dl=0

28. Gilb, Principles of Software Engineering Management, 1988.
This is the foundational agile book referred to by many Manifesto signers [26]

[28A] See pdf ‘Ch 14 POSEM Productivity’ gilb.com/dl560

[28B] Chapter 15 Deeper Perspectives on Evolutionary Delivery gilb.com/dl561

[28C] https://www.amazon.com/Principles-Software-Engineering-Management-Gilb/dp/0201192462 for free digital copy signup at www.gilb.com

29. Hewlett Packard Case
HP Evo
[29A]. The Evolutionary Development Model for Software
by Elaine L. May and Barbara A. Zimmer
August 1996 Hewlett-Packard Journal
http://www.gilb.com/DL67

[29B]. Evolutionary Fusion: A Customer- Oriented Incremental Life Cycle for Fusion
by Todd Cotton
http://www.gilb.com/DL35
August 1996 Hewlett-Packard Journal

[29C] RAPID AND FLEXIBLE PRODUCT DEVELOPMENT: AN ANALYSIS OF SOFTWARE PROJECTS AT HEWLETT PACKARD AND AGILENT (2001)
by Sharma Upadhyayula
http://www.gilb.com/DL65
M.S., Computer Engineering University of South Carolina, 1991
And Massachusetts Institute of Technology, January 2001

[29D]. Best Practices for Evolutionary Software Development
by
Darren Bronson
http://www.gilb.com/dl825
57 pages., 1999.

URI: http//hdl.handle.net/1721.1/80490

30. Mil Standard 498 (long before Manifesto!)
https://kkovacs.eu/free-project-management-template-mil-std-498

"It supports multiple program strategies. It clearly says that there are three ways of doing projects: "Grand design" (also known as, waterfall), "Incremental" (which most Agile projects do), and even "Evolutionary" (which includes exploratory projects like prototypes)."

31: Standards Comparison slides 498 and later civil standards.
A Comparison of IEEE/EIA 12207, ISO/IEC 12207, J-STD-016, and MIL-STD-498 for Acquirers and Developers
Lewis Gray, Ph.D.
http://abelia.com/docs/122_016.pdf

32. Jack Caine’s 'Agile Lean slide collection'
linkedin.com/in/jack-caine-58690a13
well over 1,000 very good slides, which you can reuse (Jack told me) for your agile presentations. Just credit original author on slide.

33. AGILE FAILURE RATES:
Google: 'Agile IT failure rates'

33A Why we Should Rethink the Agile Manifesto: Projects Still Fail
Derwyn Harris | September 10, 2014
https://www.google.no/search?client=safari&rls=en&q=agile+it+failure+rate&ie=UTF-8&oe=UTF-8&gfe_rd=cr&dcr=0&ei=LR9NWobkI8-q8wfMq67YBg

33B UK wasting £37 billion a year on failed Agile IT projects
https://www.google.no/search?client=safari&rls=en&q=agile+it+failure+rate&ie=UTF-8&oe=UTF-8&gfe_rd=cr&dcr=0&ei=LR9NWobkI8-q8wfMq67YBg

"The survey found that 34% of failed Agile projects failed because of a lack of upfront and ongoing planning. Planning is a casualty of today’s interpretation of the Agile Manifesto, which can cause Agile teams to lose their way and their customers to lose visibility of what they are getting for their money, now and in the future."

"68% of CIOs agree that Agile teams require more Architects. From defining strategy, to championing technical requirements (such as performance and security) to ensuring development teams stick to the rules of the game, the role of the Architect is sorely missed in the Agile space.  It must be reintroduced.
But the report did uncover some relatively good news for the UK tech industry.  While the rate of complete failure of Agile projects was 12% in the UK – in the US, CIO’s report 21% of Agile projects result in complete failure."

34. Ken and Will Hopper: The Puritan Gift.
https://www.amazon.com/Puritan-Gift-Reclaiming-American-Financial/dp/184511986X
An analysis of how American management went bad, starting with Harvard Business School. Managers still have almost no idea how to 'balance their scorecard', by quantifying business and customer values, as well as they do the 'financials'. Management BS still reigns. Musk [22] and Jobs did not get an MBA. But they are value-driven, not finance-narrow.

35. ‘What’s Wrong With Agile Methods? Some Principles And Values To Encourage Quantification’ with Confirmit Case'.
http://www.methodsandtools.com/archive/archive.php?id=58

36. Some Alternative Ideas On Agile Values For Delivering Stakeholder Value Principles and Values – Agility is the Tool, Not the Master. 2 papers see links below.

[36A] Gilb’s Ten Key Agile Principles to deliver stakeholder value, avoid bureaucracy and give creative freedom" Part 1 of 2
http://www.gilb.com/DL431
(The Paper from Agile Record)
Note: the gilb.com references will work if you delete the ''tiki-download_file.php?fileid=" text, and insert DL in front of the number (www.gilb.com/DLnn) where nn is the number at the end of the old URL

[36B] Part 2 “Values for Value”
http://www.gilb.com/DL448
Agile Record 2010, www.agilerecord.com, October 2010, Issue 4
Note: the gilb.com references will work if you delete the ''tiki-download_file.php?fileid=" text, and insert DL in front of the number (www.gilb.com/DLnn) where nn is the number at the end of the old URL

37. Advanced Agile Software Engineering (Agile Turkey April 2018 slides talk) Version 2 jan 2018 1st draft. Might be much changed by presentation date.
http://concepts.gilb.com/dl915

38. Alan Cooper, The Inmates are running the Asylum, https://www.goodreads.com/book/show/44098.The_Inmates_Are_Running_the_Asylum

39. Contracting for Value
39A. Slides http://www.gilb.com/dl864
39B. Paper, Agile Contracting for Results The Next Level of Agile Project Management: Gilb's Mythodology Column Agilerecord August 2013
http://www.gilb.com//dl581

40. ON SCALING

[40A]: SLIDES. Practical Scaling Methods for Industrial Systems
Unicom Conf, London, 31 Oct 2017, slides
http://concepts.gilb.com/dl916

[40B] “Beyond Scaling: Scale-free Principles for Agile Value Delivery - Agile Engineering”
http://www.gilb.com/dl865 (PAPER). With reference to Intel experiences with Gilb methods. (Jan 8 2016)

[40C] “SCALE-FREE:
Practical Scaling Methods
for Industrial Systems Engineering”
lecture slides. With reference to Intel experiences with Gilb methods.
http://concepts.gilb.com/dl892

41. Planguage A Software and Systems Engineering Language, for Evaluating Methods, and Managing Projects for Zero Failure, and Maximum ‘Value Efficiency’
Keynote
International Conference on Software Process and Product Measurement (Mensura)
http://concepts.gilb.com/dl918

42. Power To the Programmers
(about delegation and motivation in practice)
Power to The Programmers”, as held Krakow ACE Conference June 2014
Video: http://vimeo.com/98733453

Link to Oct 2015 Prague Slides
“Power to The Programmers”
http://concepts.gilb.com/dl841

43. See https://technology.amis.nl/2008/10/03/agile-software-development-the-principles-principle-8-agile-processes-promote-sustainable-development-the-sponsors-developers-and-users-should-be-able-to-maintain-a-constant-pace-indefinitely/ for more Geek BS without any evidence whatsover

44. Gilb, Quantifying Management Bullshit: forcing IT Stakeholders to reveal the value they really want from your IT Project.
http://www.gilb.com/dl465

45. Tom Gilb
'Estimating Efficiency of Means for Ends: A Dummies Guide to Impact Estimation Tables'
http://concepts.gilb.com/dl906

46. Simplicity Talk
http://www.gilb.com/DL464
ACCU Conference. Einstein and Simplicity Principles

47. Gilb, CONFRONTING WICKED PROBLEMS:
and some Planguage Tools to deal with them.
http://www.gilb.com/dl866
A detailed paper on how Planguage, in practice, can simplify 'wicked' problems (which then are no longer so wicked)
on Jan 10 2016

48. Software Engineering Complexity
and Challenges of Software Engineering
slides, http://concepts.gilb.com/dl889
Quality Days, Vienna, Talk
Wednesday 18 January 2017
45 minutes

49. Practical Tools for Simplification
of Software Quality Engineering
Half-Day Afternoon Workshop at
Quality Days, Vienna 17 January 2017
http://concepts.gilb.com/dl888

50. What is Wrong with Software Architecture. Gilb Keynote in London Oct 2013
https://www.youtube.com/watch?v=HNasoyrxzy8
1.5 Hours.
USE https://vimeo.com/28763240 (Javazone, Oslo)

What is wrong with current Software Architecture Methods: 10 Principles for Improvement, 30 Sept 2013 and Oct London week, http://concepts.gilb.com/dl587

51. Stakeholder Power:The Key to Project Failure or Success
including 10 Stakeholder Principles
http://concepts.gilb.com/dl880

52.  Stakeholders and their values
GilbFest 2017,slides
http://concepts.gilb.com/dl920

53. Gillian Tett: The Silo Effect: The Peril of Expertise and the Promise of Breaking Down Barriers. 2017

54. Value Manifesto, Tom Gilb
http://concepts.gilb.com/dl898
March 2017, This is the core of my Agile Ideas.

See updated version January 2018 at www.Gilb.com (Blog) 

If any links are broken please report to [email protected]