Teacher: Tom Gilb, Hon FBCS
--------------------------------------------------------------------------------
AGENDA
18:00 – Main presentation
20:30 – Approximate close
--------------------------------------------------------------------------------
SYNOPSIS
Agile for IT projects, Scrum, and the many variations, are in my opinion part of the problem, not the solution, to good successful IT projects. The Agile total-failure rate is 62% according to one internet analysis (by Kai Gilb). Fact is, it varies, and is much worse when all degrees of failure are considered.
The problem is: agile, as practiced and taught, is focussed on code and speed of production. It needs to be focused on delivering real measurable improvement of critical values to the stakeholders.
When did your agile project report numeric improvements in your top-ten critical value-objectives?
Prerequisites:
Please ensure you have a laptop or tablet so that you can access fully the presentation and other documentation, as well as participate in exercises, and use specification tools.
Description:
This is a lecture plus (10%) discussion course.
I am going to brief you on agile, and on ‘agile as it should be’, based on my book ‘Value Agile’
Background:
I can tell you right away that the problem is ‘management bullshit’, and the solution is ‘crystal clear communication’. I will also teach you exactly how to communicate better in practice, about your projects. It is not very difficult, you mainly have to decide to get a lot clearer, like 100X clearer, 100X less BS. Is that clear?
We will start with an in-depth analysis of the Infamous ‘Agile Manifesto’. We will continue with a section on why projects get messed up. On our way we will give quite a few, usually freely-downloadable, references, for constructive ‘how to’ detail.
Are you ready to differentiate yourself from the run-of-the-mill certified agilistas, by you quickly delivering real valued results, to your business?
It might take real courage to stand up for business results, when all around you believe that ‘delivering working code’ 6 times faster than usual, is the main idea. Of course you will finally have to prove you can deliver results to gain real credibility. We will equip you with practical tools, but you have to fight for what is honourable: real results for your stakeholders.
Main subjects: (this is the book, below, table of contents)
How Well Does the Agile Manifesto Align with Principles that Lead to Success in Product Development?
Chapter 1. The Four Values of the Agile Manifesto, a critical analysis 7
Value 1. Individuals and interactions over processes and tools 9
Value 2. Working software over comprehensive documentation 11
Value 3. Customer collaboration over contract negotiation 13
VALUE 4. ‘Responding to change over following a plan’ 16
Chapter 2. 18
The Twelve Agile Manifesto Principles, a critical analysis 18
PRINCIPLE 1: ‘Our highest priority is to satisfy the customer through early and continuous delivery of valuable software’. 18
PRINCIPLE 2. ‘Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage’. 21
PRINCIPLE 3. ‘Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale’. 24
PRINCIPLE 4. ‘Business people and developers must work together daily throughout the project’. 26
PRINCIPLE 5. ‘Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done’. 30
Principle 6. ‘Enable face-to-face interactions’. 33
Principle 7. ‘Working software is the primary measure of progress’. 38
PRINCIPLE 8. ‘Agile processes promote sustainable development. 40
The sponsors, developers, and users should be able to maintain a constant pace indefinitely’. 40
PRINCIPLE 9. ‘Continuous attention to technical excellence and good design enhances agility’. 44
PRINCIPLE 10. ‘Simplicity - the art of maximising the amount of work not done - is essential’. 47
Principle 11. ‘The best architectures, requirements, and designs emerge from self-organizing teams’. 49
Principle 12. ‘At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly’. 51
References for the ‘agile manifesto’ chapter 53
CHAPTER 3: 60
Principles of Project Failure: How to sabotage a project, without anyone noticing you. 60
THE MAIN PRINCIPLES OF FAILURE 68
1. Do not analyze stakeholders, stick to ‘customers' and ‘users’. 68
2. Do not clarify stakeholders values. Give them the technology they say they want. 74
3. Commit to all the ‘nice-sounding’ designs and strategies. Especially the ones on the managers’ PowerPoint slides. 81
4. Make use of the most widespread project development methods. 84
Popularity is a sure sign of oversimplified training, 84
and methods which do oversimplify training, have failure rates that are over 50%, for years on end, 84
and no one does anything effective about it. 84
5. Make sure no one ever estimates how effective a design or strategy will be. Or what it will cost in the short term or long term. 88
Such estimates are rarely perfect and might distract from using perfectly nice and modern-sounding designs. 88
Like AI, blockchain. Or big data. 88
6. For goodness sake. Do not waste energy trying to estimate the side-effects of exciting strategies, 90
on your critical objectives and costs. 90
Such insights would delay your ‘will to get on with it’, 90
and overrun the deadline. 90
7. No cure, NO pay 93
Summary 96
References. Project Failure 98
Chapter 4 What is ‘agile As it should be’?
The real agile 103
Let’s define ‘cost-effectiveness’ 104
What are the consequences of ‘agile cost-effectiveness’ as a tool? 106
What about the core agile idea: ‘adaptability’ to changes, and to new insights? 108
Chapter 5
Parallel Agile Value delivery 109
Some Definitions from ‘Planguage’ [Ref. S] and ‘competitive engineering’ [F] book. 109
“ Parallel Development Concept *363 February 25, 2003 109
Parallelity: Concept *104. August 3, 2001 109
The comparison to the parallel development as written in the 2020 ‘Parallel agile’ book. 110
Distinct Software 110
Practical Case study 2003 Confirmit 111
The Backroom and Frontroom Parallel value development 113
Parallel Value requirement specification 115
Strategy Decomposition, for independent implementation 116
Using Value Tables to select parallel developments 118
A Result Cycle [S]: Here is another detailed concept definition from 2003 (Planguage concept glossary) 119
Result Cycle Concept *122. January 3, 2003 119
Documentation: the course is based on this recent textbook
Title : Value Agile: Agile as it should be.
Which BCS Members may download, print out, get signed by the teacher, at any time in order to evaluate the course contents, and to prepare for the course beforehand, and to study and share with their organisation afterwards; if they wish.
--------------------------------------------------------------------------------
SPEAKER BIOGRAPHY
Tom Gilb HonFBCS joined IBM in 1958. He has been an international consultant and teacher for 55 years. Written 10 published books. Competitive Engineering (2005), and Value Planning (2016). As well as 10 digitally published books in 2018 and 2019. Tom has developed advanced methods for developing systems of any kind, with emphasis on IT systems and High Quality systems.
He is Honorary Fellow of BCS.
Tom Gilb and his partner Kai Gilb have, together with many professional friends and clients, personally developed the Agile ‘Engineering’ methods they teach. The methods have been developed over five decades of practice all over the world in both small companies and projects, as well as in the largest companies and projects. Their website www.Gilb.com/ offers free papers, slides, books, videos, and cases about Agile and many other subjects.
There are many organisations, and individuals, who use some or all of their methods. IBM and HP were two early corporate-wide adopters (1980, 1988). As of 2016 over 20,000 engineers at Intel have voluntarily adopted the Planguage requirements specification methods; in addition to practicing to a lesser extent Evo, Spec QC and other Gilb methods.
Many other multinationals are in various phases of adopting and practicing the Gilb methods. Many smaller companies also use the methods.
Tom’s methods are 100% risk conscious and devoted to reducing the risks of failure and partial failure, by attention to the details, and to the big picture.
--------------------------------------------------------------------------------
THIS WORKSHOP IS BROUGHT TO YOU BY: BCS SPA Specialist Group
Visit http://www.bcs-spa.org/index.php
